Thread: Annoying build warnings from latest Apple toolchain

Annoying build warnings from latest Apple toolchain

From

Tom Lane

Date:

26 September 2023, 22:23:18

Since updating to Xcode 15.0, my macOS machines have been
spitting a bunch of linker-generated warnings.  There
seems to be one instance of

ld: warning: -multiply_defined is obsolete

for each loadable module we link, and some program links complain

ld: warning: ignoring duplicate libraries: '-lpgcommon', '-lpgport'

You can see these in the build logs for both sifaka [1] and
indri [2], so MacPorts isn't affecting it.

I'd held out some hope that this was a transient problem due to
the underlying OS still being Ventura, but I just updated another
machine to shiny new Sonoma (14.0), and it's still doing it.
Guess we gotta do something about it.

We used to need "-multiply_defined suppress" to suppress other
linker warnings.  I tried removing that from the Makefile.shlib
recipes for Darwin, and those complaints go away while no new
ones appear, so that's good --- but I wonder whether slightly
older toolchain versions will still want it.

As for the duplicate libraries, yup guilty as charged, but
I think we were doing that intentionally to satisfy some other
old toolchains.  I wonder whether removing the duplication
will create new problems.

            regards, tom lane

[1] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=sifaka&dt=2023-09-26%2021%3A09%3A01&stg=build
[2] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=indri&dt=2023-09-26%2021%3A42%3A17&stg=build

Re: Annoying build warnings from latest Apple toolchain

From

Tom Lane

Date:

27 September 2023, 00:37:36

I wrote:
> Since updating to Xcode 15.0, my macOS machines have been
> spitting a bunch of linker-generated warnings.  There
> seems to be one instance of
> ld: warning: -multiply_defined is obsolete
> for each loadable module we link ...

I poked into this a little more.  We started using "-multiply_defined
suppress" in commit 9df308697 of 2004-07-13, which was in the OS X 10.3
era.  I failed to find any specific discussion of that switch in our
archives, but the commit message suggests that I probably stole it
from a patch the Fink project was carrying.

Googling finds some non-authoritative claims that "-multiply_defined"
has been a no-op since OS X 10.9 (Mavericks).  I don't have anything
older than 10.15 to check, but removing it on 10.15 does not seem
to cause any problems.

So I think we can safely just remove this switch from Makefile.shlib.
The meson build process isn't invoking it either I think.

The other thing will take a bit more work ...

            regards, tom lane

Re: Annoying build warnings from latest Apple toolchain

From

Tom Lane

Date:

27 September 2023, 19:05:49

I wrote:
> Since updating to Xcode 15.0, my macOS machines have been
> spitting a bunch of linker-generated warnings. ...
> some program links complain

> ld: warning: ignoring duplicate libraries: '-lpgcommon', '-lpgport'

I found that this is being caused by the libpq_pgport hack in
Makefile.global.in, which ensures that libpgcommon and libpgport
get linked before libpq.  The comment freely admits that it results in
linking libpgcommon and libpgport twice.  Now, AFAICS that whole hack
is unnecessary on any platform where we know how to do symbol export
control, because then libpq won't expose any of the troublesome
symbols to begin with.  So we can resolve the problem by just not
doing that on macOS, as in the attached draft patch.  I've confirmed
that this suppresses the duplicate-libraries warnings on Xcode 15.0
without creating any issues on older macOS (though I'm only in a
position to test as far back as Catalina).

The patch is written to change things only on macOS, but I wonder
if we should be more aggressive and change it for all platforms
where we have symbol export control (which is almost everything
these days).  I doubt it'd make any noticeable difference in
build time, but doing that would give us more test coverage
which would help expose any weak spots.

I've not yet looked at the meson build infrastructure to
see if it needs a corresponding change.

            regards, tom lane

diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index 18240b5fef..cded651755 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -589,19 +589,31 @@ endif
 libpq = -L$(libpq_builddir) -lpq

 # libpq_pgport is for use by client executables (not libraries) that use libpq.
-# We force clients to pull symbols from the non-shared libraries libpgport
+# We want clients to pull symbols from the non-shared libraries libpgport
 # and libpgcommon rather than pulling some libpgport symbols from libpq just
 # because libpq uses those functions too.  This makes applications less
-# dependent on changes in libpq's usage of pgport (on platforms where we
-# don't have symbol export control for libpq).  To do this we link to
+# dependent on changes in libpq's usage of pgport.  To do this we link to
 # pgport before libpq.  This does cause duplicate -lpgport's to appear
