Re: [HACKERS] ranlib bleating about dirmod.o being empty
On 3/17/15 12:51 PM, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: It looks like ar isn't even the preferred method to build static libraries on OS X anymore. Instead, one should use libtool (not GNU libtool), which has a -no_warning_for_no_symbols option. I looked into this a little bit, but that option seems to be a somewhat recent innovation; at least the libtool on my 10.6 (Snow Leopard) buildfarm critter doesn't recognize it. Yeah, that's what I was unsure about. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ranlib bleating about dirmod.o being empty
Peter Eisentraut pete...@gmx.net writes: It looks like ar isn't even the preferred method to build static libraries on OS X anymore. Instead, one should use libtool (not GNU libtool), which has a -no_warning_for_no_symbols option. I looked into this a little bit, but that option seems to be a somewhat recent innovation; at least the libtool on my 10.6 (Snow Leopard) buildfarm critter doesn't recognize it. We might be able to adopt it in a couple more years when nobody cares about such old OS X releases. In the meantime, though, reclassifying dirmod.o solves the problem so I don't feel a need to have an argument about dropping support for old releases. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ranlib bleating about dirmod.o being empty
On 3/14/15 12:58 PM, Tom Lane wrote: I'm getting rather tired of reading these warning messages in OS X builds: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libpgport.a(dirmod.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libpgport_srv.a(dirmod_srv.o) has no symbols The reason for this warning is that dirmod.o contains no functions that aren't Windows-specific. As such, it seems like putting it into the list of always compiled port modules is really a mistake. Any objections to switching it to be built only on Windows? It looks like ar isn't even the preferred method to build static libraries on OS X anymore. Instead, one should use libtool (not GNU libtool), which has a -no_warning_for_no_symbols option. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ranlib bleating about dirmod.o being empty
On Sun, Mar 15, 2015 at 1:58 AM, Tom Lane t...@sss.pgh.pa.us wrote: I'm getting rather tired of reading these warning messages in OS X builds: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libpgport.a(dirmod.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libpgport_srv.a(dirmod_srv.o) has no symbols The reason for this warning is that dirmod.o contains no functions that aren't Windows-specific. As such, it seems like putting it into the list of always compiled port modules is really a mistake. Any objections to switching it to be built only on Windows? +1. Thanks for changing that. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ranlib bleating about dirmod.o being empty
I'm getting rather tired of reading these warning messages in OS X builds: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libpgport.a(dirmod.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libpgport_srv.a(dirmod_srv.o) has no symbols The reason for this warning is that dirmod.o contains no functions that aren't Windows-specific. As such, it seems like putting it into the list of always compiled port modules is really a mistake. Any objections to switching it to be built only on Windows? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
