On Wed, Sep 25, 2002 at 08:44:07AM +0200, Jaromir Dolecek wrote:
> Jed Davis wrote:
> > For extra fun, define global data with the same name as a library
> > function; preferably the name should be that of a well-known call that
> > the program doesn't use directly (so no compiler warnings) but that a
> > loadable module that the program doesn't deal with directly (e.g. an
> > nsswitch plugin) does use.  (My instance: "uname" with glibc and NIS.)

Yes, and if the 'plugin' is loaded by another 'plugin', then the lower
plugin has terrible problems finding the same copy of a global
data item as the code that loaded it.

> AFAIK we use internal namespace for these, so library (libc at least)
> still uses the right thing even if you have symbol with same name
> as some library routine.
> i.e. this is intended to work fine with NetBSD (you'd just not be
> able to use the routine in your program, obviously).

I doubt it, which 'internal' namespace would that be then.

Try compiling up the following:
l1.c:
    char *l1(void) { return "l1"; }
l2.c:
    extern char *l1(void); char *l2(void) { return l1(); }
cc -O2 -fpic -c l1.c
cc -O2 -fpic -c l2.c
cc -shared -ol.so l[12].o
p.c:
    #include <stdio.h>
    extern char *l2(void);
    char *l1(void) { return "p"; }
    int main(int c, char **v) { printf("%s\n", l2()); }
cc -O2 -op p.c l.so
LD_LIBRARY_PATH=. p

Note that "p" is output because the call to 'l1' in 'l2'
is required to reference the one in the program body, not the
copy in the library.
No amount of 'prelinking' will preserve this effect.

For a more lively case, add:
    void readlink(void) { _exit(0); }
to p.c
Note that the program exits without printing anything.

	David

-- 
David Laight: david@l8s.co.uk