-# on client link lines, since that also appears in $(LIBS).
+# on client link lines, since that also appears in $(LIBS).  On platforms
+# where we have symbol export control for libpq, the whole exercise is
+# unnecessary because libpq won't expose any of these symbols.  Currently,
+# only macOS warns about duplicate library references, so we only suppress
+# the duplicates on macOS.
+ifeq ($(PORTNAME),darwin)
+libpq_pgport = $(libpq)
+else ifdef PGXS
+libpq_pgport = -L$(libdir) -lpgcommon -lpgport $(libpq)
+else
+libpq_pgport = -L$(top_builddir)/src/common -lpgcommon -L$(top_builddir)/src/port -lpgport $(libpq)
+endif
+
 # libpq_pgport_shlib is the same idea, but for use in client shared libraries.
+# We need those clients to use the shlib variants, even on macOS.  (Ideally,
+# users of this macro would strip libpgport and libpgcommon from $(LIBS),
+# but no harm is done if they don't.)
 ifdef PGXS
-libpq_pgport = -L$(libdir) -lpgcommon -lpgport $(libpq)
 libpq_pgport_shlib = -L$(libdir) -lpgcommon_shlib -lpgport_shlib $(libpq)
 else
-libpq_pgport = -L$(top_builddir)/src/common -lpgcommon -L$(top_builddir)/src/port -lpgport $(libpq)
 libpq_pgport_shlib = -L$(top_builddir)/src/common -lpgcommon_shlib -L$(top_builddir)/src/port -lpgport_shlib $(libpq)
 endif

Re: Annoying build warnings from latest Apple toolchain

From

Tom Lane

Date:

27 September 2023, 20:52:44

I wrote:
> I've not yet looked at the meson build infrastructure to
> see if it needs a corresponding change.

I think it doesn't, as long as all the relevant build targets
write their dependencies with "frontend_code" before "libpq".
(The need for this is, of course, documented nowhere.  The state
of the documentation for our meson build system is abysmal.)

However, it's hard to test this, because the meson build
seems completely broken on current macOS:

-----
$ meson setup build --prefix=$HOME/pginstall
The Meson build system
Version: 0.64.1
Source dir: /Users/tgl/pgsql
Build dir: /Users/tgl/pgsql/build
Build type: native build
Project name: postgresql
Project version: 17devel

meson.build:9:0: ERROR: Unable to detect linker for compiler `cc -Wl,--version`
stdout:
stderr: ld: unknown options: --version
clang: error: linker command failed with exit code 1 (use -v to see invocation)

A full log can be found at /Users/tgl/pgsql/build/meson-logs/meson-log.txt
-----

That log file offers no more detail than the terminal output did.

(I also tried with a more recent meson version, 1.1.1, with
the same result.)

            regards, tom lane

Re: Annoying build warnings from latest Apple toolchain

From

Andres Freund

Date:

28 September 2023, 20:32:13

Hi,

On 2023-09-27 16:52:44 -0400, Tom Lane wrote:
> I wrote:
> > I've not yet looked at the meson build infrastructure to
> > see if it needs a corresponding change.
>
> I think it doesn't, as long as all the relevant build targets
> write their dependencies with "frontend_code" before "libpq".

Hm, that's not great. I don't think that should be required. I'll try to take
a look at why that's needed.


> However, it's hard to test this, because the meson build
> seems completely broken on current macOS:

I am travelling and I don't quite dare to upgrade my mac mini remotely. So I
can't try Sonoma directly.

But CI worked after switching to sonoma - although installing packages from
macports took forever, due to macports building all packages locally.

https://cirrus-ci.com/task/5133869171605504

There's some weird warnings about hashlib/blake2, but it looks like that's a
python installation issue. Looks like this is with python from macports in
PATH.

[00:59:14.442] ERROR:root:code for hash blake2b was not found.
[00:59:14.442] Traceback (most recent call last):
[00:59:14.442]   File "/opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/hashlib.py", line
307,in <module> 
[00:59:14.442]     globals()[__func_name] = __get_hash(__func_name)
[00:59:14.442]                              ^^^^^^^^^^^^^^^^^^^^^^^
[00:59:14.442]   File "/opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/hashlib.py", line
129,in __get_openssl_constructor 
[00:59:14.442]     return __get_builtin_constructor(name)
[00:59:14.442]            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[00:59:14.442]   File "/opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/hashlib.py", line
123,in __get_builtin_constructor 
[00:59:14.442]     raise ValueError('unsupported hash type ' + name)
[00:59:14.442] ValueError: unsupported hash type blake2b

