Apple's ranlib warns about protocol_openssl.c

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