This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: glibc-2.0.99 build problems
- To: "Jack Howarth" <howarth@bromo.med.uc.edu>
- Subject: Re: glibc-2.0.99 build problems
- From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
- Date: Sun, 1 Nov 1998 21:16:02 +0100 (CET)
- Cc: libc-alpha@cygnus.com
- References: <9811011211.ZM2127@bromo.med.uc.edu>
>>>>> Jack Howarth writes:
Jack> Andreas.
Jack> Thanks again. The modified version of Uli's test code works exactly
Jack> as you indicated. I see...
Jack> [root@dilbert newtest]# LD_LIBRARY_PATH=. ./m
Jack> This is main
Jack> This is foo
Jack> This is bar
Jack> ./p.so: undefined symbol: xyzzy
Jack> I have been told that the ld.so.1 in glibc 2.1 will be (and is) much
Jack> stricter than that in 2.0.7 and below. I think the next step is to
Jack> get someone running glibc 2.0.7 to test your modified code. If my
Jack> guess is right then it should pass the modified test on glibc 2.0.7.
Jack> The question then becomes which is correct behavior...does the test
Jack> just happen to work in glibc 2.0.7 and should that coding be allowed?
Jack> Or is glibc 2.0.99 being to strict about exporting symbols back to
Jack> the original program when one of the intervening shared libs is linked
Jack> rather then accessed via dlopen.
Jack
following your suggestion, I tested the code on an alpha running glibc
2.0.7-13 from RedHat (installed in May) and it works:
$ LD_LIBRARY_PATH=. ./m
This is main
This is foo
This is bar
This is baz
This is xyzzy
Therefore my question remains: Is the program I've written correct
and should it work with glibc 2.0.99? Or does it just work by
accident with 2.0.7?
Andreas
--
Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de