This just happens whenever python's hashlib - supposedly in the standard
library - is imported.


There *are* some buildsystem warnings:
[00:59:27.289] [260/2328] Linking target src/interfaces/libpq/libpq.5.dylib
[00:59:27.289] ld: warning: -undefined error is deprecated
[00:59:27.289] ld: warning: ignoring -e, not used for output type

Full command:
[1/1] cc  -o src/interfaces/libpq/libpq.5.dylib src/interfaces/libpq/libpq.5.dylib.p/fe-auth-scram.c.o
src/interfaces/libpq/libpq.5.dylib.p/fe-auth.c.osrc/interfaces/libpq/libpq.5.dylib.p/fe-connect.c.o
src/interfaces/libpq/libpq.5.dylib.p/fe-exec.c.osrc/interfaces/libpq/libpq.5.dylib.p/fe-lobj.c.o
src/interfaces/libpq/libpq.5.dylib.p/fe-misc.c.osrc/interfaces/libpq/libpq.5.dylib.p/fe-print.c.o
src/interfaces/libpq/libpq.5.dylib.p/fe-protocol3.c.osrc/interfaces/libpq/libpq.5.dylib.p/fe-secure.c.o
src/interfaces/libpq/libpq.5.dylib.p/fe-trace.c.osrc/interfaces/libpq/libpq.5.dylib.p/legacy-pqsignal.c.o
src/interfaces/libpq/libpq.5.dylib.p/libpq-events.c.osrc/interfaces/libpq/libpq.5.dylib.p/pqexpbuffer.c.o
src/interfaces/libpq/libpq.5.dylib.p/fe-secure-common.c.osrc/interfaces/libpq/libpq.5.dylib.p/fe-secure-openssl.c.o
src/interfaces/libpq/libpq.5.dylib.p/fe-gssapi-common.c.osrc/interfaces/libpq/libpq.5.dylib.p/fe-secure-gssapi.c.o
-Wl,-dead_strip_dylibs-Wl,-headerpad_max_install_names -Wl,-undefined,error -shared -install_name @rpath/libpq.5.dylib
-compatibility_version5 -current_version 5.17 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.0.sdk -Og
-ggdb-Wl,-rpath,/opt/local/lib -Wl,-rpath,/opt/local/libexec/openssl3/lib src/common/libpgcommon_shlib.a
src/port/libpgport_shlib.a-exported_symbols_list=/Users/admin/pgsql/build/src/interfaces/libpq/exports.list -lm
/opt/local/lib/libintl.dylib/opt/local/lib/libgssapi_krb5.dylib /opt/local/lib/libldap.dylib
/opt/local/lib/liblber.dylib/opt/local/libexec/openssl3/lib/libssl.dylib
/opt/local/libexec/openssl3/lib/libcrypto.dylib/opt/local/lib/libz.dylib /opt/local/lib/libzstd.dylib 
ld: warning: -undefined error is deprecated
ld: warning: ignoring -e, not used for output type

So we need to make the addition of -Wl,-undefined,error conditional, that
should be easy enough. Although I'm a bit confused about this being
deprecated.

For the -e bit, this seems to do the trick:
@@ -224,7 +224,7 @@ elif host_system == 'darwin'
   library_path_var = 'DYLD_LIBRARY_PATH'

   export_file_format = 'darwin'
-  export_fmt = '-exported_symbols_list=@0@'
+  export_fmt = '-Wl,-exported_symbols_list,@0@'

   mod_link_args_fmt = ['-bundle_loader', '@0@']
   mod_link_with_dir = 'bindir'

It's quite annoying that apple is changing things option syntax.


> (I also tried with a more recent meson version, 1.1.1, with
> the same result.)

Looks like you need 1.2 for the new clang / ld output...  Apparently apple's
linker changed the format of its version output :/.

Greetings,

Andres Freund

Re: Annoying build warnings from latest Apple toolchain

From

Tom Lane

Date:

28 September 2023, 20:46:08

Andres Freund <andres@anarazel.de> writes:
> On 2023-09-27 16:52:44 -0400, Tom Lane wrote:
>> I think it doesn't, as long as all the relevant build targets
>> write their dependencies with "frontend_code" before "libpq".

