> On Wed, Apr 01, 1998 at 10:24:46AM +0100, Mark Phillips wrote:
> > Sorry to bother you if you are not the correct people to talk to!
> >
> > I'm not sure who I should email:-(
>
> Me (ld.so maintainer) and RedHat.
Great!
Thanks for getting back to me.
Any idea who the relevent redhat person is, I can't find an email addr
for reporting bugs (or contributing fixes) if you haven't got support!
>
> > I have encountered a problem, AND come up with a patch, with the dynamic
> > linker code.
> >
> > The problem is that when I'm using RedHat 5.0, with latest patches
> > from RedHat (including ldconfig-1.9.5-2.rpm), ld.so is loading a
> > mixture of libc5 and libc6(glibc) libs!
>
> This is because RedHat doesn't tag their libraries appropriately and
> uses -rpath. Both can cause the problem you have.
Yes and no, actually the libs causing the problem are NOT from RedHat,
they are from the binary XFree distribution (not an rpm).
>
> > Now the redhat ldconfig/ld.so has been patched so ldconfig records the
> > libc version in the cache against each lib, if it can deduce it, and
> > ld.so then tries to load a consistent set of libs.
>
> Wrong. RedHat didn't patch ldconfig to record the libc version in the
> cache. That change was added by me in version 1.9.0. What RedHat did
Sorry I was not intending to misdirect credit for the patch.
> was modify ld.so to move the -rpath search to after the cache search.
> This is non-standard and was done by RedHat only instead of fixing the
Yep, I thought it was pretty yucky (and I assumed it was done by
redhat, not the owner of the package).
Redhat's patch is also not needed with my patch...
> real causes of the problems (i.e. the one listed above).
>
> > BUT, I found that XEmacs was picking up a mixture of libc5 and libc6(glibc)
> > libs because the XFree libs (and others) did not have enough info for
> > ldconfig to work out their libc version (it gets some libc5 libs
> > because they are earlier in the path and do not have libc version info
> > - - of course the same problem hits different apps if I change the
> > path).
> >
> > My enclosed patch allows you to specify the expected lib type for
> > directories in ld.so.conf (/usr/X11R6/lib=LIB_ELF_LIBC6 for example), then
> > libs it can't work out get tagged anyway. Appropriate warnings are also
> > issued.
>
> Your patch didn't come through, at least on the linux-kernel-digest
OK I can resend it.
> list. I should warn you though that I will very reluctant to add it
> though. I'd much rather see people properly tag their libraries.
I would REALLY, like it (or something better) to be used, my arguments
"for" are as follows:-
1) The average user will NOT notice when they get a mixed set of libs
- they will just get very obscure errors.
2) The problem is not redhat specific, it applies to any dynamic lib
built without a -lc, but pre-existing, and future mistakes from other
platforms where it doesn't matter.
3) I KNOW what type of libs are in my libdirs, in particular the libc5
libs kept arround for compatibility, and your code will make it
obvious if someone gets the config file wrong.
Basically, the patch is small and robust and nails the problem close
to source (ok the real source of the problem is the libc change, but
ld.so is close).
Could you please email me and let me know if you are prepared to
consider using my patch - if you are could you please let me know
where I can get an uptodate development copy of ldconfig so I can do a
patch relative to that (and do a patch for the man page , which I
haven't bothered with yet).
Yours Faithfully
Mark Phillips
>
> > Now what should I do with the patch!
> >
> > Does anyone want a copy, or know who I should email it to?
>
> Send it to me.
>
> David
> --
> David Engel ODS Networks
> david@sw.ods.com 1001 E. Arapaho Road
> (972) 234-6400 Richardson, TX 75081
>
Mark S. Phillips ESN 742 2461
msp@nortel.co.uk Tel. +44 1279 402461
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu