This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libtool for shared objects?


On Mar 11, 2008, Basile STARYNKEVITCH <basile@starynkevitch.net> wrote:

>> * Basile STARYNKEVITCH wrote on Tue, Mar 11, 2008 at 09:18:54PM CET:

>>> I would like to use this tool to compile some  (generated)
>>> warm(basilys.c file into a warm-basilys.la in the most  portable
>>> way (on Linux/ELF systems I would just use gcc -fPIC -shared
>>> warm-basilys.c -o warm-basilys.so and use the warm-basilys.so
>>> shared  library to dlopen).

> I need all this in the gcc/ subdir, since I want cc1 (the same process) to
>   1. generate a C file
>   2. compile it to some dynamically loadable stuff (*.so on Linux/Elf,
> perhaps *.la with libtool)
>   3. lt_dlopenext it

Erhm...  You can't even count on having functional dynamic libraries,
let alone dlopen.  libtool will try to minimize the impact of these
absences with the -dlopen flag, that will link the wanted library into
the main executable, such that libltdl will pretend to dlopen and look
up symbols.

Given lack of dlopen, it's not possible to accommodate dlopening
emulation of libraries created after the executable, which is what
you're after.  libtool and libltdl won't help you in these cases.  You
probably don't care about them, though.

I'm not sure when the library you have in mind is supposed to be
built.  If it's to be built as part of the GCC build process, then
there's no reason I can think of to depend on dlopen in the first
place.  Simply linking it into GCC should be nearly the same, unless
you depend on dynamic symbol lookup, which could be easily emulated.

But if the library is to be build as part of the *use* of GCC, then
things get much trickier.  libtool is not designed for this kind of
use, although you could in theory build and install a libtool that
will work along with the compiler, but there are many caveats.  I
don't think I'd recommend going down this path, but if this is your
case, I can elaborate further.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


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