> Hm, that's not great. I don't think that should be required. I'll try to take
> a look at why that's needed.

Well, it's only important on platforms where we can't restrict
libpq.so from exporting all symbols.  I don't know how close we are
to deciding that such cases are no longer interesting to worry about.
Makefile.shlib seems to know how to do it everywhere except Windows,
and I imagine we know how to do it over in the MSVC scripts.

>> However, it's hard to test this, because the meson build
>> seems completely broken on current macOS:

> Looks like you need 1.2 for the new clang / ld output...  Apparently apple's
> linker changed the format of its version output :/.

Ah, yeah, updating MacPorts again brought in meson 1.2.1 which seems
to work.  I now see a bunch of

ld: warning: ignoring -e, not used for output type
ld: warning: -undefined error is deprecated

which are unrelated.  There's still one duplicate warning
from the backend link:

ld: warning: ignoring duplicate libraries: '-lpam'

I'm a bit baffled why that's showing up; there's no obvious
double reference to pam.

            regards, tom lane

Re: Annoying build warnings from latest Apple toolchain

From

Andres Freund

Date:

28 September 2023, 22:22:48

Hi,

On 2023-09-28 16:46:08 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2023-09-27 16:52:44 -0400, Tom Lane wrote:
> >> I think it doesn't, as long as all the relevant build targets
> >> write their dependencies with "frontend_code" before "libpq".
> 
> > Hm, that's not great. I don't think that should be required. I'll try to take
> > a look at why that's needed.
> 
> Well, it's only important on platforms where we can't restrict
> libpq.so from exporting all symbols.  I don't know how close we are
> to deciding that such cases are no longer interesting to worry about.
> Makefile.shlib seems to know how to do it everywhere except Windows,
> and I imagine we know how to do it over in the MSVC scripts.

Hm, then I'd argue that we don't need to care about it anymore. The meson
build does the necessary magic on windows, as do the current msvc scripts.

I think right now it doesn't work as-is on sonoma, because apple decided to
change the option syntax, which is what causes the -e warning below, so the
relevant option is just ignored.

> There's still one duplicate warning
> from the backend link:
> 
> ld: warning: ignoring duplicate libraries: '-lpam'
> 
> I'm a bit baffled why that's showing up; there's no obvious
> double reference to pam.

I think it's because multiple libraries/binaries depend on it. Meson knows how
to deduplicate libraries found via pkg-config (presumably because that has
enough information for a topological sort), but apparently not when they're
found as "raw" libraries.  Until now that was also just pretty harmless, so I
understand not doing anything about it.

I see a way to avoid the warnings, but perhaps it's better to ask the meson
folks to put in a generic way of dealing with this.

Greetings,

Andres Freund

Re: Annoying build warnings from latest Apple toolchain

From

Tom Lane

Date:

28 September 2023, 22:58:49

Andres Freund <andres@anarazel.de> writes:
> On 2023-09-28 16:46:08 -0400, Tom Lane wrote:
>> Well, it's only important on platforms where we can't restrict
>> libpq.so from exporting all symbols.  I don't know how close we are
>> to deciding that such cases are no longer interesting to worry about.
>> Makefile.shlib seems to know how to do it everywhere except Windows,
>> and I imagine we know how to do it over in the MSVC scripts.

> Hm, then I'd argue that we don't need to care about it anymore. The meson
> build does the necessary magic on windows, as do the current msvc scripts.

If we take that argument seriously, then I'm inclined to adjust my
upthread patch for Makefile.global.in so that it removes the extra
inclusions of libpgport/libpgcommon everywhere, not only macOS.
The rationale would be that it's not worth worrying about ABI
stability details on any straggler platforms.

> I think right now it doesn't work as-is on sonoma, because apple decided to
> change the option syntax, which is what causes the -e warning below, so the
> relevant option is just ignored.

Hmm, we'd better fix that then.  Or is it their bug?  It looks to me like
clang's argument is -exported_symbols_list=/path/to/exports.list, so
it must be translating that to "-e".

            regards, tom lane

Re: Annoying build warnings from latest Apple toolchain

From

Tom Lane

Date:

28 September 2023, 23:17:37

I wrote:
> Andres Freund <andres@anarazel.de> writes:
>> I think right now it doesn't work as-is on sonoma, because apple decided to
>> change the option syntax, which is what causes the -e warning below, so the
>> relevant option is just ignored.

