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

Alexandre Oliva wrote:
On Mar 11, 2008, Basile STARYNKEVITCH <> 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 in the most  portable
way (on Linux/ELF systems I would just use gcc -fPIC -shared
warm-basilys.c -o and use the
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)

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 $
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.

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} ***

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