Thread: Apple's ranlib warns about protocol_openssl.c
Hi, Apple's ranlib doesn't like empty translation units[1], but protocol_openssl.c doesn't define any symbols (unless you have an ancient EOL'd openssl), so longfin and CI say: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libpgcommon.a(protocol_openssl.o) has no symbols I guess we still can't switch to (Apple) libtool. Maybe configure should be doing a test and adding it to LIBOBJS or a similar variable only if necessary, or something like that? [1] https://www.postgresql.org/message-id/flat/28521.1426352337%40sss.pgh.pa.us
Thomas Munro <thomas.munro@gmail.com> writes:
> Apple's ranlib doesn't like empty translation units[1], but
> protocol_openssl.c doesn't define any symbols (unless you have an
> ancient EOL'd openssl), so longfin and CI say:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
> file: libpgcommon.a(protocol_openssl.o) has no symbols
> I guess we still can't switch to (Apple) libtool. Maybe configure
> should be doing a test and adding it to LIBOBJS or a similar variable
> only if necessary, or something like that?
Hmm ... right now, with only one test to make, the configure change
wouldn't be that hard; but that might change in future, plus I'm
unsure how to do it in MSVC.
A lazy man's answer could be to ensure the translation unit isn't
empty, say by adding
+#else
+
+int dummy_protocol_openssl_variable = 0;
+
#endif /* !SSL_CTX_set_min_proto_version */
regards, tom lane
On 16.12.21 16:25, Tom Lane wrote: > Thomas Munro <thomas.munro@gmail.com> writes: >> Apple's ranlib doesn't like empty translation units[1], but >> protocol_openssl.c doesn't define any symbols (unless you have an >> ancient EOL'd openssl), so longfin and CI say: > >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: >> file: libpgcommon.a(protocol_openssl.o) has no symbols > >> I guess we still can't switch to (Apple) libtool. Maybe configure >> should be doing a test and adding it to LIBOBJS or a similar variable >> only if necessary, or something like that? > > Hmm ... right now, with only one test to make, the configure change > wouldn't be that hard; but that might change in future, plus I'm > unsure how to do it in MSVC. > > A lazy man's answer could be to ensure the translation unit isn't > empty, say by adding These are not errors, right? So why is this a problem?
On Fri, Dec 17, 2021 at 4:48 AM Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: > These are not errors, right? So why is this a problem? Yeah they're just warnings. I don't personally care if we just ignore them until we drop OpenSSL < 1.1.0 or macOS < 10.something. I mentioned it because in the past we worked to get rid of these sorts of warnings (there have been a couple of rounds at least), and they show up more obviously in the CI scripts because they use -s, so the 3 warning lines are the only output.
Thomas Munro <thomas.munro@gmail.com> writes:
> On Fri, Dec 17, 2021 at 4:48 AM Peter Eisentraut
> <peter.eisentraut@enterprisedb.com> wrote:
>> These are not errors, right? So why is this a problem?
> Yeah they're just warnings. I don't personally care if we just ignore
> them until we drop OpenSSL < 1.1.0 or macOS < 10.something. I
> mentioned it because in the past we worked to get rid of these sorts
> of warnings (there have been a couple of rounds at least), and they
> show up more obviously in the CI scripts because they use -s, so the 3
> warning lines are the only output.
Yeah, "zero chatter from a successful build" has been a goal
for awhile now.
Having said that, I'm not seeing any such warning when I build
with openssl 1.1.1k on my own Mac, so I'm a bit confused why
Thomas sees it.
regards, tom lane
> On 16 Dec 2021, at 19:22, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Having said that, I'm not seeing any such warning when I build > with openssl 1.1.1k on my own Mac, so I'm a bit confused why > Thomas sees it. Maybe it's dependant on macOS/XCode release? I see the warning on my Catalina laptop. -- Daniel Gustafsson https://vmware.com/
Daniel Gustafsson <daniel@yesql.se> writes:
>> On 16 Dec 2021, at 19:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Having said that, I'm not seeing any such warning when I build
>> with openssl 1.1.1k on my own Mac, so I'm a bit confused why
>> Thomas sees it.
> Maybe it's dependant on macOS/XCode release? I see the warning on my Catalina
> laptop.
Could be. I tried it on Monterey, but not anything older.
(longfin is still on Big Sur, because I've been lazy about
updating it.)
regards, tom lane
On Fri, Dec 17, 2021 at 9:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Daniel Gustafsson <daniel@yesql.se> writes: > >> On 16 Dec 2021, at 19:22, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Having said that, I'm not seeing any such warning when I build > >> with openssl 1.1.1k on my own Mac, so I'm a bit confused why > >> Thomas sees it. > > > Maybe it's dependant on macOS/XCode release? I see the warning on my Catalina > > laptop. > > Could be. I tried it on Monterey, but not anything older. > (longfin is still on Big Sur, because I've been lazy about > updating it.) Hmm. Happened[1] with Andres's CI scripts, which (at least on the version I used here, may not be his latest) runs on macOS Monterey and installs openssl from brew which is apparently 3.0.0. Wild guess: some versions of openssl define functions, and some define macros, and here we're looking for the macros? https://cirrus-ci.com/task/6100205941555200
Hi, On 2021-12-17 14:26:53 +1300, Thomas Munro wrote: > On Fri, Dec 17, 2021 at 9:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Could be. I tried it on Monterey, but not anything older. > > (longfin is still on Big Sur, because I've been lazy about > > updating it.) > > Hmm. Happened[1] with Andres's CI scripts, which (at least on the > version I used here, may not be his latest) runs on macOS Monterey and > installs openssl from brew which is apparently 3.0.0. Wild guess: > some versions of openssl define functions, and some define macros, and > here we're looking for the macros? I also see it on an m1 mini I got when building against openssl 3. There is -no_warning_for_no_symbols in apple's ranlib. But perhaps there's another way around this: We have ssl_protocol_version_to_openssl() in both be-secure-openssl.c and fe-secure-openssl.c. Perhaps we should just move it to protocol_openssl.c? Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes:
> I also see it on an m1 mini I got when building against openssl 3.
Huh, I wonder why I'm not seeing it.
> There is -no_warning_for_no_symbols in apple's ranlib. But perhaps
> there's another way around this:
> We have ssl_protocol_version_to_openssl() in both be-secure-openssl.c
> and fe-secure-openssl.c. Perhaps we should just move it to
> protocol_openssl.c?
Those functions have the same name, but not the same arguments,
so it'd take some refactoring to share any code.
regards, tom lane
Hi,
On 2021-12-16 21:13:20 +0100, Daniel Gustafsson wrote:
> > On 16 Dec 2021, at 19:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > Having said that, I'm not seeing any such warning when I build
> > with openssl 1.1.1k on my own Mac, so I'm a bit confused why
> > Thomas sees it.
>
> Maybe it's dependant on macOS/XCode release? I see the warning on my Catalina
> laptop.
I think it might an x86_64 vs arm64 thing.
cd ~/build/postgres/dev-assert/vpath/src/common
$ cat protocol_openssl.s
.section __TEXT,__text,regular,pure_instructions
.build_version macos, 12, 0 sdk_version 12, 3
.subsections_via_symbols
$ as -arch arm64 protocol_openssl.s -o protocol_openssl-arm64.o
$ as -arch x86_64 protocol_openssl.s -o protocol_openssl-x86_64.o
$ llvm-objdump -t protocol_openssl-x86_64.o
protocol_openssl-x86_64.o: file format mach-o 64-bit x86-64
SYMBOL TABLE:
$ llvm-objdump -t protocol_openssl-arm64.o
protocol_openssl-arm64.o: file format mach-o arm64
SYMBOL TABLE:
0000000000000000 l F __TEXT,__text ltmp0
For some reason arm64 ends up with that ltmp0 symbol, which presumably
prevents the warning from being triggered.
Greetings,
Andres Freund