Thread: pgsql/src Makefile.shlib
CVSROOT: /home/projects/pgsql/cvsroot
Module name: pgsql
Changes by: tgl@hub.org 01/03/10 18:15:20
Modified files:
src : Makefile.shlib
Log message:
Turns out the HPUX linker likes -Bsymbolic too. Without this, ODBC
driver does not work because its internal cross-references get bound
to similarly named functions in unixODBC shared library.
Tom Lane writes: > Modified files: > src : Makefile.shlib > > Log message: > Turns out the HPUX linker likes -Bsymbolic too. Without this, ODBC > driver does not work because its internal cross-references get bound > to similarly named functions in unixODBC shared library. You probably want to define this in Makefile.hpux (compare to Makefile.linux for example), unless you want to link *all* shared libraries this way. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> You probably want to define this in Makefile.hpux (compare to
> Makefile.linux for example), unless you want to link *all* shared
> libraries this way.
Hm. I don't see a reason not to do all our shlibs that way;
it seems to me that being able to break a shlib by means of
an accidental conflict with one of its internal function names
is a Bad Thing.
But I suppose it's probably best to treat HPUX as much like the
other platforms as possible. Will change, unless I can talk you
into changing all the rest.
regards, tom lane
> Peter Eisentraut <peter_e@gmx.net> writes: > > You probably want to define this in Makefile.hpux (compare to > > Makefile.linux for example), unless you want to link *all* shared > > libraries this way. > > Hm. I don't see a reason not to do all our shlibs that way; > it seems to me that being able to break a shlib by means of > an accidental conflict with one of its internal function names > is a Bad Thing. > > But I suppose it's probably best to treat HPUX as much like the > other platforms as possible. Will change, unless I can talk you > into changing all the rest. Peter made the same suggestion for me for BSDI, and it made sense once I saw it. It put all the OS-specific stuff in separate files. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Tom Lane writes: > Hm. I don't see a reason not to do all our shlibs that way; > it seems to me that being able to break a shlib by means of > an accidental conflict with one of its internal function names > is a Bad Thing. I don't know why this is a feature, let alone the default, but this doesn't seem like the time to find out. After all ELF is a pretty widely used format these days and everybody links their libraries this way. I actually had to use -Bsymbolic in another project because of conflicts, but the whole build ended up being very noisy and broke for obscure reasons. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> You probably want to define this in Makefile.hpux (compare to
> Makefile.linux for example), unless you want to link *all* shared
> libraries this way.
I tried this and realized that it does not work unless I make
shlib_symbolic = -Bsymbolic
rather than
shlib_symbolic = -Wl,-Bsymbolic
as is done on all the other platforms that define this symbol.
Reason: we build shlibs by invoking the linker directly, not
via the compiler, on HPUX.
AFAICT, our practice for the other platforms that invoke the linker
directly is to include options directly into the LINK.shared macro;
see for example the *bsd and sunos4 entries in Makefile.shlib.
These examples are why I added -Bsymbolic to HPUX's LINK.shared in the
first place, and I'm now inclined to leave it that way. Comments?
regards, tom lane
Tom Lane writes:
> I tried this and realized that it does not work unless I make
> shlib_symbolic = -Bsymbolic
> rather than
> shlib_symbolic = -Wl,-Bsymbolic
> as is done on all the other platforms that define this symbol.
> Reason: we build shlibs by invoking the linker directly, not
> via the compiler, on HPUX.
This is fine. Different platforms, different habits.
> AFAICT, our practice for the other platforms that invoke the linker
> directly is to include options directly into the LINK.shared macro;
LINK.shared should include the command line necessary to link a shared
library, no matter if the linker, the compiler driver, or what else is
running behind the scenes. On a GCC/ELF platform it may be simply
$(CC) -shared
on others it can invoke the linker with special options or what not.
> see for example the *bsd and sunos4 entries in Makefile.shlib.
Note that in sunos
$(LD) -assert pure-text -Bdynamic
the -Bdynamic option is not the same as the -Bsymbolic option. -Bdynamic
simply means "create a shared library". (Not sure about the -assert
thing, I think it ensures that the library is somewhat self contained.)
Also, the *bsd lines you might be referring to
$(LD) -x -Bshareable -Bforcearchive
the -Bshareable is the flag to make a shared library, -Bforcearchive is
completely unnecessary, and -x says "Discard all local symbols in the
input files.", whatever that may mean. (In fact, I'm fairly convinced
that this is not the recommended way to link shared libraries on these
systems, but I don't have enough enthusiasm to amend this.)
> These examples are why I added -Bsymbolic to HPUX's LINK.shared in the
> first place, and I'm now inclined to leave it that way. Comments?
Well, this is not really related. Makefile.shlib and LINK.shared say
"link a shared library in some default way". The shlib_symbolic macro
says "link a shared library in some other way". Now you can postulate the
"other way" to be the new "default way", but at least that's how the setup
is.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> Also, the *bsd lines you might be referring to > > $(LD) -x -Bshareable -Bforcearchive > > the -Bshareable is the flag to make a shared library, -Bforcearchive is > completely unnecessary, and -x says "Discard all local symbols in the > input files.", whatever that may mean. (In fact, I'm fairly convinced > that this is not the recommended way to link shared libraries on these > systems, but I don't have enough enthusiasm to amend this.) I seem to remember someone saying it was needed to like later stuff, like ODBC? I am not sure myself. Some OS's had it, other's didn't. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026