1998-10-28 00:30:31 +08:00
From nobody Wed Oct 14 16:43:54 1998
X-From-Line: badger@prtr-13.ucsc.edu Sat Mar 07 06:09:15 1998
Return-Path: <badger@prtr-13.ucsc.edu>
Delivered-To: gord@trick.profitpress.com
Received: (qmail 29304 invoked from network); 7 Mar 1998 06:09:10 -0000
Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
by 127.0.0.1 with SMTP; 7 Mar 1998 06:09:10 -0000
Received: from mail.cwo.com (gateway.m-tech.ab.ca [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id WAA18468 for <gord@m-tech.ab.ca>; Fri, 6 Mar 1998 22:55:43 -0700
Received: from Greyeyes.ucsc.edu (badger@port-sac31.cwo.com [207.173.173.146])
by mail.cwo.com (8.8.8/8.8.8) with ESMTP id VAA08756
for <gord@m-tech.ab.ca>; Fri, 6 Mar 1998 21:59:21 -0800
Received: (from badger@localhost)
by Greyeyes.ucsc.edu (8.8.7/8.8.7) id VAA27714;
Fri, 6 Mar 1998 21:54:09 -0800
Message-ID: <19980306215408.59334@prtr-13.ucsc.edu>
Date: Fri, 6 Mar 1998 21:54:08 -0800
From: Toshio Kuratomi <badger@prtr-13.ucsc.edu>
To: Gordon Matzigkeit <gord@m-tech.ab.ca>
Subject: Re: InterLibrary Dependency
References: <19980225175901.56084@prtr-13.ucsc.edu> <8690qzyqqx.fsf@trick.profitpress.com> <19980225214804.59179@prtr-13.ucsc.edu> <863eh2547a.fsf@trick.profitpress.com> <19980303213204.27408@prtr-13.ucsc.edu> <86k9a9du5z.fsf@trick.profitpress.com>
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
micalg=pgp-md5; boundary="Ew/8QCHSq3SnV5pl"
X-Mailer: Mutt 0.88
In-Reply-To: <86k9a9du5z.fsf@trick.profitpress.com>; from Gordon Matzigkeit on Thu, Mar 05, 1998 at 08:38:48AM -0700
Xref: trick.profitpress.com mail.libtool:1135
1998-11-03 03:30:15 +08:00
Lines: 366
X-Gnus-Article-Number: 1 Mon Nov 2 17:17:55 1998
1998-10-28 00:30:31 +08:00
--Ew/8QCHSq3SnV5pl
Content-Type: multipart/mixed; boundary="D7pdK0Ng3jPPYy/f"
--D7pdK0Ng3jPPYy/f
Content-Type: text/plain; charset=us-ascii
Okay! Here's a complete patch! It works well for me -- I haven't had it do
anything unexpected.
The best thing to do is probably just to look at the patch itself. But the
basic architecture is this:
in ltconfig.in, the person who writes libtool makes sure $deplibs is included
in $archive_cmds somewhere and also sets the $check_shared_deplibs_method.
check_shared_deplibs_method can be any of five things:
test_compile
file_regex
file_magic [regex]
pass_all
none
I think that file_magic works the best: It looks in the library link path for
libraries that have the right libname. Then it runs file on the library and
checks for a match against [regex] using expr. I currently have linux-elf
looking for the string: "ELF 32-bit LSB shared object" which seems to work well.
(I don't know whether the "32-bit" would have to change on linux-alpha
though.... change to 'ELF [0-9]+-bit LSB shared object' might work. I don't
know.)
file_regex will look for a filename in the link path. It doesn't take an
argument because I use the libname_spec and library_names_spec variables to
create the string to look for. I don't like it because symlinks and random
files can make it give false positives.
test_compile has been overhauled since the last patch. It now handles -L
correctly, I hope. It also takes the names of it's libraries from
libname_spec instead of a hardcoded lib`expr $a_deplib : '-l/(.*/)'`.so line.
pass_all will pass everything without any checking. I put it in because
osf3&4 appear to be treated that way right now... It might be wise to perform
checks here to see if the libraries exist on the system, but I don't know how
osf3&4 handle that, so I thought it would be better just to do it the way the
current code does.
none is the default for all systems unless overridden in ltconfig.in
(Currently, linux-elf is the only system that overrides.) It causes deplibs
to be reassigned deplibs="". That way archive_cmds can contain deplibs on all
platforms, but not have deplibs used unless needed.
Okay:: Then in ltmain.in we have the real workhorse: a litle initialization
and postprocessing (to setup/release variables for use with eval echo
libname_spec etc.) and a case statement that decides which method is being
used. This is the real code... I wish I could condense it a little more, but
I don't think I can without function calls. I've mostly optimized it (moved
things out of loops, etc.) but there is probably some fat left. I thought I
should stop while I was ahead, work on whatever bugs you discover, etc before
thinking about more than obvious optimizations.
Uhm... Anything else? Ahh -- I can't seem to access my mail server right now,
I have a feeling the network between it and the outside world has gone down
again. I hope this situation is resolved soon, but I have no assurancances
(These things always happen on a Friday, no?)
If you need to reach me and your mail bounces off my normal address, you can
send mail to my parent's account mrk-chri@cwo.com and they'll see that I get
it.
-Toshio
(This patch is against libtool-1.0i)
--
badger \"The Difference between today and yesterday is not so much what has
@prtr-13 \ changed between then and now as what I hope to change by tomorrow."
.ucsc.edu \~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
--D7pdK0Ng3jPPYy/f
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="libtool-interlibdep.diff"
--- libtool-1.0i/ltconfig.in.orig Fri Feb 6 00:23:19 1998
+++ libtool-1.0i/ltconfig.in Fri Mar 6 20:34:39 1998
@@ -709,7 +709,7 @@
# See if GNU ld supports shared libraries.
if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
- archive_cmds='$CC -shared ${wl}-soname $wl$soname -o $lib$libobjs'
+ archive_cmds='$CC -shared ${wl}-soname $wl$soname -o $lib$libobjs$deplibs'
runpath_var=LD_RUN_PATH
ld_shlibs=yes
else
@@ -1098,6 +1098,19 @@
shlibpath_var=
version_type=none
dynamic_linker="$host_os ld.so"
+check_shared_deplibs_method='none'
+# Need to set the preceding variable on all platforms that support
+# interlibrary dependencies.
+# 'none' -- dependencies disabled.
+# 'pass_all' -- all dependencies passed with no checks.
+# 'test_compile' -- check by making test program.
+# 'file_regex' -- check by looking for filenames that look like the shared
+# library in the library path.
+# 'file_magic [regex]' -- check by looking for files in library path which
+# responds to the "file" command with a given regex. This is actually a
+# superset of the file_regex command. If you have file on your system, you'll
+# want to use this instead.
+# Notes: regexes are run through expr.
echo $ac_n "checking dynamic linker characteristics... $ac_c" 1>&6
case "$host_os" in
@@ -1160,6 +1173,7 @@
soname_spec='${libname}${release}.so.$major'
finish_cmds='PATH="$PATH:/sbin" ldconfig -n $libdir'
shlibpath_var=LD_LIBRARY_PATH
+ check_shared_deplibs_method='file_magic ELF 32-bit LSB shared object'
if test -f /lib/ld.so.1; then
dynamic_linker='GNU ld.so'
@@ -1191,6 +1205,7 @@
soname_spec='${libname}${release}.so'
library_names_spec='${libname}${release}.so.$versuffix $libname.so'
shlibpath_var=LD_LIBRARY_PATH
+ check_shared_deplibs_method='pass_all'
;;
sco3.2v5*)
@@ -1411,6 +1426,9 @@
archive_cmds="$archive_cmds"
postinstall_cmds="$postinstall_cmds"
postuninstall_cmds="$postuninstall_cmds"
+
+# Method to check whether dependent libraries are shared objects.
+check_shared_deplibs_method="$check_shared_deplibs_method"
# Flag that allows shared libraries with undefined symbols to be built.
allow_undefined_flag="$allow_undefined_flag"
--- libtool-1.0i/ltmain.in.orig Fri Feb 6 00:06:22 1998
+++ libtool-1.0i/ltmain.in Fri Mar 6 20:56:51 1998
@@ -363,6 +363,9 @@
compile_shlibpath=
finalize_shlibpath=
deplibs=
+ extradeplibs=
+ lib_search_path="/lib /usr/lib"
+
dlfiles=
dlprefiles=
export_dynamic=no
@@ -492,9 +495,12 @@
;;
esac
deplibs="$deplibs $arg"
+ extradeplibs="$extradeplibs $arg"
+ lib_search_path="$lib_search_path `expr $arg : '-L\(.*\)'`"
;;
-l*) deplibs="$deplibs $arg" ;;
+ -El*) extradeplibs="$extradeplibs -`expr $arg : '-E\(.*\)'`" ;;
-no-undefined)
allow_undefined=no
@@ -987,6 +993,185 @@
fi
if test "$build_libtool_libs" = yes; then
+ # Transform deplibs into only deplibs that can be linked in shared.
+ ## Gordon: Do you check for the existence of the libraries in deplibs
+ ## on the system? That should maybe be merged in here someplace....
+ ## Actually: I think test_compile and file_magic do this... file_regex
+ ## sorta does this. Only pas_all needs to be changed. -Toshio
+ name_save=$name
+ libname_save=$libname
+ release_save=$release
+ versuffix_save=$versuffix
+ major_save=$major
+ # I'm not sure if I'm treating the release correctly. I think
+ # release should show up in the -l (ie -lgmp5) so we don't want to
+ # add it in twice. Is that correct?
+ release=""
+ versuffix=""
+ major=""
+ newdeplibs=
+ case "$check_shared_deplibs_method" in
+ pass_all) ;; # Don't check for shared/static. Everything works.
+ # This might be a little naive. We might want to check
+ # whether the library exists or not. But this is on
+ # osf3 & osf4 and I'm not really sure... Just
+ # implementing what was already the behaviour.
+ test_compile)
+ # This code stresses the "libraries are programs" paradigm to its
+ # limits. Maybe even breaks it. We compile a program, linking it
+ # against the deplibs as a proxy for the library. Then we can check
+ # whether they linked in statically or dynamically with ldd.
+ $rm conftest.c
+ cat > conftest.c <<EOF
+ int main() { return 0; }
+EOF
+ $rm a.out
+ $CC conftest.c $deplibs $extradeplibs
+ if test $? -eq 0 ; then
+ ldd_output=`ldd a.out`
+ for i in $deplibs; do
+ name="`expr $i : '-l\(.*\)'`"
+ # If $name is empty we are operating on a -L argument.
+ if test "$name" != "" ; then
+ libname=`eval \\$echo \"$libname_spec\"`
+ deplib_matches=`eval \\$echo \"$library_names_spec\"`
+ set dummy $deplib_matches
+ deplib_match=$2
+ if test `expr "$ldd_output" : ".*$deplib_match"` -ne 0 ; then
+ newdeplibs="$newdeplibs $i"
+ else
+ echo
+ echo "*** Warning: This library needs some functionality provided by $i."
+ echo "*** I have the capability to make that library automatically link in when"
+ echo "*** you link to this library. But I can only do this if you have a"
+ echo "*** shared version of the library, which you do not appear to have."
+ fi
+ else
+ newdeplibs="$newdeplibs $i"
+ fi
+ done
+ else
+ # Error occured in the first compile. Let's try to salvage the situation:
+ # 1) Is the error in the extradeplibs?
+ $rm a.out
+ $CC conftest.c $extradeplibs
+ if test $? -ne 0 ; then
+ echo
+ echo "*** Warning! Not all libraries necessary to the dependent libraries are"
+ echo "*** working! You will probably need to install some of:"
+ echo "*** $extradeplibs"
+ echo "*** before this library will be fully functional. Installing these"
+ echo "*** libraries before continuing would be even better."
+ newextradeplibs=
+ for i in $extradeplibs; do
+ if test `expr "$i" : '-L'` -ne 0 ; then
+ newextradeplibs="$newextradeplibs $i"
+ fi
+ done
+ extradeplibs=$newextradeplibs
+ fi
+ # 2) Compile a seperate program for each library.
+ for i in $deplibs; do
+ name="`expr $i : '-l\(.*\)'`"
+ # If $name is empty we are operating on a -L argument.
+ if test "$name" != "" ; then
+ $rm a.out
+ $CC conftest.c $i $extradeplibs
+ # Did it work?
+ if test $? -eq 0 ; then
+ ldd_output=`ldd a.out`
+ libname=`eval \\$echo \"$libname_spec\"`
+ deplib_matches=`eval \\$echo \"$library_names_spec\"`
+ set dummy $deplib_matches
+ deplib_match=$2
+ if test `expr "$ldd_output" : ".*$deplib_match"` -ne 0 ; then
+ newdeplibs="$newdeplibs $i"
+ else
+ echo
+ echo "*** Warning: This library needs some functionality provided by $i."
+ echo "*** I have the capability to make that library automatically link in when"
+ echo "*** you link to this library. But I can only do this if you have a"
+ echo "*** shared version of the library, which you do not appear to have."
+ fi
+ else
+ echo
+ echo "*** Warning! Library $i is needed by this library but I was not able to"
+ echo "*** make it link in! You will probably need to install it or some"
+ echo "*** library that it depends on before this library will be fully"
+ echo "*** functional. Installing it before continuing would be even better."
+ fi
+ else
+ newdeplibs="$newdeplibs $i"
+ fi
+ done
+ fi
+ deplibs=$newdeplibs
+ ;;
+ file_magic* | file_regex)
+ set dummy $check_shared_deplibs_method
+ file_magic_regex="`expr \"$check_shared_deplibs_method\" : \"$2\(.*\)\"`"
+ for a_deplib in $deplibs; do
+ name="`expr $a_deplib : '-l\(.*\)'`"
+ # If $name is empty we are operating on a -L argument.
+ if test "$name" != "" ; then
+ libname=`eval \\$echo \"$libname_spec\"`
+ case "$check_shared_deplibs_method" in
+ file_magic*)
+ for i in $lib_search_path; do
+ # This needs to be more general than file_regex in order to
+ # catch things like glibc on linux. Maybe file_regex
+ # should be more general as well, but maybe not. Since
+ # library names are supposed to conform to
+ # library_name_spec, I think file_regex should remain
+ # strict. What do you think Gordon?
+ potential_libs=`ls $i/$libname[.-]* 2>/dev/null`
+ for potent_lib in $potential_libs; do
+ file_output=`file $potent_lib`
+ if test `expr "$file_output" : ".*$file_magic_regex"` -ne 0 ; then
+ newdeplibs="$newdeplibs $a_deplib"
+ a_deplib=""
+ break 2
+ fi
+ done
+ done
+ ;;
+ file_regex)
+ deplib_matches=`eval \\$echo \"$library_names_spec\"`
+ set dummy $deplib_matches
+ deplib_match=$2
+ for i in $lib_search_path; do
+ potential_libs=`ls $i/$deplib_match* 2>/dev/null`
+ if test "$potential_libs" != "" ; then
+ newdeplibs="$newdeplibs $a_deplib"
+ a_deplib=""
+ break
+ fi
+ done
+ ;;
+ esac
+ if test "$a_deplib" != "" ; then
+ echo
+ echo "*** Warning: This library needs some functionality provided by $a_deplib."
+ echo "*** I have the capability to make that library automatically link in when"
+ echo "*** you link to this library. But I can only do this if you have a"
+ echo "*** shared version of the library, which you do not appear to have."
+ fi
+ else
+ # Add a -L argument.
+ newdeplibs="$newdeplibs $a_deplib"
+ fi
+ done # Gone through all deplibs.
+ ;;
+ none | *) deplibs="" ;;
+ esac
+ versuffix=$versuffix_save
+ major=$major_save
+ release=$release_save
+ libname=$libname_save
+ name=$name_save
+ deplibs=$newdeplibs
+ # Done checking deplibs!
+
# Get the real and link names of the library.
library_names=`eval \\$echo \"$library_names_spec\"`
set dummy $library_names
--D7pdK0Ng3jPPYy/f--
--Ew/8QCHSq3SnV5pl
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
iQCVAwUBNQDg/2I4kZK9uLMpAQGQfwQAo5wbFpHA4588S6R+zTjgIYPa1caMFZhM
ehwKr0JSyu8mSkp9tSavavTkyq/AE6+NnvZeNU5NpWxvfCk32f5lhEzWaU69HFfy
CjpxiDUi/74EeQrobfchoYeC6KhN66Y6JsSi1ayZa52P7hFibS674ORVXxw2zNq3
NUfJkmb2mTY=
=q0bH
-----END PGP SIGNATURE-----
--Ew/8QCHSq3SnV5pl--
From nobody Wed Oct 14 16:45:01 1998
X-From-Line: ian@cygnus.com Fri Apr 17 23:33:18 1998
Return-Path: <ian@cygnus.com>
Delivered-To: gord@trick.profitpress.com
Received: (qmail 23427 invoked from network); 17 Apr 1998 23:33:17 -0000
Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
by 127.0.0.1 with SMTP; 17 Apr 1998 23:33:17 -0000
Received: from tweedledumb.cygnus.com (gateway.m-tech.ab.ca [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id OAA06912 for <gord@profitpress.com>; Fri, 17 Apr 1998 14:17:39 -0600
Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id QAA18613;
Fri, 17 Apr 1998 16:18:12 -0400 (EDT)
Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id QAA08387; Fri, 17 Apr 1998 16:18:11 -0400
Date: Fri, 17 Apr 1998 16:18:11 -0400
Message-Id: <199804172018.QAA08387@subrogation.cygnus.com>
From: Ian Lance Taylor <ian@cygnus.com>
To: gord@profitpress.com
CC: bug-libtool@gnu.org
In-reply-to: <86k98oh6fy.fsf@trick.profitpress.com> (message from Gordon
Matzigkeit on 17 Apr 1998 08:24:33 -0600)
Subject: Re: libtool on cygwin32
Xref: trick.profitpress.com mail.libtool:1335
1998-11-03 03:30:15 +08:00
Lines: 30
X-Gnus-Article-Number: 2 Mon Nov 2 17:17:55 1998
1998-10-28 00:30:31 +08:00
From: Gordon Matzigkeit <gord@profitpress.com>
Date: 17 Apr 1998 08:24:33 -0600
>>>>> Ian Lance Taylor writes:
[...]
ILT> So, my choices are to use -no-undefined -lbfd everywhere, or to
ILT> use it only on Windows.
Would `-avoid-deps' (a proposed flag) give you what you want?
default = record inter-library dependencies on all platforms, if
possible.
-no-undefined = the dependency info provided is complete. Build
shared libraries on AIX and windows.
-avoid-deps = implies `-no-undefined'. However, avoid recording
inter-library dependencies unless they are required for building a
shared library.
Yes, that sounds like it will do what I need.
Somebody someday may want to record some library dependencies but not
others, in which case you would want
-avoid-deps -lfoo -no-avoid-deps -lbar
Ian
From nobody Wed Oct 14 16:45:40 1998
X-From-Line: ian@cygnus.com Mon Apr 27 16:24:19 1998
Return-Path: <ian@cygnus.com>
Delivered-To: gord@trick.profitpress.com
Received: (qmail 136 invoked from network); 27 Apr 1998 16:24:18 -0000
Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
by localhost with SMTP; 27 Apr 1998 16:24:18 -0000
Received: from tweedledumb.cygnus.com (gateway.m-tech.ab.ca [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id JAA21924 for <gord@m-tech.ab.ca>; Mon, 27 Apr 1998 09:42:43 -0600
Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id LAA02934;
Mon, 27 Apr 1998 11:48:04 -0400 (EDT)
Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id LAA01776; Mon, 27 Apr 1998 11:48:03 -0400
Date: Mon, 27 Apr 1998 11:48:03 -0400
Message-Id: <199804271548.LAA01776@subrogation.cygnus.com>
From: Ian Lance Taylor <ian@cygnus.com>
To: gord@m-tech.ab.ca
CC: robbe@orcus.priv.at, bug-libtool@gnu.org
In-reply-to: <86bttpvbqd.fsf@trick.profitpress.com> (message from Gordon
Matzigkeit on 25 Apr 1998 15:21:30 -0600)
Subject: Re: libtool 1.2: Why no inter-lib dependencies on ELF?
Xref: trick.profitpress.com mail.libtool:1388
1998-11-03 03:30:15 +08:00
Lines: 27
X-Gnus-Article-Number: 3 Mon Nov 2 17:17:55 1998
1998-10-28 00:30:31 +08:00
From: Gordon Matzigkeit <gord@m-tech.ab.ca>
Date: 25 Apr 1998 15:21:30 -0600
There are still some unresolved issues (see
http://www.profitpress.com/libtool/deplibs.html). Full inter-library
dependency support is scheduled for libtool 1.3, though, and should
appear in the next beta-testing release.
I read that page, and here are a few quick notes.
1) On any platform which does not require -fpic you can link
static libraries into shared libraries. These platforms include
AIX, Irix 5/6, and Windows.
2) On any functioning ELF platform you can include code which was not
compiled with -fpic in a shared library, and you can link with a
static library when creating a shared library. You say that Solaris
won't let you link a shared library against a static one, but it
appears to work for me. What type of test are you using?
3) On SunOS you can not correctly link a static library into a shared
library. It will mostly work, but I believe that certain operations,
such as overriding a shared library function in the main executable,
will fail.
Ian
From nobody Wed Oct 14 16:48:43 1998
X-From-Line: gord@gnu.org Thu Sep 10 04:39:20 1998
Return-Path: <gord@gnu.org>
Delivered-To: gord@trick.fig.org
Received: (qmail 30644 invoked from network); 10 Sep 1998 04:39:18 -0000
Received: from gen2-93ip34.cadvision.com (HELO bambam.m-tech.ab.ca) (209.91.93.34)
by cs366707-a.cgmo1.ab.wave.home.com with SMTP; 10 Sep 1998 04:39:18 -0000
Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id WAA26741 for <gord@m-tech.ab.ca>; Wed, 9 Sep 1998 22:38:15 -0600
Received: from mailhost.cyberramp.net (root@mailhost.cyberramp.net [207.158.64.11]) by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id AAA11165 for <bug-libtool@gnu.org>; Thu, 10 Sep 1998 00:38:17 -0400
Received: from fuzzylog.simple.dallas.tx.us (dal-tsa11-49.cyberramp.net [207.158.111.49])
by mailhost.cyberramp.net (8.9.1a/8.9.1/ler-980825-0832-PM) with ESMTP id XAA13581;
Wed, 9 Sep 1998 23:37:41 -0500 (CDT)
Received: from scooby (scooby [192.168.1.3])
by fuzzylog.simple.dallas.tx.us (8.8.8/8.8.8) with SMTP id XAA27692;
Wed, 9 Sep 1998 23:37:38 -0500 (CDT)
Date: Wed, 9 Sep 1998 23:37:38 -0500 (CDT)
From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
To: Libtool Bugs <bug-libtool@gnu.org>
Subject: Late-binding looses space efficiency ...
Message-ID: <Pine.SO4.4.02.9809092322490.808-100000@scooby.simple.dallas.tx.us>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Xref: trick.fig.org libtool:1605
1998-11-03 03:30:15 +08:00
Lines: 27
X-Gnus-Article-Number: 4 Mon Nov 2 17:17:55 1998
1998-10-28 00:30:31 +08:00
On most systems, libtool does not supply the dependency libraries (-llib) when
it creates the shared library in spite of these being supplied on the libtool
command line. The ImageMagick package uses quite a few dependency libraries.
The ImageMagick library uses these libraries directly but utilities built
using the ImageMagick library only link against these libraries because the
ImageMagick library demands it.
Through testing we have found that if the 'ltconfig' archive_cmds definition
is ammended to include $deplibs that linked programs become much smaller (1/3
to 1/4 the original size). This appears to be because more code is included
in the shared library itself, avoiding the need for this to be part of the
program.
The distributed 'ltconfig' only supplies $deplibs for systems matching osf3* |
osf4*. Is there a reason why $deplibs is not supplied for all systems that can
support inter-library dependencies? Reducing overall package size is highly
desireable in order to reduce disk-space consumption and binary distribution
size.
Thanks,
Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us
http://www.cyberramp.net/~bfriesen
From nobody Wed Oct 14 16:52:40 1998
X-From-Line: ddj@hks.net Thu Sep 17 21:29:13 1998
Return-Path: <ddj@hks.net>
Delivered-To: gord@trick.fig.org
Received: (qmail 22994 invoked by uid 1003); 17 Sep 1998 21:29:12 -0000
Delivered-To: jana-profitpress-gord@profitpress.com
Received: (qmail 22991 invoked from network); 17 Sep 1998 21:29:11 -0000
Received: from dali.hks.net (ddj@208.203.175.210)
by cs366707-a.cgmo1.ab.wave.home.com with SMTP; 17 Sep 1998 21:29:11 -0000
Received: (from ddj@localhost)
by dali.hks.net (8.8.5/8.8.5) id RAA04020;
Thu, 17 Sep 1998 17:26:28 -0400
Received: from BatMail.robin.v2.15.CUILIB.3.45.SNAP.NOT.LINKED.dali..none..ix86.Linux
via MS.5.6.dali.(none).ix86_Linux;
Thu, 17 Sep 1998 17:26:27 -0400 (EDT)
Message-ID: <oq0Lu3Jz000185PkIG@hks.net>
Date: Thu, 17 Sep 1998 17:26:27 -0400 (EDT)
From: Doug DeJulio <ddj@hks.net>
To: gord@profitpress.com
Subject: Re: Libtool Inter-library Dependencies
Xref: trick.fig.org libtool:1611
1998-11-03 03:30:15 +08:00
Lines: 32
X-Gnus-Article-Number: 5 Mon Nov 2 17:17:55 1998
1998-10-28 00:30:31 +08:00
I read your discussion of why libtool can't handle inter-library
dependencies and how people might be able to help fix this. I found
an error in item #1 of "The Solution". I quote:
> Finally, there are some systems which won't even allow you to link a
> shared library against a static one:
> Solaris 2.x
This is only true in most cases. If all of the accessed individual
object files in the static library *could* have been put in a shared
library, things will work just fine. It's not the type of library
that matters, but the type of object files.
Our commercial product includes a library and a few
dynamically-loadable modules that make that library accessible to
various interpretetd languages (TCL, Perl, PHP3 and Python at the
moment, with more coming). We don't distribute a shared library
anymore because when we did this caused a ton of trouble (most people
just couldn't get it configured correctly). I haven't yet found a
platform on which linking dynamically-loadable object file against a
static "ar" archive containing relocatable object files causes any
trouble (and we support SCO, Digital Unix, SCO, Solaris, Linux, and
FreeBSD, so this isn't because of narrow experience).
So, the main point is that just deciding whether it'll work based on
looking at the library file will in some cases fail when it should
have succeeded (and the software we sell is such a case).
--
Doug DeJulio | mailto:ddj@hks.net
HKS, Incorporated | http://www.hks.net/