> Hmm, we'd better fix that then.  Or is it their bug?  It looks to me like
> clang's argument is -exported_symbols_list=/path/to/exports.list, so
> it must be translating that to "-e".

Looking closer, the documented syntax is

    -exported_symbols_list filename

(two arguments, not one with an "=").  That is what our Makefiles
use, and it still works fine with latest Xcode.  However, meson.build
thinks it can get away with one argument containing "=", and evidently
that doesn't work now (or maybe it never did?).

I tried

  export_fmt = '-exported_symbols_list @0@'

and

  export_fmt = ['-exported_symbols_list', '@0@']

and neither of those did what I wanted, so maybe I will have to
study meson's command language sometime soon.  In the meantime,
I suppose this might be an easy fix for somebody who knows their
way around meson.

            regards, tom lane

Re: Annoying build warnings from latest Apple toolchain

From

Andres Freund

Date:

29 September 2023, 02:20:27

Hi,

On 2023-09-28 19:17:37 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund <andres@anarazel.de> writes:
> >> I think right now it doesn't work as-is on sonoma, because apple decided to
> >> change the option syntax, which is what causes the -e warning below, so the
> >> relevant option is just ignored.
> 
> > Hmm, we'd better fix that then.  Or is it their bug?  It looks to me like
> > clang's argument is -exported_symbols_list=/path/to/exports.list, so
> > it must be translating that to "-e".
> 
> Looking closer, the documented syntax is
> 
>     -exported_symbols_list filename
> 
> (two arguments, not one with an "=").  That is what our Makefiles
> use, and it still works fine with latest Xcode.  However, meson.build
> thinks it can get away with one argument containing "=", and evidently
> that doesn't work now (or maybe it never did?).

It does still work on Ventura.

> I tried
> 
>   export_fmt = '-exported_symbols_list @0@'

That would expand to a single argument with a space inbetween.

> and
> 
>   export_fmt = ['-exported_symbols_list', '@0@']

That would work in many places, but not here, export_fmt is used as a format
string... We could make the callsites do that for each array element, but
there's an easier solution that seems to work for both Ventura and Sonoma -
however I don't have anything older to test with.

TBH, I find it hard to understand what arguments go to the linker and which to
the compiler on macos. The argument is documented for the linker and not the
compiler, but so far we'd been passing it to the compiler, so there must be
some logic forwarding it.

Looking through the clang code, I see various llvm libraries using
-Wl,-exported_symbols_list and there are tests
(clang/test/Driver/darwin-ld.c) ensuring both syntaxes work.

Thus the easiest fix looks to be to use this:

diff --git a/meson.build b/meson.build
index 5422885b0a2..16a2b0f801e 100644
--- a/meson.build
+++ b/meson.build
@@ -224,7 +224,7 @@ elif host_system == 'darwin'
   library_path_var = 'DYLD_LIBRARY_PATH'

   export_file_format = 'darwin'
-  export_fmt = '-exported_symbols_list=@0@'
+  export_fmt = '-Wl,-exported_symbols_list,@0@'

   mod_link_args_fmt = ['-bundle_loader', '@0@']
   mod_link_with_dir = 'bindir'

I don't have anything older than Ventura to check though.

Greetings,

Andres Freund

Re: Annoying build warnings from latest Apple toolchain

From

Andres Freund

Date:

29 September 2023, 02:33:15

Hi,

On 2023-09-28 19:20:27 -0700, Andres Freund wrote:
> Thus the easiest fix looks to be to use this:
> 
> diff --git a/meson.build b/meson.build
> index 5422885b0a2..16a2b0f801e 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -224,7 +224,7 @@ elif host_system == 'darwin'
>    library_path_var = 'DYLD_LIBRARY_PATH'
>  
>    export_file_format = 'darwin'
> -  export_fmt = '-exported_symbols_list=@0@'
> +  export_fmt = '-Wl,-exported_symbols_list,@0@'
>  
>    mod_link_args_fmt = ['-bundle_loader', '@0@']
>    mod_link_with_dir = 'bindir'
> 
> 
> I don't have anything older than Ventura to check though.

Attached is the above change and a commit to change CI over to Sonoma. Not
sure when we should switch, but it seems useful to include for testing
purposes at the very least.

Greetings,

Andres Freund

Hi,

