Yet another versioning anomaly

[H.J. Lu]

> 
> > > > I guess we should add -lc to -shared for glibc 2. But I am not
> > > > sure if all the systems support it. I think ld.so in libc 5 may
> > > > not be happy with it.
> > > 
> > > That doesn't make any sense.  Redundant dependencies happen all the time;
> > > it would be impressively lossy if ld.so couldn't handle this.
> > > 
> > 
> > I am thinking about dlopen within a binary statically linked with
> > libc.a. 
> 
> Sorry, you must explain yourself more clearly and completely for me to
> understand you.  In the case of a statically linked program using dlopen,
> the object being linked in *must* have a DT_NEEDED for libc.so, otherwise
> its refs to libc symbols will be undefined.

It is not necessary in all cases. libdl can use the exported symbols
in the statically linked program. We can build such a binary if we
want using -rdynamic.

> 
> > Besides, -lc is used for versioned symbol in libc in this
> > case. Only glibc 2 uses it.
> 
> Again, I don't understand your point.  One of the reasons to link shared
> objects with -lc is indeed to get the symbol versions bound with glibc-2.1.
> That is not the only reason, as we have just been discussing.
> 

There are some potential problems when the binary is statically linked
with the older libc, but libfoo.so loaded in via dlopen uses the newer
libc.so. I don't know what will happen when you mix the older static
libc with the newer libc.so.


-- 
H.J. Lu (hjl@gnu.org)