atom feed22 messages in org.freebsd.freebsd-currentRe: ELF ldconfig
FromSent OnAttachments
Joe AbleySep 19, 1998 9:27 am 
Terry LambertSep 19, 1998 10:24 am 
Joe AbleySep 19, 1998 10:38 am 
Joe AbleySep 19, 1998 10:45 am 
Terry LambertSep 19, 1998 10:49 am 
John PolstraSep 19, 1998 1:32 pm 
Joe AbleySep 19, 1998 4:16 pm 
Mark HuizerSep 19, 1998 4:36 pm 
Joe AbleySep 19, 1998 6:33 pm 
Dan NelsonSep 19, 1998 8:13 pm 
David HollandSep 19, 1998 9:00 pm 
Joe AbleySep 19, 1998 10:02 pm 
Peter WemmSep 20, 1998 12:50 am 
Terry LambertSep 20, 1998 2:29 am 
Terry LambertSep 20, 1998 2:48 am 
David HollandSep 20, 1998 10:55 am 
David HollandSep 20, 1998 11:04 am 
Terry LambertSep 20, 1998 2:24 pm 
David HollandSep 20, 1998 4:39 pm 
Terry LambertSep 21, 1998 1:17 am 
David HollandSep 21, 1998 11:30 am 
David HollandSep 24, 1998 1:58 pm 
Subject:Re: ELF ldconfig
From:David Holland (dhol@cs.toronto.edu)
Date:Sep 20, 1998 11:04:51 am
List:org.freebsd.freebsd-current

Right now, it's possbile to link against a shared library that requires a symbol from anothe shared library, and not get any missing symbol warnings during link phase. This has bit me on the butt more than once, especially with libraries with promiscuous symbol reference in other libraries (ie: libraries that know too much about each other).

You can also, I think, inadvertently create a shared library that requires nonexistent symbols and not get any warnings until run-time. Which (I think) amounts to the same problem, because the library requiring a symbol from another library should have been linked against that library to create a DT_NEEDED entry. I think.

There's a linker option to use when building libraries that eliminates this problem. In my opinion, it should be the default, but it's not, because that's not how Solaris does it or some crap like that.

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message