linking shared libraries into libtool libraries
libtool-1.3.5, ltmain.sh, line 1606:
# How the heck are we supposed to write a wrapper for a shared library?
if test -n "$link_against_libtool_libs"; then
$echo "$modename: error: cannot link shared libraries into libtool libraries"
1>&2
exit 1
fi
Can I suggest that you don't actually link in libtool shared libraries - but
you DO add them to the libraries dependancy list (and add any dependancies
from the .la file) rather than exiting here? Something will have to
be done to distiguish between installed and not installed versions, but that
shouldn't be too hard.
Basically if the .la file has "installed=yes", then we would copy its
dependancy libs, as well as adding "-L${libdir} -l${libname}" for that .la.
If it has "installed=no", then we would probably have to put
"-L${currentdir}/.libs -l${libname}" in our uninstalled target .la file as
well as the dependancies from the source .la, and "-L${libdir} -l${libname}"
in our target .lai as well as the dependancies from the source .lai. Of
course the assumption (and requirement) is that the two libraries get
installed together, but I don't think that is unreasonable in the situation
where you are linking against an uninstalled library.
Any problems with this idea?
I will look at making this change, but the ltmain.sh is quite complicated so
it might take a while. If anyone with a better knowledge wants to give it a
go that would be great.
Regards,
Chris
(BTW: please CC me on responses)
--
--
Knuth: premature optimisation is the root of all evil.
--
Reply with subject 'request key' for GPG public key. KeyID 0xB4E24219
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: linking shared libraries into libtool libraries
On Wed, Jan 03, 2001 at 07:42:57AM -0200, Alexandre Oliva wrote: > On Jan 3, 2001, Chris Leishman <[EMAIL PROTECTED]> wrote: > > > Can I suggest that you don't actually link in libtool shared libraries - but > > you DO add them to the libraries dependancy list (and add any dependancies > > from the .la file) rather than exiting here? > > Try the current CVS tree. That's the main feature that's going to be > introduced in libtool 1.4. > Ahhh... great! I'll give it a go. Thanks, Chris -- -- Knuth: premature optimisation is the root of all evil. -- Reply with subject 'request key' for GPG public key. KeyID 0xB4E24219 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
shared library linking on Darwin
Hi, I've been playing with the latest alpha release of libtool and have come across this issue. When linking a shared library (for a dynamically loaded module), the project I'm working on uses code from a subdirectory that has been compiled into an archive library (.a). So the link line is something like: /bin/sh ./libtool --mode=link c++ -W -Wall -o module.la --module main.lo extra/libextra.a This generates the following warning: *** Warning: This library needs some functionality provided by extra/libextra.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module module.la. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. Unfortunately I can't get the application to load the libshared.a file as a dynamic module (not unsurprising). Even if I specify -dlopen on the command line it still barfs - but since darwin doesn't have a dlopen call and I'm using wrapper library (dlcompat) this flag probably does nothing. I'm just wondering why it can't just suck the object files out of the archive when linking the shared library? That seems to be how it works on other platforms. Is it a problem with the object code not being relocatable? Alternatively I can compile the subdir as a shared library, but that means I need to use inter library dependencies when module loading - which doesn't seem to be supported?? (And besides, I don't want to have to distribute a second library file). Any suggestions or comments. Is this a bug? Thanks, Chris Leishman ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: shared library linking on Darwin
On Tuesday, April 17, 2001, at 01:50 PM, Alexandre Oliva wrote: > On Apr 17, 2001, Chris Leishman <[EMAIL PROTECTED]> wrote: > >> *** Warning: This library needs some functionality provided by >> extra/libextra.a. > >> Unfortunately I can't get the application to load the libshared.a file >> as a dynamic module (not unsurprising). Even if I specify -dlopen on >> the command line it still barfs > > How exactly are you specifying this flag, and what exactly happens? I'm using automake, and I add it to the binary_LDFLAGS option, which adds it to the link line. Everything compiles ok, but the dlopen fails with the error "not a Mach-O MH_BUNDLE file type" (this error message is output by dlcompat when NSCreateObjectFileImageFromFile returns NSObjectFileImageInapproriateFile). >> I'm just wondering why it can't just suck the object files out of the >> archive when linking the shared library? > > Because they're likely to be non-PIC, and several platforms don't > support non-PIC in shared libraries. If Darwin does, all you have to > do is to post a patch that sets deplibs_check_method=pass_all. YeahI thought the PIC might be an issue - I just wasn't sure... >> That seems to be how it works on other platforms. > > You haven't tested on enough other platforms :-) Thats entirely reasonable! I've only tried this on Solaris/Linux/BSD which isn't exactly alot. I just hoped Darwin would have some similarities with BSD - but that was a huge long shot considering its shared library system appears to be totally different (weird Mach junk ;-) ). >> Alternatively I can compile the subdir as a shared library, but that >> means I need to use inter library dependencies when module loading - > > Compile it as a libtool convenience archive. That's exactly the > purpose of this feature. I tried that, but I still get the error: *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module module. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. And the result is a static archive library (as stated in the warning). I'm sending you an example module in a separate mail (not CC'd to the list), which will show you how I've set up the build environment. Thanks, Chris ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: shared library linking on Darwin
On Friday, April 20, 2001, at 08:05 AM, Kevin Ryde wrote: > Chris Leishman <[EMAIL PROTECTED]> writes: >> >> Everything compiles ok, but the dlopen fails with the error "not a >> Mach-O MH_BUNDLE file type" (this error message is output by dlcompat >> when NSCreateObjectFileImageFromFile returns >> NSObjectFileImageInapproriateFile). > > Perhaps the backtick quoting problem (other thread) is making it miss > out on -bundle, instead using -dynamiclib, due to the test in > archive_cmds being evaluated too early. You might want to check the > cc command that gets run. No cc commands get run to link (output below). Libtool has decided that it couldn't satisfy all inter-library dependencies for the module (even though the only dependency is a single libtool convenience library), and is hence building a static archive using ar and ranlib. The .a archive is obviously not a bundle library, hence it spits the error. Chris /bin/sh ./libtool --mode=link cc -W -Wall -O0 -g -o module.la -rpath /usr/local/lib -module -release 0-1 module.lo extra/libextra.la rm -fr .libs/module.la .libs/module.* .libs/module-0-1.* *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module module. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. rm -fr .libs/module.lax mkdir .libs/module.lax rm -fr .libs/module.lax/libextra.al mkdir .libs/module.lax/libextra.al (cd .libs/module.lax/libextra.al && ar x /Users/caleishm/work/test_mod/extra/.libs/libextra.al) ~/work/test_mod/.libs/module.lax/libextra.al ar cru .libs/module.a module.o .libs/module.lax/libextra.al/extra.lo ranlib .libs/module.a rm -fr .libs/module.lax creating module.la (cd .libs && rm -f module.la && ln -s ../module.la module.la) ~/work/test_mod/.libs ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
