Re: Putty or libcrypto bug?

On 2004-11-23 19:59, Wiktor Niesiobedzki <bsd_at_w.evip.pl> wrote:
>On Tue, Nov 23, 2004 at 08:39:30PM +0200, Giorgos Keramidas wrote:
>> This is a Bad Idea(TM) most of the time though.  The library
>> implements a function that other programs or libraries may depend upon
>> to work in certain ways.  Replacing the library function with a
>> hand-rolled version may or may not work -- the latter in this case :-/
>
> Should'nt libc load nss_ldap with kind of RTLD_LOCAL, so the libc will load
> libldap in another symbol-space so symbol lookups will not end in main
> program (if it is at all possible... I'm not familiar with dynamic linking)?

What happens if parts of the program want to access symbols from many
disjoint namespaces?  If a program links to two shared objects:
libfoo.so.1 and libmore.2, which in turn depend on other shared objects,
for example:

	program
		libfoo.so.1
			libtest.so.3
		libmore.so.2
			libtmp.so.4
				libthread.so.5

and libmore _does_ want to override thread_create() from libthread.so.5
but libtmp.so.4 wants only the original thread_create() function from
libthread.so.5, which function will the runtime linker call when
`program' calls thread_create()?

> If not, then it is the fact, that programmer of any program should
> aviod duplicating function names across every library that may
> eventually be installed and somehow linked to this programm, what
> sounds rather ridiculous to me.

I don't think there is support for multiple symbol namespaces in C.
This is probably why most of the utilities in the src/ tree export as
few symbols as possible; many times just a main() function.

Judicious use of static scope and unique name prefixes like putty_ may
avoid such problems without the need for `RTLD_LOCAL'.

- Giorgos