Thread
-
More on shared objects problem
D'Arcy Cain <darcy@druid.net> — 1999-07-27T12:12:19Z
Many thanks to everyone who helped so far especially Todd Vierling for the RTFF. I think I am closer but I still have a problem. Here is the rule in my makefile now. .o.so: ld -shared -L${PGDIR}/lib --export-dynamic -rpath ${PGDIR}/lib \ -lpq -lc -o $@ $< ldd now shows this. glaccount.so: -lpq => /usr/pgsql/lib/libpq.so -lc.12 => /usr/lib/libc.so.12 I then went into the PostgreSQL code and added a dlerror() call to the error message after dlopen(). I still get an error but now I get a little more information. ERROR: Load of file /usr/pgsql/modules/glaccount.so failed: dlopen (/usr/pgsql/modules/glaccount.so) failed (/usr/pgsql/modules/glaccount.so: Undefined symbol "CurrentMemoryContext" (reloc type = 6, symnum = 6)) CurrentMemoryContext is defined in the postmaster (I checked with nm) which is the program doing the dlopen. Here is the relevant line from nm. 08138544 D CurrentMemoryContext So it looks like everything should be working but it doesn't. Is this possibly a case of bogus error message or am I misunderstanding it? Is ELF fully baked or do I need to revert to a pre-ELF system? Hmm. I just noticed that nm is an old binary and that it doesn't build from current sources due to a missing bfd.h. Is nm like ldconfig and not needed any more on ELF systems or is there just a problem with the current sources? -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner. -
Re: More on shared objects problem
Todd Vierling <tv@pobox.com> — 1999-07-27T13:04:58Z
On Tue, 27 Jul 1999, D'Arcy J.M. Cain wrote: : Many thanks to everyone who helped so far especially Todd Vierling for : the RTFF. I think I am closer but I still have a problem. Here is the : rule in my makefile now. : : .o.so: : ld -shared -L${PGDIR}/lib --export-dynamic -rpath ${PGDIR}/lib \ : -lpq -lc -o $@ $< --export-dynamic is only needed for _executables_. It is implied for shared objects. BTW, for platform compatibility, may I suggest using -R instead of -rpath... that works on all NetBSD, a.out and ELF, linkers (and even some non-NetBSD ones :). : ERROR: Load of file /usr/pgsql/modules/glaccount.so failed: dlopen (/usr/pgsql/modules/glaccount.so) failed (/usr/pgsql/modules/glaccount.so: Undefined symbol "CurrentMemoryContext" (reloc type = 6, symnum = 6)) : : CurrentMemoryContext is defined in the postmaster (I checked with nm) which : is the program doing the dlopen. Here is the relevant line from nm. ...and you don't have --export-dynamic on your _executable's_ link line. When linking the executable whose symbols will be used by a shared object, use: cc -Wl,-E ... (which is equivalent, from the cc side). : Hmm. I just noticed that nm is an old binary and that it doesn't build : from current sources due to a missing bfd.h. You need the sources of src/gnu/lib/libbfd and src/gnu/dist/{opcodes,bfd,libiberty} in order to build any libbfd using program. This is because there are a lot of internal bfd headers used by these programs. However, there is nothing wrong with your nm. -- -- Todd Vierling (tv@pobox.com) -
Re: More on shared objects problem
D'Arcy Cain <darcy@druid.net> — 1999-07-27T17:08:56Z
Thus spake Todd Vierling > On Tue, 27 Jul 1999, D'Arcy J.M. Cain wrote: > : ld -shared -L${PGDIR}/lib --export-dynamic -rpath ${PGDIR}/lib \ > : -lpq -lc -o $@ $< > > --export-dynamic is only needed for _executables_. It is implied for shared > objects. So I have been told. Removing it didn't help though. > BTW, for platform compatibility, may I suggest using -R instead of -rpath... > that works on all NetBSD, a.out and ELF, linkers (and even some non-NetBSD > ones :). OK, I did that. > ...and you don't have --export-dynamic on your _executable's_ link line. > When linking the executable whose symbols will be used by a shared object, > use: > > cc -Wl,-E ... Hmm. OK, I'll try to get that into the PostgreSQL code. Is that flag benign on a non-ELF system or do I have to test for ELF before adding the flag? > You need the sources of src/gnu/lib/libbfd and > src/gnu/dist/{opcodes,bfd,libiberty} in order to build any libbfd using > program. This is because there are a lot of internal bfd headers used by > these programs. However, there is nothing wrong with your nm. I just realized that I have not been supping gnu files. Didn't someone say here that src/gnu was now included in /src? I supped the current gnu down and will rebuild the world but I will try the -E first. Bingo! That was it. OK, I'll see that the change gets back into PostgreSQL. Hmmm. Looking at the code I see that it does expect to add that flag if it is on an ELF system. I guess configure needs to be tweaked. I'll copy (and set followups to) the PostgreSQL list to start discussions there on that. So how do we determine that a system is elf? I don't see it in uname. Do we just run file(1) on the kernel and see if the string "ELF" shows up? Many thanks for everyone's help. -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner. -
Re: More on shared objects problem
Todd Vierling <tv@pobox.com> — 1999-07-27T18:00:28Z
On Tue, 27 Jul 1999, D'Arcy J.M. Cain wrote: (Note that pgsql-hackers is not in my To: header, as I'm not on the list and cannot post.) : So how do we determine that a system is elf? I don't see it in uname. Do : we just run file(1) on the kernel and see if the string "ELF" shows up? On NetBSD, the following will do it. This may even be platform independednt if "grep -q" is replaced by "grep >/dev/null 2>&1". if echo __ELF__ | ${CC} -E - | grep -q __ELF__; then ... a.out action ... else ... ELF action ... fi -- -- Todd Vierling (tv@pobox.com) -
Re: [HACKERS] Re: More on shared objects problem
Mark Hollomon <mhh@nortelnetworks.com> — 1999-07-27T18:35:13Z
D'Arcy J.M. Cain wrote: > > So how do we determine that a system is elf? I don't see it in uname. Do > we just run file(1) on the kernel and see if the string "ELF" shows up? The test I use is to compile a program that opens its own executable and checks for the magic number. \127ELF as I remember. -- Mark Hollomon mhh@nortelnetworks.com ESN 451-9008 (302)454-9008
-
Re: [HACKERS] Re: More on shared objects problem
Thilo Manske <thilo.manske@heh.uni-oldenburg.de> — 1999-07-27T18:41:08Z
On Tue, Jul 27, 1999 at 02:35:13PM -0400, Mark Hollomon wrote: > D'Arcy J.M. Cain wrote: > > So how do we determine that a system is elf? I don't see it in uname. Do > > we just run file(1) on the kernel and see if the string "ELF" shows up? > > The test I use is to compile a program that opens its own executable > and checks for the magic number. Or this: if echo __ELF__ | ${CC} -E - | grep -q __ELF__; then # ELF else # a.out fi This is not my idea, it's from the patches for apache in the package tree. -- Dies ist Thilos Unix Signature! Viel Spass damit. -
Re: [HACKERS] Re: More on shared objects problem
Todd Vierling <tv@pobox.com> — 1999-07-27T19:04:34Z
On Tue, 27 Jul 1999, Thilo Manske wrote: : if echo __ELF__ | ${CC} -E - | grep -q __ELF__; then : # ELF : else : # a.out : fi : : This is not my idea, it's from the patches for apache in the package tree. It's actually backwards. If the "grep -q" returns true, it's an a.out system (since cpp did *not* replace __ELF__ with 1). -- -- Todd Vierling (tv@pobox.com)