On 2023-11-30 21:24:21 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2023-11-28 10:48:04 -0500, Robert Haas wrote:
> >> What a stupid, annoying decision on Apple's part. It seems like
> >> -Wl,-undefined,error is the default behavior, so they could have just
> >> ignored that flag if present, but instead they complain about being
> >> asked to do what they were going to do anyway.
> 
> > Especially because I think it didn't actually use to be the default when
> > building a dylib.
> 
> Indeed.  Whoever's in charge of their linker now seems to be quite
> clueless, or at least aggressively anti-backwards-compatibility.

It looks like it even affects a bunch of Apple's own products [1]...


> > While not helpful for this, I just noticed that there is
> > -no_warn_duplicate_libraries, which would at least get rid of the
> >   ld: warning: ignoring duplicate libraries: '-lxml2'
> > style warnings.
> 
> Oh!  If that's been there long enough to rely on, that does seem
> very helpful.

I think it's new too. But we can just check if the flag is supported.


This is really ridiculous. For at least part of venturas life they warned
about -Wl,-undefined,dynamic_lookup, which lead to 9a95a510adf3. They don't
seem to do that anymore, but now you can't specify -Wl,-undefined,error
anymore without a warning.


Attached is a prototype testing this via CI on both Sonoma and Ventura.


It's certainly possible to encounter the duplicate library issue with
autoconf, but probably not that common. So I'm not sure if we should inject
-Wl,-no_warn_duplicate_libraries as well?

Greetings,

Andres Freund


[1] https://developer.apple.com/forums/thread/733317

Attachment

v3-0001-meson-Improve-Sonoma-compability.patch

Re: Annoying build warnings from latest Apple toolchain

From

Andres Freund

Date:

09 April 2024, 17:53:37

Hi,

Looks like I forgot to update the thread to note that I finally committed the
remaining warning fixes. I had already fixed a bunch of others in upstream
meson.

commit a3da95deee38ee067b0bead639c830eacbe894d5
Author: Andres Freund <andres@anarazel.de>
Date:   2024-03-13 01:40:53 -0700

    meson: macos: Avoid warnings on Sonoma

Greetings,

Andres Freund

Re: Annoying build warnings from latest Apple toolchain

From

Mikael Sand

Date:

10 October 2024, 20:54:13

Good day!

I'm encountering a build issue with postgresql 17, I wonder if this was an intentional consequence of this commit: https://github.com/postgres/postgres/commit/b6c7cfac88c47a9194d76f3d074129da3c46545a

Or if this was unintentional. Or is there any way to compile pgcommon with the correct function names statically into libpq?

https://www.postgresql.org/message-id/CAAwAxZf456NwLKD4ZBpyDmPc5GFmGP%3Db5Vw7pTMY0v9R-%3D%2BDTA%40mail.gmail.com

This works with 16.4 but fails with 17.0:

FROM postgres:16.4-alpine3.20 AS builder
USER root
WORKDIR /app
RUN apk update && apk add --no-cache --update-cache \
    openssl-libs-static \
    libevent-static \
    libxml2-static \
    libedit-static \
    libxslt-static \
    sqlite-static \
    openldap-dev \
    libxslt-dev \
    libxml2-dev \
    libedit-dev \
    openssl-dev \
    zstd-static \
    zlib-static \
    lz4-static \
    e2fsprogs \
    keyutils \
    zstd-dev \
    zlib-dev \
    gdbm-dev \
    clang17 \
    lz4-dev \
    libldap \
    bison \
    curl \
    perl \
    make

COPY <<EOF ./main.cpp
#include<libpq-fe.h>
int main(){return PQconnectdb("")==NULL;}
EOF

ARG KRB5=1.21.3
ARG KRB5MAJMIN=1.21
RUN curl -L https://kerberos.org/dist/krb5/$KRB5MAJMIN/krb5-$KRB5.tar.gz | tar xzf -
RUN cd krb5-$KRB5/src && \
    ./configure && make && make install && \
    ./configure --disable-shared --enable-static && make && make install

ARG SASL=2.1.28
RUN curl -L https://github.com/cyrusimap/cyrus-sasl/releases/download/cyrus-sasl-$SASL/cyrus-sasl-$SASL.tar.gz | tar xzf -
RUN cd cyrus-sasl-$SASL && ./configure --enable-static && make && make install

RUN clang++ -static -o main main.cpp \
    -L/usr/local/lib -lpq -lpgcommon -lpgport \
    -lldap -lsasl2 -lssl -lcrypto -llber \
    -lgssapi_krb5 \
    -lkrb5 -lk5crypto -lcom_err -lkrb5support \
    -lgdbm

Best regards

Mikael Sand