Re: libtool for shared objects?

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

Alexandre Oliva wrote:
> 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.

I'm explicitly testing the availability of libtldl at configure time. If 
the build system don't have it, toplevel configure should fail (and I 
know how to do that) Actually, the MELT feature can only work on the 
systems which really provides a real dynamic linking mechanism (and 
*not* only the dlpreopen hack to avoid it thru static prelinking 
emulation!), i.e. having one of
    * dlopen (Solaris, Linux and various BSD flavors)
    * shl_load (HP-UX)
    * LoadLibrary (Win16 and Win32)
    * load_add_on (BeOS) 
http://www.delorie.com/gnu/docs/libtool/libtool_45.html

I call dynamic stuff the thing (usually a file) that these functions 
load dynamically. On ELF (Linux,Solaris,...) or BSD systems it probably 
is a *.so shared object (& position independent) file every linux user 
is familiar with. On HPUX it probably would be some *.sl file. On Win* 
probably some *.dll and/or *.lib and I don't know how it is called on BeOS

And of course I do depend on the functionality (provided by e.g. dlopen 
on Solaris & Linux, by shl_load on HPUX, ... all them wrapped in 
lt_dlopenext ) of dynamically loading a stuff at cc1 run time. (in other 
words, I *am* making a plugin mechanism). On the few (build or host) 
systems which still are lacking of this functionality, all the MELT 
stuff is (or has to) be disabled at configure time and that is ok for me 
(as it is for every plugin hacker in GCC).
> 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.

Yes, because I am supposing a *working* lt_dlopenext able to really load 
dynamic stuff
> 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.

Actually, I just want to generate (during the build process in gcc/ 
subdir in build directory) a script (basilys-gcc) invoked by cc1 with 
two arguments :
   the full path of some C file to generate
   the stripped path (without .so or .sl or .la) of the generated 
dynamic stuff

On Linux systems basilys-gcc would just be
  #! /bin/sh
  gcc -I...appropriatedir... -fPIC -shared -O -g $1 -o $2.so
and I do know what is the ...appropriatedir...

I was thinking that it would be a bit more portable to have it instead
  #! /bin/sh
  libtool cc -I...appropriatedir... -O -g $1 -o $2.lo

but there might be some thing I misunderstood.

And yes, my cc1 doing lt_dlopenext is linked with a -rdynamic flag.

Comments are welcome.

Regards.
--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***