Re: still can't build libtool
On Sat, Jan 05, 2002 at 03:25:41PM -0600, Bob Friesenhahn wrote: Using the exact files from libtool CVS, and the current released autoconf and automake, I get this error at the 'make' stage: Making all in libltdl gmake[1]: Entering directory `/home/bfriesen/src/gnu/libtool/libltdl' gmake[1]: *** No rule to make target `@MAINTAINER_MODE_TRUE@', needed by `Makefile'. Stop. gmake[1]: Leaving directory `/home/bfriesen/src/gnu/libtool/libltdl' gmake: *** [all-recursive] Error 1 Ideas? I just did the following (Solaris 8/SPARC): $ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/libtool login $ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/libtool co libtool $ cd libtool $ PATH=$PATH:/opt/TWWfsw/autoconf25/bin:/opt/TWWfsw/automake15 \ sh -x bootstrap $ CC=cc CXX=CC ./configure $ gmake [success] $ grep MAINTAINER_MODE_TRUE Makefile.in libltdl/Makefile.in [nothing] No problems. What procedure are you using? This is with Autoconf 2.52 and Automake 1.5. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool CVS permanently broken?
On Sat, Jan 05, 2002 at 03:10:58PM -0600, Bob Friesenhahn wrote:
It looks like the aborted configure run I was seeing was due to an
update I made to configure.ac to try to get 'make dist' to actually
work. My update was missing a quote. Sorry about that.
The automake warning/error remains.
I tried to reproduce your warning/error but I could not. The section
of code in automake looks fine to me.
# Ensure a file exists.
sub create
{
my ($file) = @_;
my $touch = new IO::File ( $file);
$touch-close;
}
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.4 branch and IRIX 6.x
When using CC=cc on IRIX 6.x, ld is used to create shared libraries.
However:
hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
This causes -Wl,-rpath to be passed to ld. Unfortunately, ld
recognizes -rpath but not -Wl so we get errors like:
(null): WARNING 1 : Unknown option: Wl,-rpath (ignored).
So, the solution would seem to be the patch below. However, after
applying this patch and running 'make check', build-relink2 dies at
the end:
if test $shlibpath_overrides_runpath != yes; then
rm -f $objdir/lt-depdemo || exit 1
cp $objdir/depdemo $objdir/lt-depdemo || exit 1
echo running ../depdemo/depdemo with installed libl3.la
if ./depdemo; then
echo Worked, as expected
else
echo shlibpath_overrides_runpath should be set to yes
status=1
fi
rm -f $objdir/lt-depdemo
fi
For IRIX 6.x:
shlibpath_overrides_runpath = no
because, according to rld(5):
The search path for shared objects is as follows:
1. The path of the shared object, if specified in the liblist. That
is, if the soname of the shared object has a path. For more
information, see the ld(1) man page.
2. DT_RPATH, if it is defined in the executable or any DSO that rld
has opened.
3. Use LD_LIBRARY_PATH, if it is defined in the environment at the
time of execution.
4. The default library search path.
However:
$ elfdump -L depdemo/.libs/depdemo | grep RPATH
/opt/build/libtool-1.4.2/depdemo/l1/.libs:/opt/build/libtool-1.4.2/tests/_inst/lib:/opt/build/libtool-1.4.2/depdemo/l2/.libs:/opt/build/libtool-1.4.2/depdemo/l3/.libs:/opt/build/libtool-1.4.2/tests/_inst/lib/extra
Both /opt/build/libtool-1.4.2/depdemo/l3/.libs and
/opt/build/libtool-1.4.2/tests/_inst/lib/extra contain libl3.so.1.0 so
the version in /opt/build/libtool-1.4.2/depdemo/l3/.libs is selected
as it is first in the search path. However, before the
shlibpath_overrides_runpath test, we broke libl3.so.1.0 earlier in
build-relink2 so libl3.so.1.0 does not contain var_l3. This results
in:
$ .libs/depdemo
174396:./depdemo: rld: Error: unresolvable symbol in
/opt/build/libtool-1.4.2/tests/_inst/lib/libl4.so.1: var_l3
174396:./depdemo: rld: Fatal Error: this executable has unresolvable
symbols
causing the test to fail. So, is build-relink2.test broken?
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.166.2.32
diff -u -3 -p -r1.166.2.32 libtool.m4
--- libtool.m4 15 Nov 2001 01:22:58 - 1.166.2.32
+++ libtool.m4 28 Jan 2002 17:37:35 -
@@ -1636,10 +1636,11 @@ else
irix5* | irix6* | nonstopux*)
if test $GCC = yes; then
archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname
${wl}$soname `test -n $verstring echo ${wl}-set_version ${wl}$verstring`
${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
+ hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
else
archive_cmds='$LD -shared $libobjs $deplibs $linker_flags -soname $soname `test
-n $verstring echo -set_version $verstring` -update_registry
${output_objdir}/so_locations -o $lib'
+ hardcode_libdir_flag_spec='-rpath $libdir'
fi
-hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
hardcode_libdir_separator=:
link_all_deplibs=yes
;;
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Building projects on i386-pc-solaris2.8
On Thu, Jan 31, 2002 at 02:04:27PM -0500, Allan McIntosh wrote: I rewrote a project's build process to use autotools and libtool. Everything builds fine but the binary seg faults at run time(in i386 solaris2.8 ). Does anyone know of any issues or AC_ AM_ macros that are absolutely required to build shared objects and dynamicly linked binaries(when porting to intel solaris2.8)? The binary builds and runs fine on Redhat 7.2. However when I build the target in i386-pc-solaris2.8 it segment faults when I run it. If I build it with out libtool and autotools it is fine. Even if you --disable-shared? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and gcj
On Sat, Feb 23, 2002 at 08:08:53AM -0800, Anthony Green wrote: I've been using a hacked version of libtool to build shared libraries of java code in with gcj. The one problem I had to work around is that libtool insists on adding -DPIC to the compilation line. gcj's -D is different from gcc and g++. My hack is to simply strip out the -D. However - now my tree contains a mix of java and c code and I need to use -DPIC with gcc. How do we change libtool to only use -DPIC where appropriate? This gets added by libtool.m4 here (line 4311): case $host_os in # For platforms which do not support PIC, -DPIC is meaningless: *djgpp*) _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)= ;; *) _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) -DPIC ;; esac This seems quite wrong. Why do we assume the compiler will grok -DPIC? Why isn't this handled in the tag-specific and os-specific portions of libtool.m4? If the tag/os combo says -KPIC is needed, why do we -KPIC -DPIC? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and gcj
On Fri, Mar 01, 2002 at 06:58:08AM -0800, Anthony Green wrote: On Fri, 2002-03-01 at 00:19, Per Bothner wrote: Of course the real fix involves fixing ltmain.sh, but that goes beyond my ability to peer into the bowels of libtool. The other bad thing I should mention is the test to see if gcj can use both -c and -o. This test is failing for some unknown reason, causing bad problems for my project. I don't think libtool should even perform this test. gcj is known to always handle -c and -o. What version of gcj are you using? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and gcj
On Fri, Mar 01, 2002 at 06:58:08AM -0800, Anthony Green wrote:
On Fri, 2002-03-01 at 00:19, Per Bothner wrote:
Of course the real fix involves fixing ltmain.sh, but that goes
beyond my ability to peer into the bowels of libtool.
The other bad thing I should mention is the test to see if gcj can use
both -c and -o. This test is failing for some unknown reason, causing
bad problems for my project. I don't think libtool should even perform
this test. gcj is known to always handle -c and -o.
Try the patch below and let me know if it works. Note this removes
-DPIC completely (even for C, C++).
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.248
diff -u -3 -p -r1.248 libtool.m4
--- libtool.m4 7 Feb 2002 19:54:36 - 1.248
+++ libtool.m4 1 Mar 2002 17:31:17 -
@@ -832,8 +832,8 @@ AC_CACHE_CHECK([if $compiler supports -c
CFLAGS=$CFLAGS -o out/conftest2.$ac_objext],
[$1],[CXX],[save_CXXFLAGS=$CXXFLAGS
CXXFLAGS=$CXXFLAGS -o out/conftest2.$ac_objext],
- [$1],[GCJ],[save_GCJFLAGS=$GCJFLAGS
- GCJFLAGS=$GCJFLAGS -o out/conftest2.$ac_objext])
+ [$1],[GCJ],[save_CFLAGS=$CFLAGS
+ CFLAGS=$GCJFLAGS -o out/conftest2.$ac_objext])
echo $lt_simple_compile_test_code conftest.$ac_ext
# According to Tom Tromey, Ian Lance Taylor reported there are C compilers
@@ -856,7 +856,7 @@ AC_CACHE_CHECK([if $compiler supports -c
fi
ifelse([$1],[],[CFLAGS=$save_CFLAGS],
[$1],[CXX],[CXXFLAGS=$save_CXXFLAGS],
- [$1],[GCJ],[GCJFLAGS=$save_GCJFLAGS])
+ [$1],[GCJ],[CFLAGS=$save_CFLAGS])
chmod u+w .
$rm conftest* out/*
rmdir out
@@ -3155,7 +3158,7 @@ objext=o
_LT_AC_TAGVAR(objext, $1)=$objext
# Code to be used in simple compile tests
-lt_simple_compile_test_code=class foo {}
+lt_simple_compile_test_code=class foo {};
# Code to be used in simple link tests
lt_simple_link_test_code='public class conftest { public static void main(String[]
argv) {}; }'
@@ -4294,7 +4297,7 @@ AC_MSG_RESULT([$_LT_AC_TAGVAR(lt_prog_co
if test -n $_LT_AC_TAGVAR(lt_prog_compiler_pic, $1); then
AC_LIBTOOL_COMPILER_OPTION([if $compiler PIC flag
$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) works],
_LT_AC_TAGVAR(lt_prog_compiler_pic_works, $1),
-[$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) -DPIC], [],
+[$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)], [],
[case $_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) in
| *) ;;
*) _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) ;;
@@ -4302,15 +4305,6 @@ if test -n $_LT_AC_TAGVAR(lt_prog_compi
[_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
_LT_AC_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no])
fi
-case $host_os in
- # For platforms which do not support PIC, -DPIC is meaningless:
- *djgpp*)
-_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
-;;
- *)
-_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)
-DPIC
-;;
-esac
])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: GCJFLAGS
On Fri, Mar 01, 2002 at 12:01:24PM -0700, Tom Tromey wrote: Albert == Albert Chin [EMAIL PROTECTED] writes: Albert Why does HEAD libtool use GCJFLAGS when autoconf 2.5x doesn't Albert support it? The support is in automake. That doesn't help when running autoconf though. Specifically, from libtool.m4: AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext], [_LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)], [_LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)=no $rm -r conftest 2/dev/null mkdir conftest cd conftest mkdir out ifelse([$1],[],[save_CFLAGS=$CFLAGS CFLAGS=$CFLAGS -o out/conftest2.$ac_objext], [$1],[CXX],[save_CXXFLAGS=$CXXFLAGS CXXFLAGS=$CXXFLAGS -o out/conftest2.$ac_objext], [$1],[GCJ],[save_GCJFLAGS=$GCJFLAGS GCJFLAGS=$GCJFLAGS -o out/conftest2.$ac_objext]) echo $lt_simple_compile_test_code conftest.$ac_ext ... ifelse([$1],[],[CFLAGS=$save_CFLAGS], [$1],[CXX],[CXXFLAGS=$save_CXXFLAGS], [$1],[GCJ],[GCJFLAGS=$save_GCJFLAGS]) I've patched this to use CFLAGS in exchange for GCJFLAGS but only when doing tests like the above. GCJFLAGS is still present in Makefile.am. Shouldn't autoconf support gcj natively? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: No static libraries?
On Fri, Mar 01, 2002 at 02:15:05PM -0800, Anthony Green wrote: I think this is my final real problem with the CVS version of libtool (once Per's patch is applied). Libtool isn't building static libraries for my project, although it does try to install them (and fail). You need to be more specific. 1. Does it fail while configuration your application to detect that static libraries can be built? 2. For what compiler (C, C++, GCJ)? A snippet of the ./configure run would help too. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ltconfig for s/390
On Wed, Mar 13, 2002 at 08:50:32AM -0600, Konkol, Josh wrote: Hello all, I'm trying to install RRDtool on Linux running on a Mainframe. My problem is when I run configure I get the error: checking host system type... Invalid configuration `s390-unknown-linux-gnu': machine `s390-unknown' not recognized .snip. ltconfig: you must specify a host type if you use `--no-verify' Try `ltconfig --help' for more information. configure: error: libtool configure failed Grab a copy of the latest config.guess and config.sub from: ftp://ftp.gnu.org/gnu/config and rerun ./configure. Let us know if it works. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
On Tue, Oct 08, 2002 at 11:17:55AM -0500, Bob Friesenhahn wrote: Wouldn't it be better to get libtool 1.5 out the door? The resources required to achieve a releasable product are similar and CVS libtool already contains most of the fixes that would go into a 1.4.3. I'd like to see 1.4.3. Who else is onboard? What is required to make a release happen? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
On Tue, Oct 08, 2002 at 03:38:17PM -0500, Robert Boehne wrote: So a 1.4.3 version is desired, that's established. The million-dollar question is: Does current branch-1-4 Libtool do the trick? If so, then a roll out could be done within the week. I've got some patches I'd like to roll in. I'll submit them tomorrow. How about a test tarball 10/12. That should give others enough time to get in some patches that might be in the queue. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.5
On Wed, Oct 09, 2002 at 12:29:44PM -0500, Bob Friesenhahn wrote: On Wed, 9 Oct 2002, Guido Draheim wrote: In my experience, the 1.5 code-base is a solid product on systems supported by 1.4.2, and provided that it is patched and proven to work under MinGW and Darwin then 1.5 should be ready to release. That's another argument. And since it was missed to push 1.4.3 out to the world when it was due, we can as well dump the work that I and others have done on the libtool-1-4 branch and well move ahead. Anyway, it would be nice if you'd find some nice words for those who were not on your branch of the developments, for which I understand you are proud of what you've achieved and that you want to have it out and recognized. I do not mean to slight the supporters of a 1.4.3 release at all. I believe that supporters of a 1.4.3 release have only the best intentions and that many libtool users (but not libtool itself) would benefit from a 1.4.3 release. To clarify things, until very recently I have served only the role of a libtool user, not a libtool developer. While I have used the libtool code which would become 1.5 through its entire development, I have contributed little to it. The gestation period for 1.5 spans well over two years because for quite a long time it lived in the multi-language-branch. Developers like Ossama Othman, Robert Boehne, and Gary Vaughan deserve credit for this work. I won't debate the value of 1.5. Are developers moving to autoconf 2.5x in droves? I think the developers interested in moving to 2.5x will be interested in a 1.5 release as it will force them to move to 2.5x. However, for those that don't, I support the 1.4.3 interim release for those wishing to remain at 2.13 for whatever reason. If someone is willing to spin the release, I'd like to see us move ahead with a 1.4.3. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
On Tue, Oct 15, 2002 at 10:43:08AM -0500, Bob Friesenhahn wrote: On Tue, 15 Oct 2002, Max Bowsher wrote: The idea of supporting a --bindir option is tempting, but then 'libtool --mode=install' stops looking like a simple install program, and in fact, the --bindir option would need to be passed for several different phases of libtool operation since it would influence the content of the library.la file. Since Windows may be the only OS benefiting from this, we could have a case of the tail wagging the dog. So we conditionalize all this so it only activates on Windows. There is a fundamental flaw with this logic. Sorry to dissapoint you, but most open source software using libtool does not originate from the Windows environment. :-) If you rely on a feature which only takes effect under Windows, then packages will neglect to enable or test that feature, resulting in packages which do not build properly (or misbehave) under Windows. Doesn't this conflict with the libtool option -no-undefined: - Macro: AC_LIBTOOL_WIN32_DLL This macro should be used if the package has been ported to build clean dlls on win32 platforms. Usually this means that any library data items are exported with `__declspec(dllexport)' and imported with `__declspec(dllimport)'. If this macro is not used, libtool will assume that the package libraries are not dll clean and will build only static libraries on win32 hosts. This macro must be called *before* `AC_PROG_LIBTOOL', and provision must be made to pass `-no-undefined' to `libtool' in link mode from the package `Makefile'. Naturally, if you pass `-no-undefined', you must ensure that all the library symbols *really are* defined at link time! It seems that CYGWIN needs -no-undefined but this might be problematic on other unices. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: no AIX 5 support? I've got some idea what's needed.
On Tue, Dec 03, 2002 at 10:21:53AM -0600, [EMAIL PROTECTED] wrote: That seems rather odd to me. -G is a linker flag, and no matter which compiler you use, the AIX ld command is what is eventually invoked. libtool probably assumes that gcc -shared will do the right thing. I don't think GCC knows how to create -brtl-style shared libraries on AIX. Looking at libtool.m4, when GCC is used, -G is *not* added. Dan From [EMAIL PROTECTED] Tue Dec 3 05:38:03 2002 I've seen reports from Apache-2.0+AIX users that -G isn't added with gcc, but I see it added with xlc_r. By any chance is that something you can confirm or deny? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: non-GNU sed complanits from Libtool CVS
On Fri, Dec 13, 2002 at 12:37:14AM -0600, Robert Boehne wrote: I'm seeing this sed invocation spitting out complaints on any platform not using GNU sed, i.e. OS X, FreeBSD, IRIX, Tru64 to name a few. Any idea why? lt_compile=`echo $ac_compile | sed \ -e 's:.*FLAGS\}\? :$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag:; t' \ -e 's:$: $lt_compiler_flag:'` Replace 'FLAGS\}\?' with 'FLAGS}?'. BTW, I don't show a failure on Tru64 UNIX 4.0D nor 5.1. But, I have some patches on these machines. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
hppa*64* and dependent libraries
Dependent libraries for hppa64* is funky. $ cd /tmp/a $ ld -b +h lib1.sl.0 -o lib1.sl obj1.o obj2.o -lc $ elfdump -L lib1.sl | head 0 Needed libc.2 1 Soname lib1.sl.0 $ cd /tmp/b $ ld -b +h lib2.sl.0 -o lib2.sl ../a/lib1.sl obj3.o obj4.o -lc $ elfdump -L lib2.sl | head 0 Needed lib1.sl.0 1 Needed libc.2 2 Soname lib2.sl.0 $ cd /tmp $ ld -b +h lib3.sl.0 -o lib3.sl a/lib1.sl b/lib2.sl obj5.o ld: Can't find dependent library libl1.sl.0 $ ld -b +h lib3.sl.0 -o lib3.sl -La b/lib2.sl obj5.o According to http://docs.hp.com/hpux/onlinedocs/B2355-90655/B2355-90655.html: * All DT_NEEDED entries with no / in the libname are subject to dynamic path lookup. We have two possible solutions: (1) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a ../a/lib1.sl obj3.o obj4.o -lc (2) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a -l1 obj3.o obj4.o -lc I've confirmed the above behaviour with a post to the HP-UX Developer Mailing List. It's frustrating that even though we explicitly list a/lib1.sl in the link line, it doesn't help. So, is there anything in libtool to already do this? If not, do we adopt solution #1 or #2? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: hppa*64* and dependent libraries
On Sat, Dec 14, 2002 at 03:22:42AM -0600, Albert Chin wrote:
Dependent libraries for hppa64* is funky.
$ cd /tmp/a
$ ld -b +h lib1.sl.0 -o lib1.sl obj1.o obj2.o -lc
$ elfdump -L lib1.sl | head
0 Needed libc.2
1 Soname lib1.sl.0
$ cd /tmp/b
$ ld -b +h lib2.sl.0 -o lib2.sl ../a/lib1.sl obj3.o obj4.o -lc
$ elfdump -L lib2.sl | head
0 Needed lib1.sl.0
1 Needed libc.2
2 Soname lib2.sl.0
$ cd /tmp
$ ld -b +h lib3.sl.0 -o lib3.sl a/lib1.sl b/lib2.sl obj5.o
ld: Can't find dependent library libl1.sl.0
$ ld -b +h lib3.sl.0 -o lib3.sl -La b/lib2.sl obj5.o
According to
http://docs.hp.com/hpux/onlinedocs/B2355-90655/B2355-90655.html:
* All DT_NEEDED entries with no / in the libname are subject to
dynamic path lookup.
We have two possible solutions:
(1) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a ../a/lib1.sl obj3.o obj4.o -lc
(2) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a -l1 obj3.o obj4.o -lc
I've confirmed the above behaviour with a post to the HP-UX Developer
Mailing List. It's frustrating that even though we explicitly list
a/lib1.sl in the link line, it doesn't help.
So, is there anything in libtool to already do this? If not, do we
adopt solution #1 or #2?
Ok, there is another option:
(3) ld -b +h lib2.sl.0 -o lib2.sl +b /tmp/a ../a/lib1.sl obj3.o obj4.o -lc
I've chosen to use option #3 because libtool has code to handle most
of it. I've configure hppa64 such that:
hardcode_direct=no
hardcode_into_libs=yes
hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
However, I now have the problem that I need '+b' for ld and '-Wl,+b'
for cc. Because there is not a separate $hardcode_libdir_flag_spec for
ld/cc, I have to hack libtool.m4 like:
case ${LD} in
*/ld*)
wl=
esac
eval dep_rpath=\$hardcode_libdir_flag_spec\
This is gross. I have no problem modifying $hardcode_libdir_flag_spec
so it's rewritten as:
hardcode_libdir_flag_spec=`if linking with ld; then +b $libdir;
else ${wl}+b ${wl}$libdir`
However, I don't see an easy way to detect at runtime whether or not
we're using ld/cc to link/compile. So, what do I do? Should I
introduce a separate hardcode_libdir_flag_spec for creating shared
libraries and one for creating programs?
BTW, this is relative to 1.4 but the same problems no doubt exist in
HEAD.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: hppa*64* and dependent libraries
On Wed, Dec 18, 2002 at 07:45:36PM -0500, Boehne, Robert wrote:
Post the patch you have for 1.4. I'm curious as to why you need to
set $wl at all, if linking is being done with ld then ${wl}= for
any flag. IMHO, if that isn't being done properly we need to find
out why.
There's a small patch in here too for IRIX so just ignore it.
As an example, the following links libpng 1.2.4 as a shared library
and a test program:
...
/bin/sh ./libtool --mode=link cc +DD64 +O2 +ESlit +Onofltacc
+Oentrysched +Odataprefetch +Onolimit
-L/opt/TWWfsw/zlib11/lib/pa20_64 -o libpng.la -rpath
/opt/TWWfsw/libpng12/lib/pa20_64 -version-info 2:2:0 -module png.lo
pngerror.lo pngget.lo pngmem.lo pngpread.lo pngrio.lo pngread.lo
pngrtran.lo pngrutil.lo pngset.lo pngtrans.lo pngwio.lo pngwrite.lo
pngwtran.lo pngwutil.lo -lz -lm
rm -fr .libs/libpng.la .libs/libpng.* .libs/libpng.*
/usr/ccs/bin/ld -b +h libpng.sl.2 -o .libs/libpng.sl.2.2 png.o
pngerror.o pngget.o pngmem.o pngpread.o pngrio.o pngread.o pngrtran.o
pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o
pngwutil.o +b /opt/TWWfsw/zlib11/lib/pa20_64
-L/opt/TWWfsw/zlib11/lib/pa20_64
/opt/TWWfsw/zlib11/lib/pa20_64/libz.sl -lm -lc
(cd .libs rm -f libpng.sl.2 ln -s libpng.sl.2.2 libpng.sl.2)
...
/bin/sh ./libtool --mode=link cc +DD64 +O2 +ESlit +Onofltacc
+Oentrysched +Odataprefetch +Onolimit
-L/opt/TWWfsw/zlib11/lib/pa20_64 -o pngtest pngtest.o libpng.la -lz
-lm
cc +DD64 +O2 +ESlit +Onofltacc +Oentrysched +Odataprefetch +Onolimit
-o .libs/pngtest pngtest.o -L/opt/TWWfsw/zlib11/lib/pa20_64
./.libs/libpng.sl /opt/TWWfsw/zlib11/lib/pa20_64/libz.sl -lm -Wl,+b
-Wl,/opt/TWWfsw/libpng12/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64
...
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.166.2.45
diff -u -3 -p -r1.166.2.45 libtool.m4
--- libtool.m4 11 Oct 2002 16:06:07 - 1.166.2.45
+++ libtool.m4 19 Dec 2002 01:21:10 -
@@ -910,7 +910,14 @@ AC_CACHE_VAL(lt_cv_prog_cc_pic,
# Is there a better lt_cv_prog_cc_static that works with the bundled CC?
lt_cv_prog_cc_wl='-Wl,'
lt_cv_prog_cc_static=${lt_cv_prog_cc_wl}-a ${lt_cv_prog_cc_wl}archive
- lt_cv_prog_cc_pic='+Z'
+ case $host_cpu in
+ hppa*64*|ia64*)
+ # +Z the default
+ ;;
+ *)
+ lt_cv_prog_cc_pic='+Z'
+ ;;
+ esac
;;
irix5* | irix6* | nonstopux*)
@@ -1627,23 +1634,41 @@ else
hpux9* | hpux10* | hpux11*)
case $host_os in
hpux9*) archive_cmds='$rm $output_objdir/$soname~$LD -b +b $install_libdir -o
$output_objdir/$soname $libobjs $deplibs $linker_flags~test $output_objdir/$soname =
$lib || mv $output_objdir/$soname $lib' ;;
-*) archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs
$linker_flags' ;;
+*)
+ case $host_cpu in
+ hppa*64*|ia64*)
+ archive_cmds='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+ ;;
+ *)
+ archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs
+$linker_flags'
+ ;;
+ esac
+ ;;
+esac
+case $host_cpu in
+hppa*64*|ia64*)
+ hardcode_direct=no
+ hardcode_into_libs=yes
+ ;;
+*)
+ hardcode_direct=yes
+ export_dynamic_flag_spec='${wl}-E'
+ ;;
esac
hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
hardcode_libdir_separator=:
-hardcode_direct=yes
hardcode_minus_L=yes # Not in the search PATH, but as the default
-# location of the library.
-export_dynamic_flag_spec='${wl}-E'
+# location of the library
;;
irix5* | irix6* | nonstopux*)
if test $GCC = yes; then
archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname
${wl}$soname `test -n $verstring echo ${wl}-set_version ${wl}$verstring`
${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
+ hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
else
archive_cmds='$LD -shared $libobjs $deplibs $linker_flags -soname $soname `test
-n $verstring echo -set_version $verstring` -update_registry
${output_objdir}/so_locations -o $lib'
+ hardcode_libdir_flag_spec='-rpath $libdir'
fi
-hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
hardcode_libdir_separator=:
link_all_deplibs=yes
;;
@@ -2122,12 +2148,21 @@ hpux9* | hpux10* | hpux11*)
version_type=sunos
need_lib_prefix=no
need_version=no
- shlibpath_var=SHLIB_PATH
- shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
library_names_spec='${libname}${release}.sl$versuffix ${libname}${release}.sl$major
$libname.sl'
soname_spec='${libname}${release}.sl$major'
# HP-UX runs *really* slowly unless shared libraries are mode 555.
postinstall_cmds='chmod 555 $lib'
+ case $host_cpu
Re: hppa*64* and dependent libraries
On Thu, Dec 19, 2002 at 03:13:13PM -0500, John David Anglin wrote:
I agree that we should use +b to embed the path. Is everyone else in
agreement?
What about the alternative -L and -l approach which ia64 uses and
I adopted in my original patch? I tried to stay away from using +b.
Maybe I am missing something but the package which I have built seem
to have a reasonable embedded path. For example,
I integrated your -L patch and get the following with libpng-1.2.4:
...
/bin/sh ./libtool --mode=link cc +DD64 +O2 +ESlit +Onofltacc
+Oentrysched +Odataprefetch +Onolimit
-L/opt/TWWfsw/zlib11/lib/pa20_64 -o libpng.la -rpath
/opt/TWWfsw/libpng12/lib/pa20_64 -version-info 2:2:0 -module png.lo
pngerror.lo pngget.lo pngmem.lo pngpread.lo pngrio.lo pngread.lo
pngrtran.lo pngrutil.lo pngset.lo pngtrans.lo pngwio.lo pngwrite.lo
pngwtran.lo pngwutil.lo -lz -lm
rm -fr .libs/libpng.la .libs/libpng.* .libs/libpng.*
/usr/ccs/bin/ld -b +h libpng.sl.2 -o .libs/libpng.sl.2.2 png.o
pngerror.o pngget.o pngmem.o pngpread.o pngrio.o pngread.o pngrtran.o
pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o
pngwutil.o -L/opt/TWWfsw/zlib11/lib/pa20_64
-L/opt/TWWfsw/zlib11/lib/pa20_64 -L/opt/TWWfsw/zlib11/lib/pa20_64
/opt/TWWfsw/zlib11/lib/pa20_64/libz.sl -lm -lc
(cd .libs rm -f libpng.sl.2 ln -s libpng.sl.2.2 libpng.sl.2)
(cd .libs rm -f libpng.sl ln -s libpng.sl.2.2 libpng.sl)
ar cru .libs/libpng.a png.o pngerror.o pngget.o pngmem.o pngpread.o
pngrio.o pngread.o pngrtran.o pngrutil.o pngset.o pngtrans.o pngwio.o
pngwrite.o pngwtran.o pngwutil.o
...
$ elfdump -L .libs/libnpg.sl | grep Rpath
4 Rpath
/opt/TWWfsw/zlib11/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64
Ick!
What I really like about +b is that it makes it explicit. The big
advantage of -L is that it is additive whereas +b is not (i.e. +b /a
+b /b = +b /b, where you want /a:/b). However, libtool will add in
the necessary `:' but if someone has LDFLAGS=-Wl,+b,/path, then
/path won't be in the colon-separated path built by libtool.
Below is the patch against 1.4 with your -L addition.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.166.2.45
diff -u -3 -p -r1.166.2.45 libtool.m4
--- libtool.m4 11 Oct 2002 16:06:07 - 1.166.2.45
+++ libtool.m4 19 Dec 2002 22:50:39 -
@@ -910,7 +910,14 @@ AC_CACHE_VAL(lt_cv_prog_cc_pic,
# Is there a better lt_cv_prog_cc_static that works with the bundled CC?
lt_cv_prog_cc_wl='-Wl,'
lt_cv_prog_cc_static=${lt_cv_prog_cc_wl}-a ${lt_cv_prog_cc_wl}archive
- lt_cv_prog_cc_pic='+Z'
+ case $host_cpu in
+ hppa*64*|ia64*)
+ # +Z the default
+ ;;
+ *)
+ lt_cv_prog_cc_pic='+Z'
+ ;;
+ esac
;;
irix5* | irix6* | nonstopux*)
@@ -1627,23 +1634,43 @@ else
hpux9* | hpux10* | hpux11*)
case $host_os in
hpux9*) archive_cmds='$rm $output_objdir/$soname~$LD -b +b $install_libdir -o
$output_objdir/$soname $libobjs $deplibs $linker_flags~test $output_objdir/$soname =
$lib || mv $output_objdir/$soname $lib' ;;
-*) archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs
$linker_flags' ;;
+*)
+ case $host_cpu in
+ hppa*64*|ia64*)
+ archive_cmds='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+ ;;
+ *)
+ archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs
+$linker_flags'
+ ;;
+ esac
+ ;;
+esac
+case $host_cpu in
+hppa*64*|ia64*)
+ hardcode_direct=no
+ hardcode_shlibpath_var=no
+ hardcode_into_libs=yes
+ hardcode_libdir_flag_spec='-L$libdir'
+ ;;
+*)
+ export_dynamic_flag_spec='${wl}-E'
+ hardcode_direct=yes
+ hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
+ hardcode_libdir_separator=:
+ hardcode_minus_L=yes # Not in the search PATH, but as the default
+ # location of the library
+ ;;
esac
-hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
-hardcode_libdir_separator=:
-hardcode_direct=yes
-hardcode_minus_L=yes # Not in the search PATH, but as the default
-# location of the library.
-export_dynamic_flag_spec='${wl}-E'
;;
irix5* | irix6* | nonstopux*)
if test $GCC = yes; then
archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname
${wl}$soname `test -n $verstring echo ${wl}-set_version ${wl}$verstring`
${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
+ hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
else
archive_cmds='$LD -shared $libobjs $deplibs $linker_flags -soname $soname `test
-n $verstring echo -set_version $verstring` -update_registry
${output_objdir}/so_locations -o $lib
hppa64* for 1.4 branch
Yes, I know the 1.4 branch is deprecated.
Because this patch is based on one submitted by Ross Alexander, it
cannot be committed until a copyright assignment form by Ross has been
accepted by the FSF.
2002-12-20 Albert Chin-A-Young ([EMAIL PROTECTED])
* libtool.m4, ltmain.in: Add support for hppa*64* based on
a patch by Ross Alexander [EMAIL PROTECTED].
Credit to Ross! Use +b to hardcode library runtime path.
Add new variable, $hardcode_libdir_flag_spec_ld, that
is equivalent to $hardcode_libdir_flag_spec but is used
when ld is used for linking. This works around having to
set wl=''.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.166.2.49
diff -u -3 -p -r1.166.2.49 libtool.m4
--- libtool.m4 23 Oct 2002 00:55:33 - 1.166.2.49
+++ libtool.m4 20 Dec 2002 16:16:20 -
@@ -910,7 +910,14 @@ AC_CACHE_VAL(lt_cv_prog_cc_pic,
# Is there a better lt_cv_prog_cc_static that works with the bundled CC?
lt_cv_prog_cc_wl='-Wl,'
lt_cv_prog_cc_static=${lt_cv_prog_cc_wl}-a ${lt_cv_prog_cc_wl}archive
- lt_cv_prog_cc_pic='+Z'
+ case $host_cpu in
+ hppa*64*)
+ # +Z the default
+ ;;
+ *)
+ lt_cv_prog_cc_pic='+Z'
+ ;;
+ esac
;;
irix5* | irix6* | nonstopux*)
@@ -1627,14 +1634,34 @@ else
hpux9* | hpux10* | hpux11*)
case $host_os in
hpux9*) archive_cmds='$rm $output_objdir/$soname~$LD -b +b $install_libdir -o
$output_objdir/$soname $libobjs $deplibs $linker_flags~test $output_objdir/$soname =
$lib || mv $output_objdir/$soname $lib' ;;
-*) archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs
$linker_flags' ;;
+*)
+ case $host_cpu in
+ hppa*64*)
+ archive_cmds='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+ ;;
+ *)
+ archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs
+$linker_flags'
+ ;;
+ esac
+ ;;
+esac
+case $host_cpu in
+hppa*64*)
+ hardcode_direct=no
+ hardcode_into_libs=yes
+ hardcode_libdir_flag_spec_ld='+b $libdir'
+ hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
+ hardcode_shlibpath_var=no
+ ;;
+*)
+ export_dynamic_flag_spec='${wl}-E'
+ hardcode_direct=yes
+ hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
+ hardcode_minus_L=yes # Not in the search PATH, but as the default
+ # location of the library
+ ;;
esac
-hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
hardcode_libdir_separator=:
-hardcode_direct=yes
-hardcode_minus_L=yes # Not in the search PATH, but as the default
-# location of the library.
-export_dynamic_flag_spec='${wl}-E'
;;
irix5* | irix6* | nonstopux*)
@@ -2127,12 +2154,21 @@ hpux9* | hpux10* | hpux11*)
version_type=sunos
need_lib_prefix=no
need_version=no
- shlibpath_var=SHLIB_PATH
- shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
library_names_spec='${libname}${release}.sl$versuffix ${libname}${release}.sl$major
$libname.sl'
soname_spec='${libname}${release}.sl$major'
# HP-UX runs *really* slowly unless shared libraries are mode 555.
postinstall_cmds='chmod 555 $lib'
+ case $host_cpu in
+ hppa*64*)
+shlibpath_var=LD_LIBRARY_PATH
+shlibpath_overrides_runpath=yes
+sys_lib_search_path_spec=/usr/lib/pa20_64 /usr/ccs/lib/pa20_64
+sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
+;;
+ *)
+shlibpath_var=SHLIB_PATH
+shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
+ esac
;;
irix5* | irix6* | nonstopux*)
@@ -2489,8 +2526,8 @@ if test -f $ltmain; then
old_striplib striplib file_magic_cmd export_symbols_cmds \
deplibs_check_method allow_undefined_flag no_undefined_flag \
finish_cmds finish_eval global_symbol_pipe global_symbol_to_cdecl \
-global_symbol_to_c_name_address \
-hardcode_libdir_flag_spec hardcode_libdir_separator \
+global_symbol_to_c_name_address hardcode_libdir_flag_spec \
+hardcode_libdir_flag_spec_ld hardcode_libdir_separator \
sys_lib_search_path_spec sys_lib_dlsearch_path_spec \
compiler_c_o compiler_o_lo need_locks exclude_expsyms include_expsyms; do
@@ -2752,6 +2789,11 @@ hardcode_into_libs=$hardcode_into_libs
# This must work even if \$libdir does not exist.
hardcode_libdir_flag_spec=$lt_hardcode_libdir_flag_spec
+# If ld is used when linking, flag to hardcode \$libdir into
+# a binary during linking. This must work even if \$libdir does
+# not exist.
+hardcode_libdir_flag_spec_ld=$lt_hardcode_libdir_flag_spec_ld
+
# Whether we need a single -rpath flag with a separated argument.
hardcode_libdir_separator=$lt_hardcode_libdir_separator
Re: Unrequested F77 config
On Sun, Dec 22, 2002 at 10:07:32AM -0600, Bob Friesenhahn wrote: There are certainly a bug in that even if no fortran compiler is found, libtool proceeds to configure the F77 tag. Much of this configuration is done with CC unset, causing various warnings. Libtool should provide a way for the user to specify which tags are to be configured. This would allow a project which includes its own libtool, but uses a subset of the supported languages to avoid configuring libtool for languages which are not used. We could augment AC_PROG_LIBTOOL to take a list of tags: AC_PROG_LIBTOOL([tag1,tag2,...]) Anyone want to submit a patch :) -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: icc support
On Mon, Dec 23, 2002 at 09:11:54PM +0100, Sven Hartrumpf wrote: I have seen icc support mentioned on the mailing list. In which libtool versions is it available? I think the HEAD branch (1.5). -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool incompatible with current autoconf
On Mon, Dec 23, 2002 at 04:12:46PM -0800, Dan Kegel wrote: I discovered to my chagrin that I cannot update kaffe from autoconf2.13 to autoconf2.53. Just update configure in the libltdl directory. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libltdl segfaults on lt_dlsym
On Mon, Dec 30, 2002 at 04:42:50PM +1100, Conrad Canterford wrote: This is almost certainly a user error, not a libltdl error, but I cannot work out how to make this work. I have a .so file which contains my user interface. The main program finds the path to it and the names of varioius subroutines within it from within its config file. It does an lt_dlinit(), and then an lt_dlopen(char */path/to/library). This works fine, and I can see the handle returned. However, I next try and do an lt_dlsym(handle, char *symname), and it segfaults each and every time. Is there some step I'm missing, or something else I'm likely to have forgotten to do that is required? What version of libtool? I think 1.4.3 had some ltdl patches. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: gettext libintl.la dependency_libs problem
On Thu, Jan 02, 2003 at 10:26:28PM -0600, Tim Mooney wrote: In regard to: Re: gettext libintl.la dependency_libs problem, Albert Chin...: On Thu, Jan 02, 2003 at 07:07:42PM -0600, Albert Chin wrote: On Thu, Jan 02, 2003 at 06:30:58PM -0600, Tim Mooney wrote: ... Now say you build some package (for me it was glib-2.2.0) that depends on gettext. When you go to link the package on a platform like Tru64 or IRIX, the link will fail because libtool passes the `-R/usr/local/gnu/lib' to whatever is doing the linking on the platform in question (ld generally). Many vendor compilers and linkers don't understand `-R', so the link bombs. Show the command-line doing this. With versioning this gets pretty long, hopefully it comes through OK: ... According to the libtool info file: `-R LIBDIR' If OUTPUT-FILE is a program, add LIBDIR to its run-time path. If OUTPUT-FILE is a library, add -RLIBDIR to its DEPENDENCY_LIBS, so that, whenever the library is linked into a program, LIBDIR will be added to its run-time path. So, I guess it's a bug in libtool. Is the patch below correct? We can throw away -R in $deplibs because we already added it to $xrpath when we scanned $dependency_libs. I haven't tested the patch mutch. -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/ltmain.in,v retrieving revision 1.259.2.26 diff -u -3 -p -r1.259.2.26 ltmain.in --- ltmain.in 11 Oct 2002 16:06:07 - 1.259.2.26 +++ ltmain.in 3 Jan 2003 08:21:16 - @@ -2084,6 +2084,7 @@ compiler. for deplib in $tmp_libs; do case $deplib in -L*) new_libs=$deplib $new_libs ;; + -R*) ;; *) case $specialdeplibs in * $deplib *) new_libs=$deplib $new_libs ;; ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Exceptions in shared lib with icc on Linux
On Mon, Jan 06, 2003 at 05:29:04PM +0100, Martin Frydl wrote: I've found problem when throwing exception from shared library when compiled with icc on Linux. I've attached a test case. The source of this problem is probably linking against c library. Libtool uses this command line: icpc -shared -nostdlib .libs/sub1.o -lc -Qoption,ld,-soname \ -Qoption,ld,libshr.so.0 -o .libs/libshr.so.0.0.0 When I remove -nostdlib and -lc from command line, exe runs without problems. What if you remove only -lc? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How can I link with libguile?
On Sun, Jan 12, 2003 at 04:24:02PM -0800, Bruce Korb wrote: ``libguile'' lives in a place where LD_LIBRARY_PATH must be set (viz., /opt/sfw/lib). What is wrong? What should I be doing to tell libtool that it has to add a ``-R/opt/sfw/lib'' or something? If I use ``guile-config'' first, I'll override ``--with-libguile''. So much pain. :-( We solve this by building like so: $ LDFLAGS=-R[path to guile library] ./configure And, in the specific case of guile, we modify guile-config to output -L[path to guile libraries] *and* -R[path to guile libraries]. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How can I link with libguile?
On Mon, Jan 13, 2003 at 10:16:04AM -0800, Bruce Korb wrote: Albert Chin wrote: On Sun, Jan 12, 2003 at 04:24:02PM -0800, Bruce Korb wrote in http://mail.gnu.org/archive/html/libtool/2003-01/msg00035.html : ``libguile'' lives in a place where LD_LIBRARY_PATH must be set (viz., /opt/sfw/lib). What is wrong? What should I be doing to tell libtool that it has to add a ``-R/opt/sfw/lib'' or something? If I use ``guile-config'' first, I'll override ``--with-libguile''. So much pain. :-( We solve this by building like so: $ LDFLAGS=-R[path to guile library] ./configure And, in the specific case of guile, we modify guile-config to output -L[path to guile libraries] *and* -R[path to guile libraries]. :-( Several problems: 1. There seems to be something funny about the way links work on the Source Forge compile farm. The linker (invoked as gcc) knows where to find free software libraries (/opt/fsw/lib), but it doesn't pass this knowledge along to the run time loader. Is this expected behavior, or a Source Forge issue? Should my link test be changed to a run test? Doing that would trigger the invocation of guile-config. In any event, on the compile farm, my test believes that it can compile and link without anything more special than ``-lguile'' on the link line (no -I either). Run with gcc -v and see what's happening. If during the build of autogen you must run a program which depends on libguile, change your link to a test. 2. On Solaris, libtool ought to take -L args and duplicate them as -R args, yes? Or, is that too simple? *ICK* *ICK* *ICK*! 3. As the author of a *-config script, how would I know when to add the -R thingey? Would libtool strip it if it weren't needed on a particular platform? Do you (Albert) add the -R/path/to/libopts on my script, too? Is there a configure test to check for the need of adding -R? I add -R/path/to/libopts for *every* *-config script (ditto for pkgconfig scripts). Testing for -R won't help you on Tru64 UNIX, IRIX, Redhat Linux, AIX, etc. Libtool does accept -R/path/to/lib and will convert -R to the proper switch for the platform in question. However, this doesn't help during ./configure. P.S.: Dan Kegel asked: Is guile-config reliably installed for versions of guile later than some number X? Answer: No. It is a special issue with Red Hat. They set the prefix to /usr so that no special configury is required, so nobody needs to consult guile-config. That means that just because you cannot find guile-config it doesn't mean that Guile has not been installed. SO: step 1, let someone tell you where to find it. Failing that, step 2, try to use it anyway. If *that* fails, then, finally, go find guile-config. Maybe I should switch steps 2 and 3, but it led to such a complicated shell script/autoconf macroRed Hat should distribute the script. I think you should do the following: 1. Try to link and run against -lguile. 2. Look for guile-config and repeat #1. 3. Fail with a decent AC_ERROR. At the same time, I'd add the following autoconf options: --with-guile-config=[path to guile-config] --with-guile=[base path of guile installation] --with-guile-includes=[path to guile includes] --with-guile-libraries=[path to guile libraries] --with-guile would: CPPFLAGS=$CPPFLAGS -I$withval/include LDFLAGS=$LDFLAGS -L$withval/lib --with-guile-includes would: CPPFLAGS=$CPPFLAGS -I$withval/include --with-guile-libraries would: LDFLAGS=$LDFLAGS -L$withval/lib --with-guile is of course optional if you choose --with-guile-includes and --with-guile-libraries. BTW, this is OT for libtool. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran)
On Wed, Jan 15, 2003 at 02:22:15PM -0500, Boehne, Robert wrote: I will look into this, but FYI, -DPIC should not be passed when compiling Fortran. Why should -DPIC be passed at all for any compiler? Thanks, Robert -Original Message- From: Steve Edwards [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 1:03 PM To: [EMAIL PROTECTED] Subject: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) I have just run into problems trying to use libtool on a rs6000-ibm-aix4.3.2.0 system to build a library written in Fortran with the IBM compiler xlf/xlf90. There is an immediate compilation failure stating: xlf90: 1501-210 command option P contains an incorrect subargument libtool appears to insist on adding -DPIC to the compile command which is being interpreted very differently by the IBM compiler than g77 would treat it. I've searched the mail archives and found two references to this 'feature' but haven't come across any messages suggesting a method for curing it. As this is on rs6000 architecture, I got around the problem by modifying the libtool script to remove the addition of -DPIC but have no idea if this breaks something vitally important (it appeared to work okay). Steve -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC
On Wed, Jan 15, 2003 at 05:23:33PM -0500, Boehne, Robert wrote: Good point, we never really resolved this issue. All in favor of dropping -DPIC entirely say I! WE :) Robert -Original Message- From: Albert Chin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 4:11 PM To: [EMAIL PROTECTED] Subject: Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) On Wed, Jan 15, 2003 at 02:22:15PM -0500, Boehne, Robert wrote: I will look into this, but FYI, -DPIC should not be passed when compiling Fortran. Why should -DPIC be passed at all for any compiler? Thanks, Robert -Original Message- From: Steve Edwards [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 1:03 PM To: [EMAIL PROTECTED] Subject: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) I have just run into problems trying to use libtool on a rs6000-ibm-aix4.3.2.0 system to build a library written in Fortran with the IBM compiler xlf/xlf90. There is an immediate compilation failure stating: xlf90: 1501-210 command option P contains an incorrect subargument libtool appears to insist on adding -DPIC to the compile command which is being interpreted very differently by the IBM compiler than g77 would treat it. I've searched the mail archives and found two references to this 'feature' but haven't come across any messages suggesting a method for curing it. As this is on rs6000 architecture, I got around the problem by modifying the libtool script to remove the addition of -DPIC but have no idea if this breaks something vitally important (it appeared to work okay). Steve -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
AC_LIBTOOL_PROG_LD_SHLIBS overrides defaults
Why does AC_LIBTOOL_PROG_LD_SHLIBS override defaults set in the tag-specific configuration? I'm talking about: runpath_var= _LT_AC_TAGVAR(allow_undefined_flag, $1)= _LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1)=no _LT_AC_TAGVAR(archive_cmds, $1)= ... If I set a default in AC_LIBTOOL_LANG_GCJ_CONFIG, the above code will just override it. How about we change all of the above to: runpath_var= if test x$_LT_AC_TAGVAR(allow_undefined_flag, $1) = x; then _LT_AC_TAGVAR(allow_undefined_flag, $1)= fi ... Or, if a variable is unset, we don't give it a blank value and only test for variables we change, like: if test x$_LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1) != x; then _LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1)=no fi -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Problems in cvs-version of libtool.
On Mon, Jan 20, 2003 at 05:39:50PM +0100, Erik Assum wrote: * Albert Chin | On Mon, Jan 20, 2003 at 03:27:25PM +0100, Erik Assum wrote: | ld: fatal: symbol `bool Tango::operator==(const Tango::BlackBoxElt,const Tango::BlackBoxElt)' is multiply-defined: | (file .libs/tangoSK.o and file .libs/tangoDynSK.o); | ld: fatal: symbol `bool Tango::operator(const Tango::BlackBoxElt,const Tango::BlackBoxElt)' is multiply-defined: | (file .libs/tangoSK.o and file .libs/tangoDynSK.o); | | Anyone familiar with this? | | This isn't a libtool problem. Tell the omniorb people. How is this, since it worked with an earlier version of libtool? So the *only* difference is the version of libtool? If so, do you have both? If you do, then recompile and mail a diff of the last libtool compile command (and the lines that follow it). -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC
On Tue, Jan 21, 2003 at 09:13:54AM +1000, Kevin Ryde wrote: Robert Boehne [EMAIL PROTECTED] writes: All good ideas, and I don't really have a preference for any of them. If you do, let me know or I'll just pick the one that looks easiest. I'd think an autoconf macro would be ok, to be used for instance AC_LIBTOOL_PICDEF([-DPIC]) AC_PROG_LIBTOOL which I guess would just insert its argument into $pic_flag. Is setting a custom -DPIC really necessary? How about we just leave the existing -DPIC for the C and C++ tags? I don't see anything to gain by choosing a new default or allowing it to be set. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: flat namespaces redux
On Mon, Feb 03, 2003 at 11:59:03PM -0600, Robert Boehne wrote: Maybe I don't understand OS X, but as I see it, any library that needs a two level namespace would not build on any other OS because OS X is the only OS that supports this feature. Now, if that is the case, it doesn't make any sense for Libtool (a tool for portable library creation use) to support a feature that is only present on a single platform. Does that make sense? I think we should support the two-level namespace, even if it is OSX-specific. I look at libtool more as a way to easily build shared libraries across multiple platforms. Think about AIX. An AIX shared library (non-brtl) can contain *both* a static and shared member. We don't emulate this across all platforms. And, how about this warning in ltmain.in (a non-portable feature): echo *** Warning: Linking the shared library $output against the echo *** static library $deplib is not portable! deplibs=$deplib $deplibs -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: To sed or not to sed
On Tue, Feb 04, 2003 at 04:04:29PM +, Lars Hecking wrote: On Solaris 7/8, this list of objects is too long for the native sed, and linking fails (some error messages about line too long). I reported this as a bug and was told to use GNU sed instead. Fixed in libtool 1.4.3. Libtool now searches for the best sed in $PATH on your system. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: flat namespaces redux
On Tue, Feb 04, 2003 at 09:56:47PM -0600, Robert Boehne wrote: [snip snip] For this feature to really be useful a library would have to be a) Initially developed on OS/X b) dependent on two level namespace c) not really useful on any other plaform (no reason to fix for a flat namespace) I don't think there are too many libraries that would fit this criteria, but please, correct me if I'm wrong. In short, I'm not dead set against the idea, I just don't see the point. I have no clue when it comes to OSX. However, the only reason I support this is the impression I get that two-level namespaces are good for OSX. Is this true? Does Apple *recommend* flat or two-level namespaces? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Pending release of 1.5
On Tue, Feb 04, 2003 at 01:10:54AM -0600, Robert Boehne wrote: I'm just about to make the release of Libtool 1.5. If anyone would like to test the current CVS on their favorite platform and report any problems, please do so! If not, your woes may have to wait for 1.5.1. What date do you plan to release? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How to tell libtool to have/work with one of [.lo|.o] file ( ifpossible )
On Wed, Feb 05, 2003 at 02:11:39PM -0800, Asim Suter wrote: I see that libtool compiles every C source file two times 1) once to generate .lo files 2) second time to generate .o files Is it possible to tell libtool to generate only one type of object file ? My belief is that only one type of file should be sufficient. The main motivation is to reduce the build time approximately by a factor of 2 which would be a tremendous help for us. --disable-shared or --disable-static. If you want static and shared, you don't have a choice. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AC_CHECK_LIB(m, main, LIBM=-lm) broken with C++
On Wed, Feb 05, 2003 at 03:00:39PM -0600, Bob Friesenhahn wrote: I posted a detailed message to [EMAIL PROTECTED] and [EMAIL PROTECTED] but there has been no response at all so I will post again. CVS libtool.m4 contains lines like AC_CHECK_LIB(m, main, LIBM=-lm) and AC_CHECK_LIB(ltdl, main, ... blah Gross! What is the best path forward? Replace main with a *real* function in one of the libraries. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Upgrading a project to libtool and maintaining old library version
A project wishes to upgrade to use libtool to build shared libraries but maintain compatibility with the old library versioning scheme. Is -version-info and -release *it* for how to tell libtool to handle library versions? Old (on Redhat Linux): libfontconfig.so - libfontconfig.so.1 libfontconfig.so.1 - libfontconfig.so.1.0 libfontconfig.so.1.0 SONAME: libfontconfig.so.1 Can I duplicate this with a libtool-generated libfontconfig shared library? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
64-bit object files on AIX
The AIX ar/nm commands, by default, don't work with 64-bit object files. They need the -X64 option added. What's the best way to add this to libtool? I don't see a quick override for either $AR or $NM. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Problems checking out branch-1-5
I have CVS 1.11.5: $ cvs -d:pserver:[EMAIL PROTECTED]:/var/cvs login $ cvs -d:pserver:[EMAIL PROTECTED]:/var/cvs co -rbranch-1-5 libtool cvs [server aborted]: received abort signal -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Sun C++ shared library creation failing
On Solaris 9/SPARC with: $ CC -v CC: Forte Developer 7 C++ 5.4 Patch 111715-06 2003/03/29 ... PASS: tagdemo-conf.test FAIL: tagdemo-make.test SKIP: tagdemo-exec.test PASS: tagdemo-shared.test FAIL: tagdemo-make.test SKIP: tagdemo-exec.test ... Here's a copy of the error: $ sh tagdemo-make.test ... CC -G -zdefs -nolib -hlibbaz.so.0 -o .libs/libbaz.so.0.0.0 .libs/baz.o -Qoption ld -z -Qoption ld allextract ./.libs/libfoo.a -Qoption ld -z -Qoption ld defaultextract -lm Undefined first referenced symbol in file std::basic_ostreamchar,std::char_traitschar std::operator(std::basic_ostreamchar,std::char_traitschar ,const char*) ./.libs/libfoo.a(foo.o) ... We create a C++ shared library with -nolib which doesn't link in -lCstd, hence the error above. How do we fix? If -nolib isn't used CC adds the following libraries by default: -lCstd -lCrun -lm -lw -lcx -lc Is it really wise to use -nolib? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Sun C++ shared library creation failing
On Sun, Jun 01, 2003 at 03:47:42PM -0500, Albert Chin wrote: On Solaris 9/SPARC with: $ CC -v CC: Forte Developer 7 C++ 5.4 Patch 111715-06 2003/03/29 ... PASS: tagdemo-conf.test FAIL: tagdemo-make.test SKIP: tagdemo-exec.test PASS: tagdemo-shared.test FAIL: tagdemo-make.test SKIP: tagdemo-exec.test ... Here's a copy of the error: $ sh tagdemo-make.test ... CC -G -zdefs -nolib -hlibbaz.so.0 -o .libs/libbaz.so.0.0.0 .libs/baz.o -Qoption ld -z -Qoption ld allextract ./.libs/libfoo.a -Qoption ld -z -Qoption ld defaultextract -lm Undefined first referenced symbol in file std::basic_ostreamchar,std::char_traitschar std::operator(std::basic_ostreamchar,std::char_traitschar ,const char*) ./.libs/libfoo.a(foo.o) ... We create a C++ shared library with -nolib which doesn't link in -lCstd, hence the error above. How do we fix? If -nolib isn't used CC adds the following libraries by default: -lCstd -lCrun -lm -lw -lcx -lc Is it really wise to use -nolib? Ok, I've dug some more. If we want -zdefs and -nolib, we must add -lCstd (Sun CC 6.0, 7). From libtool.m4: # There doesn't appear to be a way to prevent this compiler from # explicitly linking system object files so we need to strip them # from the output so that they don't get included in the library # dependencies. output_verbose_link_cmd='templist=`$CC -G $CFLAGS -v conftest.$objext 21 | grep \-[[LR]]`; list=; for z in $templist; do case $z in conftest.$objext) list=$list $z;; *.$objext);; *) list=$list $z;;esac; done; echo $list' I'm not seeing this though. CC -G with Sun CC 5.0, 6.0, and 7 don't add any libraries automatically. GCC seems to add -lstdc++ regardless so postdeps gets the -lstdc++ and gets the above test right. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
1.5 automatically generating C++, F77 tags
It's really annoying to have 1.5 automatically generate the C++ and F77 tags. I'm trying to figure out why it does this. We have the following in libtool.m4: dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX. AC_PROVIDE_IFELSE([AC_PROG_CXX], [AC_LIBTOOL_CXX], [define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX ])]) Is this suppose to generate the C++ tag *only* if AC_PROG_CXX is called? If not, what does it mean because the C++ tag is *always* being created? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Mon, Jun 02, 2003 at 05:06:42PM -0500, Bob Friesenhahn wrote: On Mon, 2 Jun 2003, Albert Chin wrote: It's really annoying to have 1.5 automatically generate the C++ and F77 tags. I'm trying to figure out why it does this. We have the following in libtool.m4: dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX. AC_PROVIDE_IFELSE([AC_PROG_CXX], [AC_LIBTOOL_CXX], [define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX ])]) Is this suppose to generate the C++ tag *only* if AC_PROG_CXX is called? If not, what does it mean because the C++ tag is *always* being created? It looks to me like it is simply trying to ensure a proper execution order of AC_PROG_CXX vs AC_LIBTOOL_CXX. AC_LIBTOOL_CXX is run after AC_PROG_CXX and can be run immediately if AC_PROG_CXX has already been run. The default for libtool is to attempt to configure all tags. This is reasonable for a stand-alone libtool, but is not very reasonable for an embedded libtool. That is why we still need the macro you proposed which allows the user to tell libtool which language tags to configure. Package configure scripts would then need to incoporate the macro in order to limit the tags which get configured. I'm trying to do it automatically. I want to run AC_LIBTOOL_CXX *only* if AC_PROG_CXX is called. Can autoconf do this? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Tue, Jun 03, 2003 at 01:08:17AM +0200, Alexandre Duret-Lutz wrote: Albert == Albert Chin [EMAIL PROTECTED] writes: Albert On Mon, Jun 02, 2003 at 05:06:42PM -0500, Bob Friesenhahn wrote: On Mon, 2 Jun 2003, Albert Chin wrote: It's really annoying to have 1.5 automatically generate the C++ and F77 tags. I'm trying to figure out why it does this. We have the following in libtool.m4: dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX. AC_PROVIDE_IFELSE([AC_PROG_CXX], [AC_LIBTOOL_CXX], [define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX ])]) [...] Albert I'm trying to do it automatically. I want to run AC_LIBTOOL_CXX *only* Albert if AC_PROG_CXX is called. Can autoconf do this? Automake setups its dependency tracking code for various languages with code similar to the above. Actually, the above would work if Libtool was not running expanding AC_PROG_CXX itself! (This happens when AC_LIBTOOL_LANG_CXX_CONFIG is expanded in _LT_AC_TAGCONFIG.) As I see it, the only way to achieve what you want would be to rewrite the `case $tagname' switch from _LT_AC_TAGCONFIG in plain M4 (instead of shell). This way you can ensure that AC_LIBTOOL_LANG_CXX_CONFIG is expanded only if AC_PROG_CXX has been called first. Likewise for other languages. However I don't think you can do this and still allow AC_PROC_CXX to be called after AC_PROG_LIBTOOL. I don't have a problem requiring AC_PROG_CXX, AC_PROG_F77, or AM_PROG_GCJ before AC_PROG_LIBTOOL. Anyone see this as a problem? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Tue, Jun 03, 2003 at 08:56:38AM -0500, Bob Friesenhahn wrote:
On Tue, 3 Jun 2003, Alexandre Duret-Lutz wrote:
Albert == Albert Chin [EMAIL PROTECTED] writes:
[...]
Albert I don't have a problem requiring AC_PROG_CXX, AC_PROG_F77, or
Albert AM_PROG_GCJ before AC_PROG_LIBTOOL. Anyone see this as a problem?
As a user I wouldn't care about this little inconvenience if it
allows Libtool not to bloat my configure with useless checks.
However, requiring this will break thousands of configure.ac. I
expect most of them to run AC_INIT, AM_INIT_AUTOMAKE,
AC_PROG_LIBTOOL early, and then go on with other checks such as
language checks.
This is true. It may be very inconvenient for some packages to change
the ordering.
Maybe this could be changed as follows:
It is generally not a good approach to base a design on side-effects
or assumptions. Up to now, adding AC_PROG_LIBTOOL to a configure.ac
file has been sufficient to configure libtool, regardless of whether
libtool is stand-alone or embedded. This behavior should not be
altered.
I believe that a much better solution is to add a AC_LIBTOOL_TAGS (or
AC_LIBTOOL_LANGUAGES) macro which can be used like
AC_LIBTOOL_TAGS([c c++])
AC_PROG_LIBTOOL
[ snip snip ]
Ok, just whipped this up as a proof of concept. Haven't really tested.
Am I headed in the right direction.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
--- libtool.m4.orig 2003-06-01 16:07:41.276467000 -0500
+++ libtool.m4 2003-06-03 10:22:57.667598339 -0500
@@ -39,35 +39,9 @@
# ---
AC_DEFUN([AC_PROG_LIBTOOL],
[AC_REQUIRE([_AC_PROG_LIBTOOL])dnl
-dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX
-dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX.
- AC_PROVIDE_IFELSE([AC_PROG_CXX],
-[AC_LIBTOOL_CXX],
-[define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX
- ])])
-dnl And a similar setup for Fortran 77 support
- AC_PROVIDE_IFELSE([AC_PROG_F77],
-[AC_LIBTOOL_F77],
-[define([AC_PROG_F77], defn([AC_PROG_F77])[AC_LIBTOOL_F77
-])])
-
-dnl Quote A][M_PROG_GCJ so that aclocal doesn't bring it in needlessly.
-dnl If either AC_PROG_GCJ or A][M_PROG_GCJ have already been expanded, run
-dnl AC_LIBTOOL_GCJ immediately, otherwise, hook it in at the end of both.
- AC_PROVIDE_IFELSE([AC_PROG_GCJ],
-[AC_LIBTOOL_GCJ],
-[AC_PROVIDE_IFELSE([A][M_PROG_GCJ],
- [AC_LIBTOOL_GCJ],
- [AC_PROVIDE_IFELSE([LT_AC_PROG_GCJ],
- [AC_LIBTOOL_GCJ],
- [ifdef([AC_PROG_GCJ],
-[define([AC_PROG_GCJ], defn([AC_PROG_GCJ])[AC_LIBTOOL_GCJ])])
- ifdef([A][M_PROG_GCJ],
-[define([A][M_PROG_GCJ], defn([A][M_PROG_GCJ])[AC_LIBTOOL_GCJ])])
- ifdef([LT_AC_PROG_GCJ],
-[define([LT_AC_PROG_GCJ],
- defn([LT_AC_PROG_GCJ])[AC_LIBTOOL_GCJ])])])])
-])])# AC_PROG_LIBTOOL
+AC_PROVIDE_IFELSE([AC_LIBTOOL_TAGS],,
+ [AC_LIBTOOL_TAGS([C C++ F77])])
+]) # AC_PROG_LIBTOOL
# _AC_PROG_LIBTOOL
@@ -1608,15 +1581,26 @@
])# AC_LIBTOOL_SYS_DYNAMIC_LINKER
+# AC_LIBTOOL_TAGS
+# ---
+# tags to enable
+AC_DEFUN([AC_LIBTOOL_TAGS],
+[m4_define([_LT_TAGS],[$1])
+]) # AC_LIBTOOL_TAGS
+
+# _LT_AC_CHECK_TAG
+#
+AC_DEFUN([_LT_AC_CHECK_TAG],
+[if grep ^# ### BEGIN LIBTOOL TAG CONFIG: $1$ ${ofile} /dev/null
+then
+AC_MSG_ERROR([tag name \$1\ already exists])
+fi
+]) # _LT_AC_CHECK_TAG
+
# _LT_AC_TAGCONFIG
#
AC_DEFUN([_LT_AC_TAGCONFIG],
-[AC_ARG_WITH([tags],
-[AC_HELP_STRING([--with-tags@:@=TAGS@:@],
-[include additional configurations @:@automatic@:@])],
-[tagnames=$withval])
-
-if test -f $ltmain test -n $tagnames; then
+[if test -f $ltmain test -n _LT_TAGS; then
if test ! -f ${ofile}; then
AC_MSG_WARN([output file `$ofile' does not exist])
fi
@@ -1634,66 +1618,37 @@
# Note that this assumes the entire list is on one line.
available_tags=`grep ^available_tags= ${ofile} | $SED -e
's/available_tags=\(.*$\)/\1/' -e 's/\//g'`
- lt_save_ifs=$IFS; IFS=${IFS}$PATH_SEPARATOR,
- for tagname in $tagnames; do
-IFS=$lt_save_ifs
-# Check whether tagname contains only valid characters
-case `$echo X$tagname | $Xsed -e
's:[[-_ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890,/]]::g'` in
-) ;;
-*) AC_MSG_ERROR([invalid tag name: $tagname])
- ;;
-esac
-
-if grep ^# ### BEGIN LIBTOOL TAG CONFIG: $tagname$ ${ofile} /dev/null
-then
- AC_MSG_ERROR([tag name \$tagname\ already exists])
-fi
-
-# Update the list of available tags.
-if test -n $tagname; then
- echo appending configuration tag \$tagname\ to $ofile
-
- case $tagname in
- CXX)
- if test -n $CXX test X$CXX != Xno; then
- AC_LIBTOOL_LANG_CXX_CONFIG
- else
- tagname=
- fi
- ;;
-
- F77)
- if test -n $F77 test X$F77 != Xno; then
- AC_LIBTOOL_LANG_F77_CONFIG
- else
- tagname
Re: 1.5 automatically generating C++, F77 tags
On Tue, Jun 03, 2003 at 08:56:38AM -0500, Bob Friesenhahn wrote: On Tue, 3 Jun 2003, Alexandre Duret-Lutz wrote: Albert == Albert Chin [EMAIL PROTECTED] writes: [...] Albert I don't have a problem requiring AC_PROG_CXX, AC_PROG_F77, or Albert AM_PROG_GCJ before AC_PROG_LIBTOOL. Anyone see this as a problem? As a user I wouldn't care about this little inconvenience if it allows Libtool not to bloat my configure with useless checks. However, requiring this will break thousands of configure.ac. I expect most of them to run AC_INIT, AM_INIT_AUTOMAKE, AC_PROG_LIBTOOL early, and then go on with other checks such as language checks. This is true. It may be very inconvenient for some packages to change the ordering. Maybe this could be changed as follows: It is generally not a good approach to base a design on side-effects or assumptions. Up to now, adding AC_PROG_LIBTOOL to a configure.ac file has been sufficient to configure libtool, regardless of whether libtool is stand-alone or embedded. This behavior should not be altered. I believe that a much better solution is to add a AC_LIBTOOL_TAGS (or AC_LIBTOOL_LANGUAGES) macro which can be used like AC_LIBTOOL_TAGS([c c++]) AC_PROG_LIBTOOL This means we'd have to get rid of --with-tags. As it's not documented, I'm for this. If someone specifies AC_LIBTOOL_TAGS, and say C++ isn't specified, I don't want AC_PROG_CXX dragged in. I'll try and code this up. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Tue, Jun 03, 2003 at 10:58:14AM -0500, Bob Friesenhahn wrote: On Tue, 3 Jun 2003, Albert Chin wrote: AC_LIBTOOL_TAGS([c c++]) AC_PROG_LIBTOOL This means we'd have to get rid of --with-tags. As it's not documented, I'm for this. If someone specifies AC_LIBTOOL_TAGS, and say C++ isn't specified, I don't want AC_PROG_CXX dragged in. I am also in favor of either getting rid of --with-tags, or supporting it via a configure.ac macro that the package author needs to add. Currently libtool adds a --with-tags option to the configure script for each package which uses it. This is confusing to package users since there is no context associated with the option: --with-tags[=TAGS] include additional configurations [automatic] An option like --with-libtool-languages[=languages] would be clearer for an end user. However, I would also contend that end-users should have no need to be aware that a package uses libtool. I think --with-libtool-languages and AC_LIBTOOL_TAGS are mutually exclusive. For example: AC_LIBTOOL_TAGS([C]) AC_PROG_LIBTOOL and then --with-libtool-languages=C++ is useless because the C++ glue code won't be in configure. --with-libtool-languages means that every tag has to be present in configure. Ick. Ditch --with-tags! -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
LIBTOOL TAG CONFIG tag header
Why do we create the libtool tag header/footer like so: BEGIN LIBTOOL TAG CONFIG: $tagname END LIBTOOL TAG CONFIG: $tagname Why not use $1: @@ -3911,7 +3953,7 @@ available_tags= # ### BEGIN LIBTOOL CONFIG], -[# ### BEGIN LIBTOOL TAG CONFIG: $tagname]) +[# ### BEGIN LIBTOOL TAG CONFIG: $1]) # Libtool was configured on host `(hostname || uname -n) 2/dev/null | sed 1q`: @@ -4207,7 +4249,7 @@ ifelse([$1],[], [# ### END LIBTOOL CONFIG], -[# ### END LIBTOOL TAG CONFIG: $tagname]) +[# ### END LIBTOOL TAG CONFIG: $1]) __EOF__ -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
On Tue, Jun 03, 2003 at 07:43:52PM +0200, Alexandre Duret-Lutz wrote:
Albert Chin [EMAIL PROTECTED] writes:
[...]
| --- libtool.m4.orig 2003-06-01 16:07:41.276467000 -0500
| +++ libtool.m4 2003-06-03 10:22:57.667598339 -0500
[...]
| +AC_PROVIDE_IFELSE([AC_LIBTOOL_TAGS],,
| + [AC_LIBTOOL_TAGS([C C++ F77])])
Since the tag for C++ is called CXX and there is no tag for C,
it would seem more natural to read
AC_LIBTOOL_TAGS([CXX F77])
I think Bob's suggestion of AC_LIBTOOL_LANGUAGES is better if
you really want to pass language names as arguments.
Ah, ok. I'll ditch C++ and make CXX the tag name.
BTW, should we have a `C' tag and make it a NOOP or should we report
an invalid tag name for it? I hope libtool will eventually have a `C'
tag. The code before reports an error to adhere to current libtool
behavior.
[...]
| + [m4_if(_LT_TAG, C, ,
| + [m4_if(_LT_TAG, C++,
[...]
| + [m4_if(_LT_TAG, F77,
[...]
| + [m4_if(_LT_TAG, GCJ,
[...]
| + [m4_if(_LT_TAG, RC,
[...]
| + m4_errprintn(m4_location[: error: invalid tag name:
]_LT_TAG)
Maybe this can be simplified to something around the lines of
m4_case([_LT_TAG],
[C], ,
[CXX], [...],
[F77], [...],
[GCJ], [...],
[RC], [...],
[m4_fatal([unsupported tag name: ]_LT_TAG)])
Cool. I didn't see this. I've attached the latest version of the
patch. I'd like to hear from Robert before adding docs and submitting
a formal patch.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
--- libtool.m4.orig 2003-06-01 16:07:41.276467000 -0500
+++ libtool.m4 2003-06-03 13:58:38.856989000 -0500
@@ -39,35 +39,7 @@
# ---
AC_DEFUN([AC_PROG_LIBTOOL],
[AC_REQUIRE([_AC_PROG_LIBTOOL])dnl
-dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX
-dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX.
- AC_PROVIDE_IFELSE([AC_PROG_CXX],
-[AC_LIBTOOL_CXX],
-[define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX
- ])])
-dnl And a similar setup for Fortran 77 support
- AC_PROVIDE_IFELSE([AC_PROG_F77],
-[AC_LIBTOOL_F77],
-[define([AC_PROG_F77], defn([AC_PROG_F77])[AC_LIBTOOL_F77
-])])
-
-dnl Quote A][M_PROG_GCJ so that aclocal doesn't bring it in needlessly.
-dnl If either AC_PROG_GCJ or A][M_PROG_GCJ have already been expanded, run
-dnl AC_LIBTOOL_GCJ immediately, otherwise, hook it in at the end of both.
- AC_PROVIDE_IFELSE([AC_PROG_GCJ],
-[AC_LIBTOOL_GCJ],
-[AC_PROVIDE_IFELSE([A][M_PROG_GCJ],
- [AC_LIBTOOL_GCJ],
- [AC_PROVIDE_IFELSE([LT_AC_PROG_GCJ],
- [AC_LIBTOOL_GCJ],
- [ifdef([AC_PROG_GCJ],
-[define([AC_PROG_GCJ], defn([AC_PROG_GCJ])[AC_LIBTOOL_GCJ])])
- ifdef([A][M_PROG_GCJ],
-[define([A][M_PROG_GCJ], defn([A][M_PROG_GCJ])[AC_LIBTOOL_GCJ])])
- ifdef([LT_AC_PROG_GCJ],
-[define([LT_AC_PROG_GCJ],
- defn([LT_AC_PROG_GCJ])[AC_LIBTOOL_GCJ])])])])
-])])# AC_PROG_LIBTOOL
+]) # AC_PROG_LIBTOOL
# _AC_PROG_LIBTOOL
@@ -226,9 +198,8 @@
test -z $pic_mode pic_mode=default
# Use C for the default configuration in the libtool script
-tagname=
AC_LIBTOOL_LANG_C_CONFIG
-_LT_AC_TAGCONFIG
+_LT_AC_TAG_CONFIG
])# AC_LIBTOOL_SETUP
@@ -1608,15 +1579,29 @@
])# AC_LIBTOOL_SYS_DYNAMIC_LINKER
-# _LT_AC_TAGCONFIG
+# AC_LIBTOOL_TAGS
+# ---
+# tags to enable
+AC_DEFUN([AC_LIBTOOL_TAGS],
+[m4_define([_LT_TAGS],[$1])
+]) # AC_LIBTOOL_TAGS
+
+# _LT_AC_TAG_CHECK
#
-AC_DEFUN([_LT_AC_TAGCONFIG],
-[AC_ARG_WITH([tags],
-[AC_HELP_STRING([--with-tags@:@=TAGS@:@],
-[include additional configurations @:@automatic@:@])],
-[tagnames=$withval])
+AC_DEFUN([_LT_AC_TAG_CHECK],
+[m4_ifdef([_LT_TAG_]$1,
+ [m4_errprintn(m4_location[: error: duplicate tag: ]$1)
+ m4_exit(1)],
+ [m4_define([_LT_TAG_]$1, [])])
+]) # _LT_AC_TAG_CHECK
+
+# _LT_AC_TAG_CONFIG
+# -
+AC_DEFUN([_LT_AC_TAG_CONFIG],
+[AC_PROVIDE_IFELSE([AC_LIBTOOL_TAGS],,
+ [AC_LIBTOOL_TAGS([CXX F77 GCJ RC])])
-if test -f $ltmain test -n $tagnames; then
+if test -f $ltmain; then
if test ! -f ${ofile}; then
AC_MSG_WARN([output file `$ofile' does not exist])
fi
@@ -1634,66 +1619,33 @@
# Note that this assumes the entire list is on one line.
available_tags=`grep ^available_tags= ${ofile} | $SED -e
's/available_tags=\(.*$\)/\1/' -e 's/\//g'`
- lt_save_ifs=$IFS; IFS=${IFS}$PATH_SEPARATOR,
- for tagname in $tagnames; do
-IFS=$lt_save_ifs
-# Check whether tagname contains only valid characters
-case `$echo X$tagname | $Xsed -e
's:[[-_ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890,/]]::g'` in
-) ;;
-*) AC_MSG_ERROR([invalid tag name: $tagname])
- ;;
-esac
-
-if grep ^# ### BEGIN LIBTOOL TAG CONFIG: $tagname$ ${ofile} /dev/null
-then
- AC_MSG_ERROR([tag name \$tagname\ already exists
Re: Libtool makes configure scripts check for unneeded compilers
On Tue, Jun 10, 2003 at 02:04:40PM +0200, Peter Eisentraut wrote: [ snip snip ] For some reason this causes libtool(?) to include support for C++ and Fortran in the resulting configure script. For example, I see in 'configure': tagnames=`echo $tagnames,CXX | sed 's/^,//'` tagnames=`echo $tagnames,F77 | sed 's/^,//'` And when I run it it checks for g++ and g77 and runs the whole libtool test range for those compilers. Does anyone know why? Check the thread from last week. I'll try to post my patch by this weekend to fix this. http://mail.gnu.org/archive/html/libtool/2003-06/msg6.html -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Fixing Re: Is libtool being maintained at all?
On Mon, Jul 14, 2003 at 08:25:06PM +0200, Dalibor Topic wrote: The proper way to fix it could be to do a binary search over multiples of 2 instead of the linear search emplyed now. Use a resonable minamal value like 2**13, which leaves only a few options between 2**13 and 2**17, which is the current upper limit for the test. Starting with 2**15, you only need three tests to figure out the maximal command line length, instead of 17. How does that sound? How do you start out with 2^13 printable characters? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Hardcoding library path dependency into library
Say I'm on a platform with:
# Set to yes if using DIR/libNAME.so during linking hardcodes DIR into the
# resulting binary.
hardcode_direct=yes
and I want to create a library with an embedded .so path dependency. I
don't see how this can ever work looking at ltmain.in. If the command
line is something like:
$ libtool --mode=link xlc -o libgimp.la \
-rpath /opt/TWWfsw/gimp12/lib -version-info 0:5:0 -release 1.2 \
gimp.lo ... /opt/TWWfsw/gettext011/lib/libintl.so -liconv -lc -lm
then we have this in ltmain.in:
# Go through the arguments, transforming them on the way.
while test $# -gt 0; do
...
# Some other compiler argument.
*)
...
# Now actually substitute the argument into the commands.
if test -n $arg; then
compile_command=$compile_command $arg
finalize_command=$finalize_command $arg
fi
done # argument parsing loop
So $compile_command and $finalize_command will have
/opt/TWWfsw/gettext011/lib/libintl.so but $deplibs won't. Nothing in
$compile_command nor $finalize_command is used when --mode=link. How
should I solve this? Should I add a case statement to the loop above
looking for *.${shrext} and, if so, add it to deplibs if
hardcode_direct=yes?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: How to get libtool working on cris
On Thu, Jul 17, 2003 at 08:13:10PM +0200, Simon Posnjak wrote: What do I have to do to make libtool recognise cris-axis-none and make it create shared libraries? Thank you. P.S. If I wasn't specific enough: -The tool chain uses standard GNU tools (gcc, ld, as) -It runs linux (and i'm on ia32 linux - i'm cross compiling) -more info abut cris can be found on developer.axis.com Do you know how to *manually* created a shared library on Axis Cris? Is it similar to creating shared libraries on Linux? If so, checkout the 1.5 branch and search for linux and determine if settings are similar to your platform. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: max_cmd_len in ltmain.sh
On Sun, Jul 20, 2003 at 11:09:05AM -0700, Keith Packard wrote: I'm having trouble understanding how max_cmd_len is supposed to be getting initialized in ltmain.sh so I can use libtoolize with my package. libtool has a nice assignment, but ltmain.sh contains only references to this variable. It should be set in the generated 'libtool' program. Look at AC_LIBTOOL_SYS_MAX_CMD_LEN in libtool.m4. Am I supposed to perform additional magic on the ltmain.sh that libtoolize sticks in my directory? No. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5: superfulous tests
On Sun, Jul 20, 2003 at 08:56:32PM -0400, Thamer Al-Harbash wrote: I have been using libtool with some mixed feelings on the amount of tests it adds to `configure'. Specifically, although my source is all in C, libtool runs C++ and Fortran tests. This adds a bit of bloat everytime a user runs the configuration script. I have already explicitly specified the language in my configure.ac with: AC_LANG(C) Is there anyway to disable libtool tests for Fortrant and C++? I couldn't find any mention of it in the manual. Not with 1.5. I just submitted a patch to libtool-patches that adds a new macro, AC_LIBTOOL_TAGS to do what you want. There are some caveats though. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: max_cmd_len in ltmain.sh
On Sun, Jul 20, 2003 at 07:53:50PM -0700, Keith Packard wrote: Around 21 o'clock on Jul 20, Albert Chin wrote: It should be set in the generated 'libtool' program. Look at AC_LIBTOOL_SYS_MAX_CMD_LEN in libtool.m4. Yes, it's nicely set in the generated 'libtool' program that gets installed on my machine, but I want to use 'libtoolize --force --copy' in my package which dumps 'ltmain.sh' in the package directory; configure builds libtool from that. But, the generated libtool is then missing the definition of max_cmd_len. Am I missing something that I need to add to connfigure.ac? Odd. So max_cmd_len in your generated libtool is empty? What's the libtool output of your ./configure run look like? What platform? What version of libtool? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
IRIX inheriting RPATH of libraries
Ugh! Looks like IRIX will inherit the RPATH of a library. So, say program foo is linked against libbar2.so and libbar2.so is dependent on libbar1.so. At build time, the runtime path of the .libs directory containing libbar1.so will be added to the RPATH entry of libbar2.so. Then, when program foo is created, this .libs directory is added to the RPATH entry of program foo. Because program foo is not relinked at install time, it keeps this RPATH entry. Looks like we need another variable, inherit_rpath, that relinks programs when true. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: IRIX inheriting RPATH of libraries
On Mon, Jul 21, 2003 at 11:37:27AM -0500, Albert Chin wrote: Ugh! Looks like IRIX will inherit the RPATH of a library. So, say program foo is linked against libbar2.so and libbar2.so is dependent on libbar1.so. At build time, the runtime path of the .libs directory containing libbar1.so will be added to the RPATH entry of libbar2.so. Then, when program foo is created, this .libs directory is added to the RPATH entry of program foo. Because program foo is not relinked at install time, it keeps this RPATH entry. Looks like we need another variable, inherit_rpath, that relinks programs when true. Ok, rather than doing this, I'm going to set fast_install=no on IRIX. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: IRIX inheriting RPATH of libraries
On Mon, Jul 21, 2003 at 05:02:45PM -0500, Tim Mooney wrote: In regard to: IRIX inheriting RPATH of libraries, Albert Chin said (at...: Ugh! Looks like IRIX will inherit the RPATH of a library. So, say program foo is linked against libbar2.so and libbar2.so is dependent on libbar1.so. At build time, the runtime path of the .libs directory containing libbar1.so will be added to the RPATH entry of libbar2.so. Then, when program foo is created, this .libs directory is added to the RPATH entry of program foo. Because program foo is not relinked at install time, it keeps this RPATH entry. Looks like we need another variable, inherit_rpath, that relinks programs when true. I must be missing something, because I'm not seeing how that's different from other osf-style linkers. Tru64 executables pick up the DT_RPATH from each and every library they link directly against -- I guess I've never thought about or checked whether they pick up the RPATH for libraries that their libraries depend on. I know you're very familiar with the Tru64 linker/loader behavior. Can you explain what's different that you're surprised about in the IRIX linker vs. the Tru64 linker or other osf-style linkers? I actually like and have made great use of the executables pick up the RPATH entries for libraries they link against. It can be very handy. This isn't a problem for Tru64 UNIX because hardcode_into_libs=no. If hardcode_into_libs=yes, Tru64 UNIX would have the same problem. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Request for option to disable building of static library
On Wed, Jul 23, 2003 at 08:48:54AM +0200, Schleicher Ralph (LLI) wrote: Howard Chu writes: I've requested this feature and sent patches for it at least twice over the past 3 years. The first time was silently ignored, the second rejected. I submitted a patch on 2003-02-10 for the upcomming Libtool 1.5 release but it was silently ignored, too. Anyone available to review this patch? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool problem
On Fri, Jul 25, 2003 at 10:27:58AM +0100, M. Lavasani wrote: This is a general question, although I am going to refer to a specific paltform and specific program. I am trying to compile pango on HPUX-11.22 (IA64) platform using gcc-3.3.1. Pango first generates libpango.so, Then it generates another library libpangox.so that links to libpango.so. shared library list: ./.libs/libpango.so libX11.so.1 libc.so.1 as you see from the above it links to ./.libs/libpango.so. This has caused lot of problem. Is this the result when libpangox.so is created or *after* it is installed? What matters is the result after installation. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: disable C compiler check?
On Thu, Jul 31, 2003 at 03:26:52PM +0200, Patrick Guio wrote: I have an application that just contain C++ code and I will only need the code to be linked with C++ code. I wonder whether there is a way to disable C (and fortran) checkings when running the macro AC_PROG_LIBTOOL in the configure.ac ? You cannot remove the C check. As to removing the other checks, there is a patch for it but we have to wait for the copyright assignment form for the submitter to be accepted before the patch is applied, barring any objections. Ideally, libtool should treat C like C++ and other languages but it doesn't yet. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: C++ convenience libraries
On Sun, Aug 24, 2003 at 02:32:37AM -0400, Greg Hudson wrote:
When libtool builds these convenience libraries, it adds the static
libstdc++ library (by extracting the contents of libstdc++, then
adding it to the convenience library)
I'm seeing the same thing on Solaris 9, with a gcc installed without
shared libraries. (I sent a note about it to [EMAIL PROTECTED] but
don't see it in the archives.) The following script demonstrates the
problem:
echo '#include iostream' test.cc
echo 'void test() { std::cout 1; }' test.cc
libtool --mode=compile g++ -o test.lo -c test.cc
libtool --mode=link g++ -o libtest.la test.lo
echo '#include iostream' test2.cc
echo 'void test(); void test2() { test(); std::cout 2; }' test2.cc
libtool --mode=compile g++ -o test2.lo -c test2.cc
libtool --mode=link g++ -rpath /tmp -o libtest2.la test2.lo libtest.la
One possible solution is to ignore postdeps when creating convenience
libraries.
Any downsides to this? It does seem to make sense. And what about C
convenience libraries (or any convenience library)? Ignore postdeps
totally when creating convenience libraries?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Creating lock file for compilers that don't support -c -o
If a compiler doesn't support -c -o, libtool creates a lock file by hard linking the libtool binary with the lock file. This is a problem if the libtool binary is on a different file system than the lock file. Why don't we use a symbolic link? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Creating lock file for compilers that don't support -c -o
On Tue, Aug 26, 2003 at 01:49:10PM +1000, Robert Collins wrote: On Tue, 2003-08-26 at 12:58, Albert Chin wrote: Why not use $srcfile and $srcfile.lock as the lock file? So, rather than: They may be on different fs's. How is that possible? If we use $srcfile.lock as the lock file it is guaranteed to be on the same filesystem as $srcfile. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Building .so files only.
On Fri, Aug 29, 2003 at 12:55:19AM -0400, Daniel Reed wrote: To produce only .la and .so files, you can pass -module -avoid-version to libtool. In Automake, you can do this by using something similar to: pkglib_LTLIBRARIES = mymod.la mymod_la_SOURCES = mymod.c mymod_la_LDFLAGS = -module -avoid-version This also removes the requirement that the library name start with lib. This depends on the platform. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: dependency_libs issue
On Mon, Sep 08, 2003 at 04:38:40PM +1000, Clinton Roy wrote: I've got code in configure.ac that eventually sets LIBS to: LIBS = -lgdbm -L/dstc/lib -lxml2 -lz -lpthread -lm -ldb However, ltmain.sh produces a .la file with: dependency_libs=' /usr/lib/libgdbm.la -L/dstc/lib /usr/lib/libxml2.la -lz -lpthread -lm -ldb' How did that /usr/lib/libxml2.la get in there? Does this fix it (should apply to 1.5)? -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/ltmain.in,v retrieving revision 1.334.2.7 diff -u -3 -p -r1.334.2.7 ltmain.in --- ltmain.in 31 Jul 2003 20:46:40 - 1.334.2.7 +++ ltmain.in 20 Oct 2003 10:31:08 - @@ -2626,7 +2629,7 @@ EOF done fi if test $pass != dlopen; then - if test $pass != conv; then + if test $pass != conv test -n $newlib_search_path ; then # Make sure lib_search_path contains only unique directories. lib_search_path= for dir in $newlib_search_path; do ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4.3 searches /usr/lib before -Ldir
On Mon, Oct 20, 2003 at 07:32:21PM -0400, Pierre Sarrazin wrote: I have a C++ package that contains a library and two command-line tools. If I install this package through an RPM (on a RedHat 8.0 system), I endup with the lib*.la and lib*.so files in /usr/lib. I get into trouble when I compile the sources of a newer version of the package, while the older version is still installed. You should use libtool 1.5 if you're using C++. The libtool command that is run by make is the following: /bin/sh ../../libtool --mode=link g++ -g -Wall -o french-conjugator french_conjugator-french-conjugator.o french_conjugator-Command.o -lxml2 -lpthread -lz -lm -L../verbiste -lverbiste-0.1 The -L option correctly points to the src/verbiste directory, where the newer library has been compiled. However, libtool generates this g++ command to do the linking: g++ -g -Wall -o french-conjugator french_conjugator-french-conjugator.o french_conjugator-Command.o /usr/lib/libxml2.so -lpthread -lz -lm -L/home/ps/cvswork/verbiste/src/verbiste /usr/lib/libverbiste-0.1.so Does this patch (against 1.5) work for you? http://mail.gnu.org/archive/html/libtool/2003-10/msg00067.html It should be trivial to apply the patch to your 1.4.3 version. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool finds the wrong freetype?
On Wed, Oct 22, 2003 at 10:11:34PM +0900, Peter O'Gorman wrote: Lars Clausen wrote: It should find libfreetype in $HOME/lib, it's been first in the LD_LIBRARY_PATH for the entire installation, and pkg-config points to there. Running strace it appears that libtool looks for '../lib/libfreetype.la', but since this is run in the subdirectory 'app', it doesn't find it. It then proceeds to find it in /usr/lib, which unfortunately is a different libfreetype. ltmain.sh says that the version is 1.5.0a. I've been looking around for references to /usr/lib/libfreetype in the local .la files, but with no luck. Any ideas on how to proceed from here? Does this patch from Ben Reed help? http://mail.gnu.org/archive/html/libtool-patches/2003-06/msg2.html Or this one: http://mail.gnu.org/archive/html/libtool/2003-10/msg00067.html -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool .. [path to shared library] ...
If I invoke libtool as so: $ libtool ... [path to shared library] ... is libtool suppose to pass [path to shared library] to the final link stage? It's ignoring anything on the command line that ends with *$shrext. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool help
On Mon, Nov 10, 2003 at 09:40:54AM -0800, Nimmo, Bill wrote: I am having a bit of trouble using libtool within a makefile in the cygwin environment. Basically, I am getting the error message: libtool: invalid number of arguments Try `libtool --help' for more information. I have tried may variations in the makefile, and the online documentation doesnt seem to help. Please, any help would be appreciated. This is the complete output from the attempted make /bin/sh.exe /cygdrive/c/cygwin/bin/libtool --mode=link gcc -g\ -o pli bits.o Dbase.o debug.o C2PCThread.o ControlMeasure.o ControlMeasureFactor y.o FC2525.o Formulary.o Lock.o LOD.o MSD.o MSL.o OFileThread.o OTGold.o OTGoldT hread.o OUidFactory.o OverAnalyze.o OverEntry.o Overlay.o OverlayFileInfo.o pars eovers.o lexovers.o Parts.o PhaseLine.o PlayThread.o pli.o PliApp.o PliQThread.o PliConn.o PliUnit.o PliUnits.o Points.o Proximity.o Queue.o RateTrigger.o RawTe xt.o SDZ.o Segment.o SintCHandler.o SintCMsg.o SintCppMsg.o SintCQObj.o SintCCli ent.o TwoDThread.o ThreeDThread.o TimeTeller.o Unit.o UserProxy.o UserClient.o User2Binary.o libtool: invalid number of arguments What if you replace gcc\ with gcc ? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5 tag woes
On Wed, Nov 12, 2003 at 06:59:44PM +0100, Paolo Bonzini wrote: I have just upgraded to libtool 1.5 (Debian's package which is taken out of CVS) and here are my first experiences. HEAD or branch-1-5? I think development is happening on HEAD towards a 1.6 release. However, I have had serious problems trying to do this, because there is a complete dearth of docs about tags. So far, my only solution has been to write an Autoconf macro that wraps AC_LIBTOOL_CONFIG with a customizable preamble: this way, I can put the code to do my custom changes in the preamble and invoke _LT_AC_LANG_C_CONFIG to create the tag. There could definitely be improvement on tag support. Would be great if the default language (C) was a proper tag as well. Finally, I am quite disgruntled by the 250kb of shell code that is included in every project even if the CXX/GCJ/F77/RC tags are never used; my solution has been to redefine AC_LIBTOOL_CXX_CONFIG and friends to a colon, but this is quite of a hack. Again I ask if there is a nicer way to strip down my already huge (750kb) configure script. Does this help? AC_LIBTOOL_TAGS([]) -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5 tag woes
On Fri, Nov 14, 2003 at 10:44:52AM +0100, Paolo Bonzini wrote: Does this help? AC_LIBTOOL_TAGS([]) That's only in CVS (actually, I checked and it is not in 1.5, so it must be in CVS). I can send you a patch against 1.5 if you want. I don't see it that bad that C is not a proper tag, actually. It would also be good if enable_shared and enable_static became proper tag variables instead of globals. BTW, the October patch for -shared and -static handling (which I just noted) is a complete duplicate of the special tags disable-shared and disable-static. It should be reverted IMO, it is just featurism. When *I* proposed such a change (with no attached patch, granted :-) I was told to use the multi-language branch instead. Why make enable_shared and enable_static specific to a tag? Wouldn't it be odd that you create shared libs for C programs and static for C++? And, the --enable-shared and --enable-static options would have to multiply (--enable-c-shared, --enable-cxx-shared, etc). -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: system libraries that need -R/path/
On Tue, Nov 25, 2003 at 12:50:38PM +, Gary V. Vaughan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harlan Stenn wrote: | Does somebody have an autoconf macro to handle adding -R/path/ stuff when | libraries are found? | | It would be nice if it also had the ability to handle cross compiling. | | This came up for ntp - if the shared library of libcrypto is found the | -L flag is set, but no -R flag is set. | | I suspect other folks have had to deal with this... AC_LIBTOOL_PROG_LD_SHLIBS sets hardcode_libdir_flag_spec, hardcode_libdir_flag_spec_ld and hardcode_libdir_separator. Currently this macro isn't designed to run outside AC_PROG_LIBTOOL and has some implicit dependencies on other macros in libtool.m4 that we haven't analysed yet. With a little cleanup it shouldn't be difficult to pull it out into a separate file, along with the macros it really needs, so that aclocal can do the right thing. Patches greatfully accepted. If libtool was used rather than the compiler *during* ./configure you wouldn't have to worry about -R. However, you might find this useful: http://mail.gnu.org/archive/html/autoconf/2002-05/msg00124.html It was mentioned recently on this list. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: tag inference broken?
On Sat, Dec 06, 2003 at 10:57:52PM +0900, Peter O'Gorman wrote: Okay, I must be stupid, the tag inference goes like this: case $base_compile in # Blanks in the command may have been stripped by the calling shell, # but not from the CC environment variable when configure was run. $CC * | $CC * | `$echo $CC` * | `$echo $CC` *) ;; # Blanks at the start of $base_compile will cause this to fail # if we don't check for them as well. Now, $CC is allowed to be a program name with arguments (isn't it?), but at this point $base_compile only contains the program name gcc in my case, so when I set CC to (on darwin) gcc -arch ppc -arch i386 and set CXX to g++ -arch ppc -arch i386 I expected (without having looked at the code) tag inference to work. It doesn't of course. Before the case, what is the output of: echo .$CC. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool .. [path to shared library] ...
Repost as the first try didn't garner a response. If I invoke libtool as so: $ libtool ... [path to shared library] ... is libtool suppose to pass [path to shared library] to the final link stage? It's ignoring anything on the command line that ends with *$shrext. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool .. [path to shared library] ...
On Tue, Dec 16, 2003 at 11:33:15AM +, Gary V. Vaughan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Albert Chin wrote: | Repost as the first try didn't garner a response. | | If I invoke libtool as so: | $ libtool ... [path to shared library] ... | is libtool suppose to pass [path to shared library] to the final link | stage? It's ignoring anything on the command line that ends with | *$shrext. I can see no reason why it should. Passing `-L[path] -l[basename]' will happily pick up a system .so library even if there is no associated .la file. ~ A quick scan through ltmain.in doesn't reveal any code to deliberately ignore absolute library paths as far as I can see. Looks like a bug to me :-( What exactly are you linking? lftp 2.6.10 linking against the gettext libraries on HP-UX. Because the author used $(INTLLIBS) instead of $(LTLIBINTL), he got the .sl versions of the gettext libraries. I fixed it on the 1.5 branch but I just hacked together a solution for now. I'd send you a diff of my ltmain.in but savannah is still down :( -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Building 64-bit C++ shared libraries
libtool 1.5 has the following to pass the -m64 GCC flag through to the command building a C++ library: # gcc -m* arguments should be passed to the linker via $compiler_flags # in order to pass architecture information to the linker # (e.g. 32 vs 64-bit). This may also be accomplished via -Wl,-mfoo # but this is not reliable with gcc because gcc may use -mfoo to # select a different linker, different libraries, etc, while # -Wl,-mfoo simply passes -mfoo to the linker. -m*) This doesn't do anything for building 64-bit C++ libraries with the vendor C++ compiler. Do we need to do something similar? Or is it easier for us to say that if $LD == $CC for a tag, any unrecognized options are passed to $compiler_flags? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Building 64-bit C++ shared libraries
[resending as this garnered no response] libtool 1.5 has the following to pass the -m64 GCC flag through to the command building a C++ library: # gcc -m* arguments should be passed to the linker via $compiler_flags # in order to pass architecture information to the linker # (e.g. 32 vs 64-bit). This may also be accomplished via -Wl,-mfoo # but this is not reliable with gcc because gcc may use -mfoo to # select a different linker, different libraries, etc, while # -Wl,-mfoo simply passes -mfoo to the linker. -m*) This doesn't do anything for building 64-bit C++ libraries with the vendor C++ compiler. Do we need to do something similar? Or is it easier for us to say that if $LD == $CC for a tag, any unrecognized options are passed to $compiler_flags? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Use of grep -E in win32_libid()
Why does win32_libid() in ltmain.in use grep -E rather than $EGREP? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool link order problem
On Wed, Jan 28, 2004 at 10:59:32PM +0900, Peter O'Gorman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zachary Pincus wrote: | Which libtool translates into the following link command: | g++ -dynamiclib -single_module -o OUTPUT.dylib [input .o files] | /usr/X11R6/lib/libX11.dylib /usr/X11R6/lib/libXp.dylib | /usr/X11R6/lib/libXext.dylib /usr/X11R6/lib/libICE.dylib | /usr/X11R6/lib/libSM.dylib /usr/X11R6/lib/libXt.dylib | /usr/X11R6/lib/libXmu.dylib -L/usr/X11R6/lib -L/sw/lib | /sw/lib/libXm.dylib /sw/lib/libMrm.dylib /sw/lib/libUil.dylib -lz -lm | -install_name /usr/local/lib/libhighgui-0.9.5.dylib | -compatibility_version 6 -current_version 6.0 | I don't see what can be done about this. When I look at fink's libXm.la I see most of those libs in dependency_libs, which implies that they need to come on the link line before libXm.dylib. They do. Shouldn't the libraries in dependency_libs come after the library? Or am I missing something? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool macros installed in pkgdatadir?
On Wed, Jan 28, 2004 at 10:13:21PM +, Scott James Remnant wrote: On Wed, 2004-01-28 at 20:29, Braden McDaniel wrote: Why are the libtool macros being installed to $(pkgdatadir) rather than $(datadir)/aclocal? Because aclocal is slowly being deprecated, and will eventually vanish entirely. Managing Autoconf macros really isn't a job for Automake. The new utopia is to create a directory within your source called m4 (or some such) and in configure.ac declare AC_CONFIG_MACRO_DIR([m4]) Then when you run libtoolize, it will copy the appropriate m4 files into this directory for you. One day a version of Autoconf will use these, but for now when you run aclocal it'll add an m4_include line to aclocal.m4 for each of these files (rather than including them verbatim). Ugh. So *every* package providing useful 3rd-party autoconf macros must be copied locally to the package using them? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
func_infer_tag() broken on IRIX 6.5
$ cat /tmp/a.sh
#!/bin/sh
foo () {
echo .$0.
echo .$1.
}
foo a b c
$ uname -a
SunOS vegeta 5.7 ...
$ /tmp/a.sh
./home/china/a.sh.
.a.
$ uname -a
IRIX64 puar 6.5
$ /tmp/a.sh
.foo.
.a.
$ ksh /tmp/a.sh
./home/china/a.sh.
.a.
From sh(1) on IRIX:
Note: As of IRIX 6.4, sh is the Korn shell rather than the Bourne shell.
See bsh(1) for the Bourne Shell description. See the COMPATIBILITY
ISSUES section below for more detail.
...
COMPATIBILITY ISSUES
To retain some backward compatibility to the Bourne shell, certain Korn
shell features are controlled by how the shell is invoked and/or the
current value of the environment variable _XPG.
...
When the shell is invoked as sh and the current value of the _XPG
environment variable is not equal to 1 (one), the special positional
parameter $0, within a function call, is the name of the function.
Otherwise, it is the name of the invoking shell script.
So this means func_infer_tag() is broken in branch-1-5 because it does
this:
func_infer_tag () {
if test -n $available_tags test -z $tagname; then
CC_quoted=
...
# Blanks at the start of $base_compile will cause this to fail
# if we don't check for them as well.
*)
for z in $available_tags; do
if grep ^# ### BEGIN LIBTOOL TAG CONFIG: $z$ $0 /dev/null; then
So, should I modify the top of ltmain.in from:
# The name of this program.
progname=`$echo $0 | ${SED} 's%^.*/%%'`
modename=$progname
to:
# The name of this program.
progname=`$echo $0 | ${SED} 's%^.*/%%'`
full_path_progname=$0
modename=$progname
and then we can use $full_path_progname in func_infer_tag().
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: func_infer_tag() broken on IRIX 6.5
On Wed, Feb 11, 2004 at 07:02:00PM +, Gary V. Vaughan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Albert Chin wrote:
| So this means func_infer_tag() is broken in branch-1-5 because it does
| this:
| func_infer_tag () {
| if test -n $available_tags test -z $tagname; then
| CC_quoted=
| ...
| # Blanks at the start of $base_compile will cause this to fail
| # if we don't check for them as well.
| *)
| for z in $available_tags; do
| if grep ^# ### BEGIN LIBTOOL TAG CONFIG: $z$ $0
/dev/null; then
|
| So, should I modify the top of ltmain.in from:
| # The name of this program.
| progname=`$echo $0 | ${SED} 's%^.*/%%'`
| modename=$progname
| to:
| # The name of this program.
| progname=`$echo $0 | ${SED} 's%^.*/%%'`
| full_path_progname=$0
| modename=$progname
|
| and then we can use $full_path_progname in func_infer_tag().
Agreed, although I'd suggest argv0 as the variable name.
I submitted a patch using $progname_full_path. I dislike $argv0
because it's context-sensitive (i.e. in a shell function I'd expect it
to be $0).
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Need help with libtool on Solaris
On Wed, Feb 11, 2004 at 02:08:42PM -0800, johnny henrik wrote: I am stuck with this issue. Please help Our libtool work fine with gnu gcc. now we want to cofigure it to work with / opt/SUNWspro/bin/CC compiler. And it fail when it links. Notice that it still use gcc -share instead of /opt/SUNWspro/bin/CC -shared. Why? and how do i make it to use /opt/SUNWspro/bin/CC instead of gcc /usr/local/bin/libtool --mode=link --tag=CC /opt/SUNWspro/bin/CC -I/home/john/ common/gpslib/source/build/output/sol/include -I/include -L/home/john/common/ gpslib/source/build/output/sol/lib -L/lib -o libslsmath.la /home/john/common/ gpslib/source/build/output/sol/objs/slsmath.lo -rpath /home/john/common/gpslib/ source/build/output/sol/lib mkdir .libs gcc -shared -Wl,-h -Wl,libslsmath.so.0 -o .libs/libslsmath.so.0.0.0 /home/john /common/gpslib/source/build/output/sol/objs/.libs/slsmath.o -L/home/john/ common/gpslib/source/build/output/sol/lib -L/lib -lc You cannot use a libtool configured for GCC with the Sun compiler. Each libtool script is custom-generated for a specific compiler. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Need help with libtool on Solaris
On Fri, Feb 13, 2004 at 10:52:02AM -0800, johnny henrik wrote: How do I configure libtool to work with CC compiler? Please give my some pointer/link ... Build it just like you did to create /usr/local/bin/libtool but use The Sun C compiler (i.e. CC=cc CFLAGS=blah). -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool: link: warning: '[.la file]' seems to be moved
ltmain.in prints out a warning when it thinks the .la file isn't in $libdir: if test $absdir != $libdir; then $echo $modename: warning: \`$deplib' seems to be moved 12 fi However, if $absdir has .., and it resolves to $libdir taking .. into consideration, the warning is still printed. How do we solve this? (cd $absdir; /bin/pwd) won't work because of automounter madness. Or should we just remove the message? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: -Wl,-rpath issues
On Mon, Feb 16, 2004 at 10:58:20AM -0500, Steven F. Killen wrote: I did some searching in libtool and bugs-libtool, and didn't find anything directly related to a problem I'm having with LDFLAGS and libtool. Due to our distribution mechanism, programs that use shared libraries need to be told where to look at runtime. LDFLAGS looks like this: -L/usr/local/lib -Wl,-rpath /usr/local/lib You should use -Wl,-rpath,/usr/local/lib ^ -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: relink_command quoting bug
On Mon, Feb 16, 2004 at 11:39:17PM -0500, Michael Pruett wrote: I have found that libtool fails to quote directory names when generating relink_command in wrapper scripts. This has been tested with versions 1.4.2a on Linux and 1.5.2 on Mac OS X. The wrapper scripts generate a line which looks like the following: relink_command=(cd /home/michael/my code/src; ...) Search your libtool script for a line like: relink_command=(cd `pwd`; ... and change it to: relink_command=(cd \`pwd`\; ... Does that fix it? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: tagdemo-make.test fails
On Wed, Feb 18, 2004 at 10:00:51AM -0800, Lon Canaday wrote: tagdemo-make.test fails and I can't find info on what it does. The info section on testing doesn't even mention tagdemo. What does it do? How critical is it to using libtool? Platform? Compiler? We need more info. I think if you have VERBOSE=1 set the tests will be more verbose. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.x linking regression on Tru64 (-pthread)
On Thu, Feb 19, 2004 at 12:07:21PM -0600, Tim Mooney wrote: Given a project that uses libtool 1.4.3 and also uses pthreads, it's common to have `-pthread' in CFLAGS when configuring the project. The man page for cc defines -pthread as: -pthread Directs the linker to use the threadsafe version of any library speci- fied with the -l option when linking programs. This option also tells the linker to include the POSIX 1003.1c-conformant DECthreads inter- faces in libpthread when linking the program. This option also defines the _REENTRANT macro. In any case, for 1.4.3 compiling with libtool works correctly, and linking shared libraries also works as expected. If the project is updated to use libtool 1.5.2, though, linking fails, because `-pthread' is now being passed to ld, and ld doesn't understand that option. I haven't had a chance to look much at the problem, but thought I would report it. Please let me know if I can provide additional information. I noticed this too but haven't had a chance to look into it. Maybe this weekend. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool: link: warning: '[.la file]' seems to be moved
On Fri, Feb 13, 2004 at 02:07:12PM -0600, Albert Chin wrote: ltmain.in prints out a warning when it thinks the .la file isn't in $libdir: if test $absdir != $libdir; then $echo $modename: warning: \`$deplib' seems to be moved 12 fi However, if $absdir has .., and it resolves to $libdir taking .. into consideration, the warning is still printed. How do we solve this? (cd $absdir; /bin/pwd) won't work because of automounter madness. Or should we just remove the message? Anyone? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool-1.5.2 searches /usr/lib before -Ldir
On Sat, Feb 21, 2004 at 10:43:22AM -0800, Russ Allbery wrote: Pieter Grimmerink [EMAIL PROTECTED] writes: OK, now I've given the library in -Ldir a .la file as well. Now both libraries have a .la file, and libtool-1.5.2 uses the correct library, in -Ldir. So that's solved then. So, basically, it sounds like libtool has reinvented the very annoying Tru64 library search mechanism, where any shared libraries are found before static libraries regardless of the relative order on the library path, except as applied to *.la files. I don't think libtool is doing this. It looks like it's preferring libraries with corresponding .la files. Even that is a bug though. Someone needs to dig further. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Dlopening documentation
On Thu, Mar 04, 2004 at 06:29:16PM +, Gary V. Vaughan wrote:
If @var{dlname} is empty, then the library cannot be dlopened.
Otherwise, it gives the dlname of the library. So, if the library was
installed as @file{/usr/local/lib/libhello.la}, and the @var{dlname} was
@file{libhello.so.3}, then @file{/usr/local/lib/libhello.so.3} should be
dlopened.
If your program uses this approach, then it should search the
directories listed in the @[EMAIL PROTECTED]@code{LIBPATH}
on AIX, and @code{SHLIB_PATH} on HP-UX.} environment variable, as well as
the directory where libraries will eventually be installed. Searching
this variable (or equivalent) will guarantee that your program can find
its dlopened modules, even before installation, provided you have linked
them using libtool.
I have a feeling that this is all done automatically by lt_dlopen. If it
isn't then it should be...
Yes, it should be. BTW, how do we handle the case where
need_lib_prefix!=no?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Problems installing dependant libraries
On Fri, Mar 12, 2004 at 01:25:15PM -0600, Bob Friesenhahn wrote: On Fri, 12 Mar 2004, Fredrick Meunier wrote: Hi, I have just come across the same problem raised in the thread Library dependencies make install on the automake lists in January this year (http://mail.gnu.org/archive/html/automake/2004-01/msg00145.html) in a reasonably large project. The last message in the thread from Alexandre Duret-Lutz suggests: Another idea is to split the installation procedure in two steps: copy all libraries, and once it is done relink all libraries. Would that work? If so, we need a way to tell libtool to copy libraries without relinking. The fundamental problem is that Automake does not have an overall coherent understanding of the library dependencies when libraries are built using a recursive build. Without understanding the library dependencies, it is difficult to see how relinking would work. Why not just have the developer write a Makefile.am so the libraries are built/installed in the correct order? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libltdl FreeBSD 5.0
On Thu, Mar 18, 2004 at 01:36:37PM -0600, Bob Friesenhahn wrote: The package I maintain has about 100 modules. When loading all of the modules in succession, failures are observed when loading some of the modules even though these modules do load individually. When modules fail to load seems to depend on which dependent program requests the loading. The error information returned by libltdl doesn't seem to make any sense since it refers to unresolved symbols from previously loaded modules. Removing just one problem module from the load request causes all of the loads to succeed. The modules do all load ok under Linux, Solaris, AIX, IRIX, and HP-UX. Is anyone aware of FreeBSD-specific issues with module loading? Is there some resource limit that may be expended? Tried upgrading to the latest 5.x release or 5-CURRENT? Nothing in sysctl -a stands out to me. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
