Defining lt_preloaded_symbols

[Alexandre Oliva]

On Sep 12, 2000, Tom Tromey <tromey@cygnus.com> wrote:

Alexandre> We only need it today because prims.cc calls
Alexandre> LTDL_SET_PRELOADED_SYMBOLS().  But this is supposed to be
Alexandre> done in the main program, not in a library function.  We
Alexandre> could just leave it up to the user to do it, in case he
Alexandre> wants dlpreopening.

> That part of prims is the "main program" in a sense.
> The real main is automatically generated at compile time.  Having it
> call LTDL_SET_PRELOADED_SYMBOLS would be hard.

Perhaps we should have two object files that define functions such as
__libgcj_libltdl_init(), one that does nothing, and one that calls
LTDL_SET_PRELOADED_SYMBOLS.  The former would not be linked in by
default, being replaced with the latter in case some command-line flag
is given.

Or we could have this dummy definition of lt_preloaded_symbols in a
static library, that is always linked in after libgcj.  If the end
program doesn't use libtool for linking, it will end up importing
lt_preloaded_symbols from this library.  If it does, it will already
have a definition of it, and the definition in the library won't be
used.

The point of separating it into another library is to prevent linking
conflicts in case libgcj is a static library, natRuntime.o is brought
in for other reasons (quite likely), but an alternate definition of
lt_preloaded_symbols is already in place because libtool is being used
for linking.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me