Bug#348558: libtool: No such file or directory when linking 2 .la files with the same name but from different directories
Hi Bob,
* Bob Friesenhahn wrote on Sat, Jan 21, 2006 at 07:12:55PM CET:
On Sat, 21 Jan 2006, Ralf Wildenhues wrote:
[ this is http://bugs.debian.org/348558 ]
* Carlo Contavalli wrote on Wed, Jan 18, 2006 at 05:01:29PM CET:
On Wed, Jan 18, 2006 at 03:52:33PM +0100, Ralf Wildenhues wrote:
libtool developers: OK to apply this patch and backport to branch-1-5?
Changes wrt. previous proposed patch in above thread: use lt1-libfoo.a
instead of libfoo.a-1 naming, for the dubious benefit of 8+3 filename
systems. And tests.
This patch seems fine (and worthwhile) to me.
Thanks for the review, and sorry for the delay.
I have applied the patch (removed the now-obsolete change to
testsuite.at, added a `libtool' testsuite keyword) to HEAD, and the
corresponding change to branch-1-5; both patches are attached.
I guess the tag pending would be appropriate for the Debian bugreport
now.
Cheers,
Ralf
* libltdl/config/ltmain.m4sh (extracted_archives)
(extracted_serial): New globals.
(func_extract_archives): Use them to rename extraction archives
for linking against multiple convenience libraries with the same
name.
* tests/duplicate_conv.at: New tests.
* Makefile.am: Adjusted.
Reported by Carlo Contavalli [EMAIL PROTECTED].
* libltdl/config/ltmain.m4sh (extracted_archives)
(extracted_serial): New globals.
(func_extract_archives): Use them to rename extraction archives
for linking against multiple convenience libraries with the same
name.
* tests/duplicate_conv.at: New tests.
* Makefile.am: Adjusted.
Reported by Carlo Contavalli [EMAIL PROTECTED].
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.34
diff -u -r1.34 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 5 Feb 2006 10:24:42 - 1.34
+++ libltdl/config/ltmain.m4sh 5 Feb 2006 10:59:48 -
@@ -116,6 +116,8 @@
preserve_args=
lo2o=s/\\.lo\$/.${objext}/
o2lo=s/\\.${objext}\$/.lo/
+extracted_archives=
+extracted_serial=0
opt_dry_run=false
opt_duplicate_deps=false
@@ -1058,7 +1060,17 @@
esac
func_basename $my_xlib
my_xlib=$func_basename_result
- my_xdir=$my_gentop/$my_xlib
+ my_xlib_u=$my_xlib
+ while :; do
+case $extracted_archives in
+ * $my_xlib_u *)
+ extracted_serial=`expr $extracted_serial + 1`
+ my_xlib_u=lt$extracted_serial-$my_xlib ;;
+ *) break ;;
+ esac
+ done
+ extracted_archives=$extracted_archives $my_xlib_u
+ my_xdir=$my_gentop/$my_xlib_u
func_mkdir_p $my_xdir
Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.189
diff -u -r1.189 Makefile.am
--- Makefile.am 1 Feb 2006 19:54:33 - 1.189
+++ Makefile.am 5 Feb 2006 10:59:46 -
@@ -384,6 +384,7 @@
TESTSUITE_AT = tests/testsuite.at \
tests/libtoolize.at \
tests/duplicate_members.at \
+ tests/duplicate_conv.at \
tests/inherited_flags.at \
tests/convenience.at \
tests/link-order.at \
--- /dev/null 2006-01-25 19:46:43.433914872 +0100
+++ tests/duplicate_conv.at 2006-02-05 11:48:55.0 +0100
@@ -0,0 +1,81 @@
+# Hand crafted tests for GNU Libtool. -*- Autotest -*-
+# Copyright 2006 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+# 02110-1301, USA.
+
+AT_SETUP([duplicate convenience archive names])
+AT_KEYWORDS([libtool])
+
+# We create two convenience archives with the same name, and _also_
+# containing an object with the same name. This is necessary to detect
+# the failure with both 1.5.22 and HEAD, since the latter does not (did
+# not?) remove the temporary output directory, thus masking the failure
+# when all objects have distinct names.
+
+mkdir a b c
+
+echo 'int a () { return 0; }' a/a.c
+echo 'int a2() { return 0; }' b/a.c
+echo 'int b () { return 0; }' b/b.c
+echo 'extern int a(), a2(), b(); int c() { return a() + a2() + b(); }' c.c
+echo 'extern int c(); int main() { return c(); }'
Bug#348558: libtool: No such file or directory when linking 2 .la files with the same name but from different directories
tags 348558 + patch pending thanks On Sun, Feb 05, 2006 at 12:08:34PM +0100, Ralf Wildenhues wrote: Hi Bob, I have applied the patch (removed the now-obsolete change to testsuite.at, added a `libtool' testsuite keyword) to HEAD, and the corresponding change to branch-1-5; both patches are attached. I guess the tag pending would be appropriate for the Debian bugreport now. Thanks for all the work Ralf. I'll probably upload this if you make a new 1.5 release, or I have an other reason to upload a new 1.5 version. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348558: libtool: No such file or directory when linking 2 .la files with the same name but from different directories
[ this is http://bugs.debian.org/348558 ]
* Carlo Contavalli wrote on Wed, Jan 18, 2006 at 05:01:29PM CET:
On Wed, Jan 18, 2006 at 03:52:33PM +0100, Ralf Wildenhues wrote:
Try the patch at the end (not yet tested very much); it should not be
system-specific.
ok. just applied and tried a compilation. seems to work correctly.
Thanks.
libtool developers: OK to apply this patch and backport to branch-1-5?
Changes wrt. previous proposed patch in above thread: use lt1-libfoo.a
instead of libfoo.a-1 naming, for the dubious benefit of 8+3 filename
systems. And tests.
Long-winded explanation:
Carlo would like to add two convenience archives with the same name to a
library or a program. This currently fails on both CVS branches (in
slightly different ways), but IMHO it does not have to, since we can
disambiguate convenience archives by path (unlike real libraries!). The
patch below fixes this and adds tests to make sure it stays fixed.
Similarly, right now it is not possible to dlpreload two modules with
the same name; in addition to the bugfix below that would also need a
way to disambiguate the prefix for the symbol names. I actually believe
this can be done in principle (with a bit of help from the user side)
but will leave that for another patch to attack.
The last part of the test uses reloadable objects. We do not have any
test exposure for these yet -- which means, likely the test needs
adjusting for some systems.
Cheers,
Ralf
* libltdl/config/ltmain.m4sh (extracted_archives)
(extracted_serial): New globals.
(func_extract_archives): Use them to rename extraction archives
for linking against multiple convenience libraries with the same
name.
* tests/duplicate_conv.at: New tests.
* Makefile.am, tests/testsuite.at: Adjusted.
Reported by Carlo Contavalli [EMAIL PROTECTED].
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.28
diff -u -r1.28 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 11 Jan 2006 17:24:56 - 1.28
+++ libltdl/config/ltmain.m4sh 21 Jan 2006 07:50:42 -
@@ -116,6 +116,8 @@
preserve_args=
lo2o=s/\\.lo\$/.${objext}/
o2lo=s/\\.${objext}\$/.lo/
+extracted_archives=
+extracted_serial=0
opt_dry_run=false
opt_duplicate_deps=false
@@ -1051,7 +1053,17 @@
esac
func_basename $my_xlib
my_xlib=$func_basename_result
- my_xdir=$my_gentop/$my_xlib
+ my_xlib_u=$my_xlib
+ while :; do
+case $extracted_archives in
+ * $my_xlib_u *)
+ extracted_serial=`expr $extracted_serial + 1`
+ my_xlib_u=lt$extracted_serial-$my_xlib ;;
+ *) break ;;
+ esac
+ done
+ extracted_archives=$extracted_archives $my_xlib_u
+ my_xdir=$my_gentop/$my_xlib_u
func_mkdir_p $my_xdir
Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.185
diff -u -r1.185 Makefile.am
--- Makefile.am 3 Jan 2006 14:02:19 - 1.185
+++ Makefile.am 21 Jan 2006 07:50:41 -
@@ -383,6 +383,7 @@
TESTSUITE_AT = tests/testsuite.at \
tests/am-subdir.at \
tests/duplicate_members.at \
+ tests/duplicate_conv.at \
tests/inherited_flags.at \
tests/libtoolize.at \
tests/nonrecursive.at \
Index: tests/testsuite.at
===
RCS file: /cvsroot/libtool/libtool/tests/testsuite.at,v
retrieving revision 1.35
diff -u -r1.35 testsuite.at
--- tests/testsuite.at 16 Dec 2005 16:15:32 - 1.35
+++ tests/testsuite.at 21 Jan 2006 07:50:42 -
@@ -278,6 +278,7 @@
m4_include([libtoolize.at])
# Testing func_extract_archives
m4_include([duplicate_members.at])
+m4_include([duplicate_conv.at])
# Test that inherited_linker_flags in the .la actually gets used.
m4_include([inherited_flags.at])
# convenience archives test
--- /dev/null 1970-01-01 12:00:00.0 +0200
+++ tests/duplicate_conv.at 2006-01-21 07:46:51.0 +0100
@@ -0,0 +1,80 @@
+# Hand crafted tests for GNU Libtool. -*- Autotest -*-
+# Copyright 2006 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write
Bug#348558: libtool: No such file or directory when linking 2 .la files with the same name but from different directories
Thinking about this again: * Ralf Wildenhues wrote on Wed, Jan 18, 2006 at 03:52:33PM CET: * Carlo Contavalli wrote on Wed, Jan 18, 2006 at 02:26:27PM CET: If there's something not allowed/portable/..., I'd expect something like: moron don't do that! from libtool... Yeah, we could do that, too, iff we decide it can't be fixed. FWIW, for non-convenience libraries, where we /should/ output such a warning but don't, it's really far from trivial to decide safely iff the situation exists. Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348558: libtool: No such file or directory when linking 2 .la files with the same name but from different directories
On Sat, 21 Jan 2006, Ralf Wildenhues wrote: [ this is http://bugs.debian.org/348558 ] * Carlo Contavalli wrote on Wed, Jan 18, 2006 at 05:01:29PM CET: On Wed, Jan 18, 2006 at 03:52:33PM +0100, Ralf Wildenhues wrote: Try the patch at the end (not yet tested very much); it should not be system-specific. ok. just applied and tried a compilation. seems to work correctly. Thanks. libtool developers: OK to apply this patch and backport to branch-1-5? Changes wrt. previous proposed patch in above thread: use lt1-libfoo.a instead of libfoo.a-1 naming, for the dubious benefit of 8+3 filename systems. And tests. This patch seems fine (and worthwhile) to me. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348558: libtool: No such file or directory when linking 2 .la files with the same name but from different directories
Hi Carlo, * Carlo Contavalli wrote on Tue, Jan 17, 2006 at 07:04:55PM CET: With something like: libtool --mode=link gcc -g -O2 -std=c99 -Wall -pedantic -D_POSIX_C_SOURCE=200112L \ -Wall -export-dynamic -module -avoid-version -rpath /test -o test.la file.lo ../lib1/libtest.la ../lib2/libtest.la I get the error: [...] ar: .libs/test.lax/libtest.a/test1.o: No such file or directory make[1]: *** [test.la] Error 1 The error is quite obvious from libtool output: [...] rm -fr .libs/test.lax/libtest.a mkdir .libs/test.lax/libtest.a (cd .libs/test.lax/libtest.a ar x /test/lib1/.libs/libtest.a) rm -fr .libs/test.lax/libtest.a mkdir .libs/test.lax/libtest.a (cd .libs/test.lax/libtest.a ar x /test/lib2/.libs/libtest.a) [...] As you can see, the directory libtest.a is first created. There, lib1/libtest.a is extracted with ar x. Then, since lib2/libtest.a has the same filename, the directory libtest.a is removed, and recreated. The final result is that during link time the file test1.o is missing.. (lib1/libtest.a contains test1.o, while lib2/libtest.a contains test2.o). Thanks for the concise bug report. Two comments: your libtest.la libraries are convenience archives, so this usage should probably be accepted. At least ATM I don't know of a system where we can't make it work. With general libraries, however, using the same name for two different libraries is simply not portable -- some systems don't have the means to even specify them correctly on the command line, some systems simply have a shared library system that does not allow two libs with the same soname to be loaded in core simultaneously. It should be a rather easy workaround to simply to rename one of the libraries; is there a reason this is may be unduly difficult in your situation? Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348558: libtool: No such file or directory when linking 2 .la files with the same name but from different directories
On Wed, Jan 18, 2006 at 09:26:26AM +0100, Ralf Wildenhues wrote:
Thanks for the concise bug report. Two comments: your libtest.la
libraries are convenience archives, so this usage should probably
be accepted.
ok, we both agree on this :) I believe in this case it should be
fixed. A simple hack that worked for me was to modify
func_extract_archives() in ltmain.sh (around line 330 on 1.5.22),
changing:
my_xdir=$my_gentop/$my_xlib
to:
my_xdir=$my_gentop/$my_xlib.${RANDOM-0}
Assuming that $RANDOM comes from a prng with a long period, and that
the clashing libraries will hardly exceed the number of 1-2 on
most environments, it is reasonably safe to assume that no clashing will
ever take place.
The error seems to be reported only while working on .a files, no
warning/error while working on .so files.
With general libraries, however, using the same name
for two different libraries is simply not portable -- some systems
don't have the means to even specify them correctly on the command
line, some systems simply have a shared library system that does not
allow two libs with the same soname to be loaded in core simultaneously.
It should be a rather easy workaround to simply to rename one of the
libraries; is there a reason this is may be unduly difficult in your
situation?
actually, my environment is much more complex than the example I provided.
litest.la are both supposed to be _modules_ (to be dlopened), not simple
libraries.
The directory hierarchy is some kind of namespace, handled
directly by the application itself that takes care of handling path
problems with dlopen family.
The problem is that some of the modules, choosen at configure time,
are to be compiled into the application itself, to allow the application
to bootstrap. Those modules are thus compiled twice, in two different
build trees: once, as dynamic modules, and one more time as convenience
libraries.
The binaries that need those modules to bootstrap are then linked against
them with simple libtool options. Renaming the module would both imply
a flat namespace, which is something I'd rather try to avoid, and a
complete rework of modules naming conventions (lot of changes in .m4
macros for configure, and a lot of coding).
The curios thing is that from the build tree I generate both a couple
binaries using those convenience libraries with the same name, and
another module to be loaded into an external application that needs
those libraries too to bootstrap.
Well, with the binaries, I don't get any warning nor error, and
they seem to work correctly both on linux and freebsd (uhm.. now
that I look at them, ldd does not list those two libraries in
them... let's look at the options I've used...).
However, it is only the module that triggers the error I just
reported.
If there's something not allowed/portable/..., I'd expect something
like: moron don't do that! from libtool...
If you need to, I can do some tests / checks or provide you with
the full command lines used to compile the various components,
or as much help as I can. I'm also open to suggestions...
I know it's something you'd rather try to avoid, but the code I'm
working on is released under GPL. If you need to, you can test it
by yourself by checking it out from the public TLA archives or I
can send you a complete tarball with a brief description of the
installation process.
Forgive my english, hope I've been clear enough and that this
mail is understandable.
Just let me know,
TIA,
Carlo
--
GPG Fingerprint: 2383 7B14 4D08 53A4 2C1A CA29 9E98 5431 1A68 6975
-
Yesterday I was a dog. Today I'm a dog. Tomorrow I'll probably still
be a dog. Sigh! There's so little hope for advancement.
-- Snoopy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348558: libtool: No such file or directory when linking 2 .la files with the same name but from different directories
Hi Carlo,
* Carlo Contavalli wrote on Wed, Jan 18, 2006 at 02:26:27PM CET:
On Wed, Jan 18, 2006 at 09:26:26AM +0100, Ralf Wildenhues wrote:
Thanks for the concise bug report. Two comments: your libtest.la
libraries are convenience archives, so this usage should probably
be accepted.
ok, we both agree on this :) I believe in this case it should be
fixed. A simple hack that worked for me was to modify
func_extract_archives() in ltmain.sh (around line 330 on 1.5.22),
changing:
my_xdir=$my_gentop/$my_xlib
to:
my_xdir=$my_gentop/$my_xlib.${RANDOM-0}
Ouch. This can get you in trouble, e.g. by a full disk after several
tests with RM=': '. Or, worse, it won't work on systems where the
selected shell does not know $RANDOM.
Assuming that $RANDOM comes from a prng with a long period, and that
the clashing libraries will hardly exceed the number of 1-2 on
most environments, it is reasonably safe to assume that no clashing will
ever take place.
Try the patch at the end (not yet tested very much); it should not be
system-specific.
The error seems to be reported only while working on .a files, no
warning/error while working on .so files.
It should happen for convenience archives only, I believe.
It should be a rather easy workaround to simply to rename one of the
libraries; is there a reason this is may be unduly difficult in your
situation?
actually, my environment is much more complex than the example I provided.
litest.la are both supposed to be _modules_ (to be dlopened), not simple
libraries.
OK, I kind of guessed it would be complex. ;-)
The directory hierarchy is some kind of namespace, handled
directly by the application itself that takes care of handling path
problems with dlopen family.
Does it use libltdl for dlpreopening static components?
The problem is that some of the modules, choosen at configure time,
are to be compiled into the application itself, to allow the application
to bootstrap. Those modules are thus compiled twice, in two different
build trees: once, as dynamic modules, and one more time as convenience
libraries.
This may not be necessary, at least there are some situations in which
you may be able to get around double compilation.
The binaries that need those modules to bootstrap are then linked against
them with simple libtool options. Renaming the module would both imply
a flat namespace, which is something I'd rather try to avoid, and a
complete rework of modules naming conventions (lot of changes in .m4
macros for configure, and a lot of coding).
Sure.
If there's something not allowed/portable/..., I'd expect something
like: moron don't do that! from libtool...
Yeah, we could do that, too, iff we decide it can't be fixed.
If you need to, I can do some tests / checks or provide you with
the full command lines used to compile the various components,
or as much help as I can. I'm also open to suggestions...
Either post all `libtool --mode=link' lines including complete output
(also of the convenience libs!), or, even better..
I know it's something you'd rather try to avoid, but the code I'm
working on is released under GPL. If you need to, you can test it
by yourself by checking it out from the public TLA archives or I
can send you a complete tarball with a brief description of the
installation process.
..show the source (in any one of the ways suggested). I'm eager to
see complex real-world setups also to learn more about possible traps
to avoid in libtool.
Note to Debian libtool maintainer: do not apply the patch below (just
yet). Not much tested yet, needs testsuite additions, etc.
Cheers,
Ralf
* ltmain.in (extracted_archives, extracted_serial): New globals.
(func_extract_archives): Use them to rename extraction archives
for multiple convenience libraries with the same name.
Reported by Carlo Contavalli [EMAIL PROTECTED].
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v
retrieving revision 1.334.2.116
diff -u -r1.334.2.116 ltmain.in
--- ltmain.in 11 Jan 2006 17:25:31 - 1.334.2.116
+++ ltmain.in 18 Jan 2006 14:51:40 -
@@ -136,6 +136,8 @@
preserve_args=
lo2o=s/\\.lo\$/.${objext}/
o2lo=s/\\.${objext}\$/.lo/
+extracted_archives=
+extracted_serial=0
#
# Shell function definitions:
@@ -327,7 +329,17 @@
*) my_xabs=`pwd`/$my_xlib ;;
esac
my_xlib=`$echo X$my_xlib | $Xsed -e 's%^.*/%%'`
- my_xdir=$my_gentop/$my_xlib
+ my_xlib_u=$my_xlib
+ while :; do
+case $extracted_archives in
+ * $my_xlib_u *)
+ extracted_serial=`expr $extracted_serial + 1`
+ my_xlib_u=$my_xlib-$extracted_serial ;;
+ *) break ;;
+ esac
+ done
+ extracted_archives=$extracted_archives $my_xlib_u
+ my_xdir=$my_gentop/$my_xlib_u
Bug#348558: libtool: No such file or directory when linking 2 .la files with the same name but from different directories
On Wed, Jan 18, 2006 at 03:52:33PM +0100, Ralf Wildenhues wrote: [...] Ouch. This can get you in trouble, e.g. by a full disk after several tests with RM=': '. Or, worse, it won't work on systems where the selected shell does not know $RANDOM. makes sense :) it was just a quick hack to get it working asap, and to see if the problem really lied there. Try the patch at the end (not yet tested very much); it should not be system-specific. ok. just applied and tried a compilation. seems to work correctly. The directory hierarchy is some kind of namespace, handled directly by the application itself that takes care of handling path problems with dlopen family. Does it use libltdl for dlpreopening static components? right now, no. I use simple wrappers around dlopen. However, it is planned to migrate to libtldl. The code that takes care of loading the modules is itself a module, so I guess there won't be many problems to migrate :)... libraries. This may not be necessary, at least there are some situations in which you may be able to get around double compilation. makes sense. If you need to, I can do some tests / checks or provide you with the full command lines used to compile the various components, or as much help as I can. I'm also open to suggestions... Either post all `libtool --mode=link' lines including complete output (also of the convenience libs!), or, even better.. [...] ..show the source (in any one of the ways suggested). I'm eager to see complex real-world setups also to learn more about possible traps to avoid in libtool. Ok, if you go to: http://www.pigeonair.org/libtool/ you can find: make-all.log - log of the `make all'. Should be easy enough to grep for --mode=link (both stderr and stdout are included) make-install.log - log of the `make install', as above. configure.log - log of the configure output. Pretty much useless. pigeondeliver--main--2.0--patch-174.tar.gz - complete sources of the application + the patch you provided to ltmain.sh + a new configure. (will be committed in patch-175 in the tla tree). Since I usually compile everything in the build directory, with something like: mkdir build cd build ../configure ... make, and since most of the Makefiles are generated at ./configure time, I also provided a: build.tar.gz - with the complete build directory and all the Makefiles generated on my debian system. To access the TLA tree, you can follow the instructions on www.pigeonair.net/main/tla.xml. Make sure to have tla 1.3.x. The problem arises when compiling utils/dscm-dict (in the source tree -- build-custom/dict-dscm in the build tree). The same double library with same name is also used by sapi/postfix (build-sapi/runnable/postfix). Only when linking against postfix on a debian system, or on a system with the patch written by LaMont Jones to make postfix compile shared libraries instead of .a files. Note that this is still a public pre-pre-release, and the build system still needs _lot of tuning_ and _lots of work_. There are tons of .m4 macros, too many useless expansions, and a brand new modular structure that still needs many infrastructures. I have still tons of modules to port to this release... The build system is in a very early stage of development, and is very non standard (quite sick right now), even if I'd like to make it generic enough to be detached from pigeondeliver and suitable to make modular projects a la php or apache. To get started on a debian system, I'd suggest you to do something like: # apt-get install postfix-dev libldap2-dev $ cd pigeondeliver--main* $ mkdir build cd build $ bash ../examples/configure/configure.debian.libpostfix (../examples... is an example of how to run the configure) $ make # make install Keep in mind that the build tree has nothing to do with the source tree. The build tree resembles the final namespace that will be used when modules are installed. runnable/loadable/... are all different methods that can be used to compile a given component. Right now, it doesn't make much sense. It will as time goes on. Each method is mapped to a file in m4/methods/. I'm open to any suggestion. If you need further details, or you are courious about the structure of the build system, just let me know :) Cheers, Carlo -- GPG Fingerprint: 2383 7B14 4D08 53A4 2C1A CA29 9E98 5431 1A68 6975 - I'm all for computer dating, but I wouldn't want one to marry my sister. The possession of a book becomes a substitute for reading it. -- Anthony Burgess -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348558: libtool: No such file or directory when linking 2 .la files with the same name but from different directories
Package: libtool
Version: 1.5.22-2
Severity: normal
With something like:
libtool --mode=link gcc -g -O2 -std=c99 -Wall -pedantic
-D_POSIX_C_SOURCE=200112L \
-Wall -export-dynamic -module -avoid-version -rpath /test -o test.la file.lo
../lib1/libtest.la ../lib2/libtest.la
I get the error:
[...]
ar: .libs/test.lax/libtest.a/test1.o: No such file or directory
make[1]: *** [test.la] Error 1
The error is quite obvious from libtool output:
[...]
rm -fr .libs/test.lax/libtest.a
mkdir .libs/test.lax/libtest.a
(cd .libs/test.lax/libtest.a ar x /test/lib1/.libs/libtest.a)
rm -fr .libs/test.lax/libtest.a
mkdir .libs/test.lax/libtest.a
(cd .libs/test.lax/libtest.a ar x /test/lib2/.libs/libtest.a)
[...]
As you can see, the directory libtest.a is first created.
There, lib1/libtest.a is extracted with ar x. Then, since lib2/libtest.a
has the same filename, the directory libtest.a is removed,
and recreated. The final result is that during link time
the file test1.o is missing.. (lib1/libtest.a contains test1.o, while
lib2/libtest.a contains test2.o).
In the example above, I had to edit some paths. Hope it
doesn't impair too much the ability to reproduce the bug.
Cheers,
Carlo
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages libtool depends on:
ii autotools-dev 20050422.1 Update infrastructure for config.{
ii cpp 4:3.3.5-3 The GNU C preprocessor (cpp)
ii file 4.12-1 Determines file type using magic
ii gcc [c-compiler] 4:3.3.5-3 The GNU C compiler
ii gcc-3.3 [c-compiler] 1:3.3.6-5 The GNU C compiler
ii gcc-3.4 [c-compiler] 3.4.4-0The GNU C compiler
ii gcc-4.0 [c-compiler] 4.0.2-4The GNU C compiler
ii libc6-dev [libc-dev] 2.3.5-3GNU C Library: Development Librari
Versions of packages libtool recommends:
ii libltdl3-dev 1.5.6-6A system independent dlopen wrappe
-- no debconf information
--
GPG Fingerprint: 2383 7B14 4D08 53A4 2C1A CA29 9E98 5431 1A68 6975
-
Vitamin C deficiency is apauling.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
