This is the mail archive of the 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] 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
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

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 does not get initialized.  There is no
constructor in and the loading functions 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 in 2.1
simply ignored, by the way.  It never was correct.

One could try to add a constructor to which would get executed
and could initialize the variables.  Well, not really, and this is a
part of the problem.  The 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 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.


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

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