This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

ld.so in static apps (esp, using nss_db in static apps)


While we can use DSOs from a statically linked application we have
severe problem with this DSO dynamically loading another one (I'm not
talking about dependencies).  This second loading would use the ld.so
load mechanism and not that of the loading functions in the app
(coming from libc.a).  For now this means that we cannot handle nss_db
in statically linked applications which probably disqualifies it
completely.

This problem isn't new.  We haven't seen it in 2.1 because nss_db was
linked against the libdb.

I tried to solve this problem (or at least work around) but it is
hard.  And the more I think about it, the harder it gets.  The
immediate problem is that ld.so does not get initialized.  There is no
constructor in ld.so and the loading functions libc.so certainly don't
call _dl_main.  This means that calls to _dl_map_object or the like
find a completely uninitialized library and especially env_path_list
and rtld_search_list are NULL.  This is something the ld.so in 2.1
simply ignored, by the way.  It never was correct.

One could try to add a constructor to ld.so which would get executed
and could initialize the variables.  Well, not really, and this is a
part of the problem.  The ld.so has no idea about the environment and
cannot find out about vars like LD_LIBRARY_PATH.

Also, there is the aliasing problem: the loading functions in the app
(from libc.a) have some DSO loaded, the ld.so would load them again.

It seems to be as if the correct solution would be to have the dlopen
functions in DSOs loaded from statically linked apps should use the
implementation (of dlopen) in the statically linked app.  But how?

I would avoid handling this problem altogether if we wouldn't have
added this extra code to libnss_db.  Therefore, can we find another
solution?  What I currently imagine is making libnss_db a standalone
package which can be installed after libc and libdb.  Then we can link
just fine against libdb and don't have to use the dlopen() hack.

Comments?

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]