Re: Apple's ranlib warns about protocol_openssl.c - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Apple's ranlib warns about protocol_openssl.c
Date
Msg-id 3f72b209-7478-6f72-d5db-bd2b143931a4@enterprisedb.com
Whole thread Raw
In response to Re: Apple's ranlib warns about protocol_openssl.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Apple's ranlib warns about protocol_openssl.c  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
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?



pgsql-hackers by date:

Previous
From: Joshua Brindle
Date:
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Next
From: Andrew Dunstan
Date:
Subject: Re: [PATCH] Accept IP addresses in server certificate SANs