Re: -fpic instead of -fPIC
Hi Joakim,
* Joakim Tjernlund wrote on Mon, Jun 06, 2005 at 11:15:40PM CEST:
* Joakim Tjernlund wrote on Mon, Jun 06, 2005 at 07:21:17PM CEST:
OK, will look at that some more. I don't automake, autoconf and libtool
very well so I need
a liite guidance here. Can I just run aclocal and modify the generated
aclocal.m4? I would
then commit aclocal.m4 to CVS and use that when building our libs.
Yes, you can do that.
Just did that but aclocal.m4 got regenerated by the build. hmm, need
to look some more at that
I get confused sometimes about the rebuilding rules. configure.{ac,in}
should be a dependency of aclocal.m4, so you should make sure it's not
newer. There are more possible dependencies..
Is there a better way?
If you use recent Automake, it might be more favorable for you to create
a subdir `m4' and put all the m4 macro files you need in there
(libtool.m4, ...), and then put
ACLOCAL_AMFLAGS = -I m4
in $top_srcdir/Makefile.am.
Is 1.4-p6 recent enough? Seems so. I have copied libtool.m4 to my
local m4 dir and modified it to:
AC_MSG_RESULT([$_LT_AC_TAGVAR(lt_prog_compiler_pic, '-fpic')])
but so far no luck :(
First off: 1.4-p6 is _anything_ but recent. I believe 1.9.5 is the most
recent stable release. There have been numerous changes since 1.4, some
may need you to adjust your source somewhat (the first and second digit
specify the Automake interface version), but honestly, I can't tell you
much about 1.4.
After you have updated Automake, and modified m4/libtool.m4, run
aclocal -I m4
(this should be done automatically with the line I mentioned above, and
with autoreconf; but please again, use a recent Autoconf as well).
Just to answer your next question: It is very wise to install all of the
Autotools into the same $prefix...
Just noticed another problem: All my libs are created without .so suffix.
This is on a debian(prerelease of 3.1)
Please specify Libtool version used, the command line issued to build
the libraries, and what libtool outputs. My guess would be that you
omit the `-rpath ...' argument and libtool creates convenience archives.
I don't know about the ancient Automake, but recent ones add this
argument to the command line for libs not in noinst_* variables.
Still on configure.in :)
No problem.
Do you perchance build for a different system? For that it might make
sense to think about setting pic_flag differently (for example if the
usual memory of such an embedded target makes -fPIC obsolete anyway).
pic_flag ? I was thinking of lt_prog_compiler_pic.
Yes, certainly. Sorry for the confusion.
I am crossbuilding from linux/x86 to linux/ppc. semtimes we build for
linux/x86 to test.
Libtool (still) has many shortcomings when it comes to cross
compilation.
*snip stuff that I agree with and needs no further comment*
Now the ELF issue (which is much more nicely explained in dsohowto):
Every access to a global variable has to go through reloc each time.
Why?
*snip*
yes, but within a lib you should only need one reloc for all accesses,
right? If I compile 2 files into a lib, each referencing foo once, I
get two relocs for foo. If I compile 1 file into a lib that reference
foo twice, I get one reloc.
The linker should be able to combine the first example into one reloc.
Hmm. I'd need to look at linker docs in order to be able to comment on
this (it's been a while), sorry.
Another thing thats annoying is that a string constant needs a
reloc(on PPC). Gcc/ld should be able to merge all/most such relocs
into one, atleast all in one source file.
Same here.
Regards,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: shared library depending on static library on Solaris
Hi Sven, I am very sorry it took me so long to look at this. * Sven Verdoolaege wrote on Tue, May 10, 2005 at 06:16:52PM CEST: I wrote a library called barvinok (http://www.kotnet.org/~skimo//barvinok/barvinok-0.15.tar.gz) which uses a static library called ntl. In configure.in, I simply do AC_CHECK_LIB(ntl, main,[],[ AC_MSG_ERROR(Need ntl) ]) so -lntl ends up in LIBS. Now, what I would assume that would happen is that libtool would notice that ntl is a static library and not link it into the shared barvinok library, but instead add -lntl to dependency_libs. Unfortunately, on Solaris, libtool does try to link in ntl in the shared library itself, resulting in relocation errors. /bin/sh ./libtool --mode=link g++ -g -O2 -L/home/sven/loop//lib -L/home/sven/loop//lib -o libbarvinok.la -rpath /home/sven/loop//lib -version-info 8:0:4 ev_operations.lo genfun.lo util.lo barvinok.lo -lntl -lpolylibgmp -lgmp *snip* Text relocation remains referenced against symbol offset in file unknown 0x148 /home/sven/loop//lib/libntl.a(tools.o) [..many more symbols..] This happens with both libtool 1.5.8 and 1.5.16. Acknowledged. Is there a problem with my assumptions or with libtool ? This is a bug in libtool, I believe. deplibs_check_method may not be pass_all on your system. billie$ uname -a SunOS billie 5.8 Generic_117350-24 sun4u sparc Unfortunately, I still don't know enough about Solaris to fix this right away without breaking other uses. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Automatic response to your mail (Error)
The automatic reply to this e-mail which you should have received in response to your e-mail to [EMAIL PROTECTED] has not been defined. Please contact [EMAIL PROTECTED] for assistance. ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
[ This thread starts at
http://lists.gnu.org/archive/html/libtool/2005-05/msg00137.html
and continues at
http://lists.gnu.org/archive/html/libtool/2005-06/msg5.html ]
* Nicolas Joly wrote on Thu, May 19, 2005 at 12:39:43AM CEST:
On Wed, May 18, 2005 at 11:09:21PM +0200, Ralf Wildenhues wrote:
Could you as well please: run the script I sent in another message in
this thread and report the exact ksh version this is on, so we can
mention it in the Autoconf portability section?
[EMAIL PROTECTED] [~] /bin/ksh
$ set -o emacs
$ Version M-11/16/88f
Proposed patch for autoconf.texi below.
Regards,
Ralf
* doc/autoconf.texi (Limitations of Builtins) case: Mention
Tru64 ksh pattern matching bug. Reported against Libtool by
Albert Chin [EMAIL PROTECTED] and
Nicolas Joly [EMAIL PROTECTED].
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.906
diff -u -r1.906 autoconf.texi
--- doc/autoconf.texi 6 Jun 2005 08:01:32 - 1.906
+++ doc/autoconf.texi 7 Jun 2005 09:15:29 -
@@ -10931,6 +10931,14 @@
Even with this, SunOS 5.7 ksh matches a backslash if the set contains any
of the characters @samp{|}, @samp{}, @samp{(}, or @samp{)}.
+On the other hand, Tru64 ksh erroneously always matches a closing parenthesis
+if not specified in a character class:
+
[EMAIL PROTECTED]
+$ @kbd{case foo in *\)*) echo false ;; esac}
+false
[EMAIL PROTECTED] example
+
Some shells, such as Ash 0.3.8, are confused by an empty
@code{case}/@code{esac}:
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Sun, Jun 05, 2005 at 07:38:59PM +0200, Ralf Wildenhues wrote: * Nicolas Joly wrote on Thu, Jun 02, 2005 at 09:00:16PM CEST: On Thu, Jun 02, 2005 at 10:37:27AM +0200, Ralf Wildenhues wrote: * Nicolas Joly wrote on Thu, Jun 02, 2005 at 01:02:32AM CEST: On Wed, May 25, 2005 at 06:22:37PM +0200, Ralf Wildenhues wrote: OK to apply this patch to branch-2-0 and HEAD, and then backport to branch-1-5? Ok, with the patch applied, both libtool-1.5.18 and branch-1-5 are fine: All 112 tests passed. Applied the first patch below to HEAD, branch-2-0, the second to branch-1-5. Thanks a lot. Unfortunately, i was unable to bootstrap libtool HEAD on my Tru64 unix workstation. Next step was to bootstrap it on another machine (NetBSD/amd64); back to the Tru64 machine ... another failure. that just helped us find more HEAD bug(s). :-/ First, could you post the exact output of `bootstrap' on Tru64? I must have done something weird; `./boostrap' now works ... and `./configure' too. But print problems arise with the make command : Since this is not fixed yet, here's at least a workaround: specify either one (or both) of CONFIG_SHELL and ECHO resp. lt_ECHO (branch-1-5 resp. branch-2-0/HEAD) while configuring. CONFIG_SHELL needs to be done like so: CONFIG_SHELL=/bin/foosh /bin/foosh path/to/configure [OPTIONS..] and you should provide an echo which does not interpret backslashes (one of `echo', `/bin/echo', `print -r', `printf %s\\n' should usually do). In the mean time, i tested the solution where `print -r' and `ksh' tests are swapped (attached patch). It seems to go a little further (no more `print' error messages), but seems to fail in another ksh problem/bug : [...] libtool: compile: cc -DHAVE_CONFIG_H=config.h -DLTDL -I. -I. -I.. -I. -I. -I./libltdl -g -c -MD loaders/dlopen.c -o dlopen.o /dev/null 21 /bin/ksh ../libtool --tag=CC --mode=link cc -g -module -avoid-version -o dlopen.la dlopen.lo ../libtool[24]: invalid multibyte character ../libtool[6]: invalid multibyte character ../libtool[2312]: invalid multibyte character libtool: link: invalid operation mode `link' libtool: link: Try `libtool --help --mode=link' for more information. ../libtool[7679]: invalid multibyte character ../libtool[7679]: invalid multibyte character ../libtool[7679]: invalid multibyte character [...] ../libtool[7679]: invalid multibyte character ../libtool[7679]: invalid multibyte character gmake[3]: *** [dlopen.la] Segmentation fault gmake[3]: Leaving directory `/home/njoly/temp/libtool/libltdl' gmake[2]: *** [all] Error 2 -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
* Nicolas Joly wrote on Tue, Jun 07, 2005 at 12:10:47PM CEST: On Sun, Jun 05, 2005 at 07:38:59PM +0200, Ralf Wildenhues wrote: CONFIG_SHELL=/bin/foosh /bin/foosh path/to/configure [OPTIONS..] and you should provide an echo which does not interpret backslashes (one of `echo', `/bin/echo', `print -r', `printf %s\\n' should usually do). In the mean time, i tested the solution where `print -r' and `ksh' tests are swapped (attached patch). It seems to go a little further (no more `print' error messages), but seems to fail in another ksh problem/bug : Please rerun the libtool command line with --debug and post output, you may pack (gzip, bzip2). Regards, Ralf [...] libtool: compile: cc -DHAVE_CONFIG_H=config.h -DLTDL -I. -I. -I.. -I. -I. -I./libltdl -g -c -MD loaders/dlopen.c -o dlopen.o /dev/null 21 /bin/ksh ../libtool --tag=CC --mode=link cc -g -module -avoid-version -o dlopen.la dlopen.lo ../libtool[24]: invalid multibyte character ../libtool[6]: invalid multibyte character ../libtool[2312]: invalid multibyte character libtool: link: invalid operation mode `link' libtool: link: Try `libtool --help --mode=link' for more information. ../libtool[7679]: invalid multibyte character ../libtool[7679]: invalid multibyte character ../libtool[7679]: invalid multibyte character [...] ../libtool[7679]: invalid multibyte character ../libtool[7679]: invalid multibyte character gmake[3]: *** [dlopen.la] Segmentation fault gmake[3]: Leaving directory `/home/njoly/temp/libtool/libltdl' gmake[2]: *** [all] Error 2 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Problem on Windows
On Thu, 2005-06-02 at 16:13 +0100, Martyn Russell wrote: Hi, I am currently having problems linking in libpq (Postgres client front end) from PostgreSQL 8.0.2. I downloaded the source and installed it under MSYS/MinGW (to /usr/local). The .dll and the .a are in /usr/local/pgsql/lib. I have tried using -L/usr/local/pgsql/lib -lpq but it fails miserably, I get the following: *** Warning: linker path does not have real file for library -lpq. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libpq and none of the candidates passed a file format test *** using a file magic. Last file checked: C:/msys/1.0/local/pgsql/lib/libpq.dll *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. OK, just thought I would post my progress on this. Basically, the reason it didn't work is because I needed the AC_LIBTOOL_DLOPEN macro defined. With this added, all seems to work well. Is this right/wrong? If right, why? I saw this when trying to link with the Winsock2 library (-lws2_32) before now and decided to try and update libtool from 1.4.x to 1.5.18. It worked perfectly especially now I make use of the automatic import/export feature in gcc, however, this doesn't work for libpq? This was a problem with environment and different versions of libtool, etc. My mistake :) The only other detail I have noticed about libpq.dll is that the file format is pe-i386 and my libraries and the Winsock2 library is of format pei-i386. Does this have an impact on my problem? I am interested in the differences between a pe-i386 format and a pei- i386 are, plus if there are any issues mixing and matching libraries and executables of different types? So basically, I have got it all running. The only other issue I had was using libltdl within a library. For some reason, the symbols were not exported properly so I couldn't link with it. The symbols that were in the library were specifically libltdl functions? -- Regards, Martyn ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Problem on Windows
Hi Martyn, * Martyn Russell wrote on Tue, Jun 07, 2005 at 12:52:44PM CEST: On Thu, 2005-06-02 at 16:13 +0100, Martyn Russell wrote: I am currently having problems linking in libpq (Postgres client front end) from PostgreSQL 8.0.2. I downloaded the source and installed it under MSYS/MinGW (to /usr/local). The .dll and the .a are in /usr/local/pgsql/lib. I have tried using -L/usr/local/pgsql/lib -lpq but it fails miserably, I get the following: *** Warning: linker path does not have real file for library -lpq. *snip* *** using a file magic. Last file checked: C:/msys/1.0/local/pgsql/lib/libpq.dll *snip* OK, just thought I would post my progress on this. Great! Basically, the reason it didn't work is because I needed the AC_LIBTOOL_DLOPEN macro defined. With this added, all seems to work well. Is this right/wrong? If right, why? Docs state that you need this (for 1.5.18). Does that suffice for an answer? For newer branches you should add the `dlopen' option to LT_INIT: LT_INIT([dlopen]) I saw this when trying to link with the Winsock2 library (-lws2_32) before now and decided to try and update libtool from 1.4.x to 1.5.18. It worked perfectly especially now I make use of the automatic import/export feature in gcc, however, this doesn't work for libpq? This was a problem with environment and different versions of libtool, etc. My mistake :) So that works now? The only other detail I have noticed about libpq.dll is that the file format is pe-i386 and my libraries and the Winsock2 library is of format pei-i386. Does this have an impact on my problem? I am interested in the differences between a pe-i386 format and a pei- i386 are, plus if there are any issues mixing and matching libraries and executables of different types? Should be documented with GNU ld. I haven't had the chance to dive in there yet, though. So basically, I have got it all running. The only other issue I had was using libltdl within a library. For some reason, the symbols were not exported properly so I couldn't link with it. The symbols that were in the library were specifically libltdl functions? Using libltdl from within a library is supported only starting with branch-2-0, not with branch-1-5. There are known problems that manifest themselves (at least) on MinGW, though (less on cygwin). The recent archives of this and the libtool-patches mailing list have details. Work on this is always welcome. :) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Tue, Jun 07, 2005 at 12:35:00PM +0200, Ralf Wildenhues wrote:
* Nicolas Joly wrote on Tue, Jun 07, 2005 at 12:10:47PM CEST:
On Sun, Jun 05, 2005 at 07:38:59PM +0200, Ralf Wildenhues wrote:
CONFIG_SHELL=/bin/foosh /bin/foosh path/to/configure [OPTIONS..]
and you should provide an echo which does not interpret backslashes
(one of `echo', `/bin/echo', `print -r', `printf %s\\n' should usually
do).
In the mean time, i tested the solution where `print -r' and `ksh'
tests are swapped (attached patch). It seems to go a little further
(no more `print' error messages), but seems to fail in another ksh
problem/bug :
Please rerun the libtool command line with --debug and post output,
you may pack (gzip, bzip2).
libtool.dbg.bz2 attached.
Regards.
NB: Attached the patch forgotten in previous email too :-(
--
Nicolas Joly
Biological Software and Databanks.
Institut Pasteur, Paris.
libtool.dbg.bz2
Description: Binary data
Index: m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
retrieving revision 1.194
diff -u -r1.194 libtool.m4
--- m4/libtool.m4 6 Jun 2005 16:12:53 - 1.194
+++ m4/libtool.m4 7 Jun 2005 09:41:26 -
@@ -818,19 +818,19 @@
if test X$ECHO = Xecho; then
# We didn't find a better echo, so look for alternatives.
- if test X`{ print -r '\t'; } 2/dev/null` = 'X\t'
- echo_testing_string=`{ print -r $echo_test_string; } 2/dev/null`
- test X$echo_testing_string = X$echo_test_string; then
-# This shell has a builtin print -r that does the trick.
-ECHO='print -r'
- elif { test -f /bin/ksh || test -f /bin/ksh$ac_exeext; }
- test X$CONFIG_SHELL != X/bin/ksh; then
+ if { test -f /bin/ksh || test -f /bin/ksh$ac_exeext; }
+ test X$CONFIG_SHELL != X/bin/ksh; then
# If we have ksh, try running configure again with it.
ORIGINAL_CONFIG_SHELL=${CONFIG_SHELL-/bin/sh}
export ORIGINAL_CONFIG_SHELL
CONFIG_SHELL=/bin/ksh
export CONFIG_SHELL
exec $CONFIG_SHELL [$]0 --no-reexec ${1+[$]@}
+ elif test X`{ print -r '\t'; } 2/dev/null` = 'X\t'
+ echo_testing_string=`{ print -r $echo_test_string; } 2/dev/null`
+ test X$echo_testing_string = X$echo_test_string; then
+# This shell has a builtin print -r that does the trick.
+ECHO='print -r'
else
# Try using printf.
ECHO='printf %s\n'
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Problem on Windows
Hi Martyn, Please keep the mailing list copied, thank you. * Martyn Russell wrote on Tue, Jun 07, 2005 at 01:58:18PM CEST: On Tue, 2005-06-07 at 13:33 +0200, Ralf Wildenhues wrote: Basically, the reason it didn't work is because I needed the AC_LIBTOOL_DLOPEN macro defined. With this added, all seems to work well. Is this right/wrong? If right, why? Docs state that you need this (for 1.5.18). Does that suffice for an answer? For newer branches you should add the `dlopen' option to LT_INIT: LT_INIT([dlopen]) Mmm, not seen this used before in any configure script, is this a specific libtool function added to m4 scripts like acinclude.m4? Oh, I should have explained a little more verbosely: For 1.5.x, you put AC_LIBTOOL_DLOPEN AC_PROG_LIBTOOL in your configure.ac (or whereever else they are now). For branch-2-0, all the macro naming has been cleaned up an unified. Instead of above two lines you now write LT_INIT([dlopen]) If you has used only the AC_PROG_LIBTOOL line, running `autoupdate' should have changed that automatically to LT_INIT. autoupdate cannot do the second step alone, it will warn you that you need to do that yourself. OK? This was a problem with environment and different versions of libtool, etc. My mistake :) So that works now? End to end, all the software is working perfectly, thanks. Great. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
* Nicolas Joly wrote on Tue, Jun 07, 2005 at 01:27:25PM CEST: On Tue, Jun 07, 2005 at 12:35:00PM +0200, Ralf Wildenhues wrote: * Nicolas Joly wrote on Tue, Jun 07, 2005 at 12:10:47PM CEST: In the mean time, i tested the solution where `print -r' and `ksh' tests are swapped (attached patch). It seems to go a little further (no more `print' error messages), but seems to fail in another ksh problem/bug : [ which ends in a segmentation fault. ] Please rerun the libtool command line with --debug and post output, you may pack (gzip, bzip2). libtool.dbg.bz2 attached. OK, let's cut this testing a little short. It seems that Tru64 fails to provide any decent kind of shell for its users. I consider just putting a note about Tru64 into README (branch-1-5) resp. doc/notes.texi (HEAD). Proposal would be one of the following (whichever works and passes the test suite): | Note that Tru64 V5.1B ksh has some bugs which make it hardly useable for | libtoolized packages. Please set | BIN_SH=xpg4; export BIN_SH | in your environment for configuring and building. | Note that Tru64 V5.1B ksh has some bugs which make it hardly useable for | libtoolized packages. Please set | lt_ECHO='printf %s\\n'; export lt_ECHO | in your environment for configuring and building. (s/lt_ECHO/ECHO/g for branch-1-5). What do you think? Which one? Could one of the Tru64 users be bothered to send a bug report to HP? Regards, and thanks for all your testing, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
$BBg?M$NJ}$X(B
$B%([EMAIL PROTECTED]1|MM$H$N5U!{8r:]!=c?h$JK\5$$NNx0$r5a$a$kJ}!(B
$B=O$J1|%5%^!?'9aN)$Dc:J$O$b$A$m$s!F|K\Cf$N4{:'[EMAIL PROTECTED],ITNQ8r:](B
$BAjj$r5a$a$FEv%5%$%H$r$4MxMQ$5$l$F$*$j$^$9!#(B
$B---(B
$B!!(Bhttp://live.livedear.com/?num=love
$B!!M6$o$l$k$?$a$KEPO?$J$5$l$F$$$k$N$GM6$$$d$9$$$O$:$G$9!#(B
[EMAIL PROTECTED]!9$Jc$$=w$N;R$+$iM_5aITK~$N1|MM$^$G!$$J$?!Bh$G(B
$B=P2q$$J|[EMAIL PROTECTED],B?$9$.$F=w$N;R$KAjj$K$5$l$J$$L5NA%5%$%H$h$j(B
$B$o$:$+$JEj;[EMAIL PROTECTED]:%C%]%7%2%C%H!*(B
$BEPO?L5NA!B`2q+M3$G0B?4$N%7%9%F%`(B
$BEPO?$7$FMM;R$r8+$F$9$0$d$a$F$b#O#K$G$9!*%j%9%/[EMAIL PROTECTED]$j$^$;$s!#(B
$B---(B
$B!!(Bhttp://live.livedear.com/?num=love
---
$B:[EMAIL PROTECTED],5^A}$7$F$$$k0Y![EMAIL PROTECTED]'%C%/(B
$B$r9T$o$;$FD:$-LdBj$,5/$-$K$/$$4D6-$r;V$7$F$*$j$^$9!#(B
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure
On Tue, Jun 07, 2005 at 03:31:22PM +0200, Ralf Wildenhues wrote: * Nicolas Joly wrote on Tue, Jun 07, 2005 at 01:27:25PM CEST: On Tue, Jun 07, 2005 at 12:35:00PM +0200, Ralf Wildenhues wrote: * Nicolas Joly wrote on Tue, Jun 07, 2005 at 12:10:47PM CEST: In the mean time, i tested the solution where `print -r' and `ksh' tests are swapped (attached patch). It seems to go a little further (no more `print' error messages), but seems to fail in another ksh problem/bug : [ which ends in a segmentation fault. ] Please rerun the libtool command line with --debug and post output, you may pack (gzip, bzip2). libtool.dbg.bz2 attached. OK, let's cut this testing a little short. It seems that Tru64 fails to provide any decent kind of shell for its users. I consider just putting a note about Tru64 into README (branch-1-5) resp. doc/notes.texi (HEAD). Proposal would be one of the following (whichever works and passes the test suite): | Note that Tru64 V5.1B ksh has some bugs which make it hardly useable for | libtoolized packages. Please set | BIN_SH=xpg4; export BIN_SH | in your environment for configuring and building. This one does not work ... It will solve the `print' problem, but will lead to the shell crash a little later. with `BIN_SH=xpg4' set, `/usr/bin/posix/sh' is executed instead of the classic `/bin/sh'; and, unfortunately, this is a hard link to `ksh'. [EMAIL PROTECTED] [~] ls -ldi /usr/bin/posix/sh /usr/bin/ksh 482 -rwxr-xr-x 2 bin bin 307248 Oct 16 2002 /usr/bin/ksh 482 -rwxr-xr-x 2 bin bin 307248 Oct 16 2002 /usr/bin/posix/sh | Note that Tru64 V5.1B ksh has some bugs which make it hardly useable for | libtoolized packages. Please set | lt_ECHO='printf %s\\n'; export lt_ECHO | in your environment for configuring and building. (s/lt_ECHO/ECHO/g for branch-1-5). Will test, and report. What do you think? Which one? Could one of the Tru64 users be bothered to send a bug report to HP? Sorry i can't. Our sysadmins tried to have a software support contract from Digital/Compaq for many years, but didn't get any succes ! They give up when HP came up ... -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris. ___ http://lists.gnu.org/mailman/listinfo/libtool
g++ is not used by libtool
Hi, I'm trying to compile fam-2.6.10 from ftp://oss.sgi.com/projects/fam/download/stable/fam-2.6.10.tar.gz The problem is that fam is a C++ library and libtool is not capable of C++. In the linking step the following command is issued: /bin/sh ../libtool --mode=link g++ -g -O2 -o libfam.la -rpath /usr/local/lib -export-symbols fam.sym Client.lo fam.lo -lstdc++ libtool translates this to several commands and this one: gcc -shared Client.lo fam.lo /usr/lib/libstdc++.so -Wl,-soname -Wl,libfam.so.0 -Wl,-retain-symbols-file -Wl,fam.sym -o .libs/libfam.so.0.0.0 Why is not g++ called? Why is /usr/lib/libstdc++.so added to the command line? The correct command line would be: g++ -shared Client.lo fam.lo -Wl,-soname -Wl,libfam.so.0 -Wl,-retain-symbols-file -Wl,fam.sym -o .libs/libfam.so.0.0.0 How can I achieve that g++ is called and not gcc? And how to get rid of /usr/lib/libstdc++.so correctly? I've found the line libfam_la_LIBADD = -lstdc++ in Makefile.in. I guess the fam developers added this line, because libtool was not able to use g++ and they could not figure out how to change this situation. When I remove this line. libtool is not called with -lstdc++ which is also correct, but libtool itself still calls gcc. How to resolve this situation? Christoph Bartoschek ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: g++ is not used by libtool
Hi Christoph, * Christoph Bartoschek wrote on Tue, Jun 07, 2005 at 08:57:26PM CEST: I'm trying to compile fam-2.6.10 from ftp://oss.sgi.com/projects/fam/download/stable/fam-2.6.10.tar.gz The problem is that fam is a C++ library and libtool is not capable of C++. Libtool /is/ capable of C++. /bin/sh ../libtool --mode=link g++ -g -O2 -o libfam.la -rpath /usr/local/lib -export-symbols fam.sym Client.lo fam.lo -lstdc++ libtool translates this to several commands and this one: gcc -shared Client.lo fam.lo /usr/lib/libstdc++.so -Wl,-soname -Wl,libfam.so.0 -Wl,-retain-symbols-file -Wl,fam.sym -o .libs/libfam.so.0.0.0 Why is not g++ called? Why is /usr/lib/libstdc++.so added to the command line? The correct command line would be: Several issues: First, the libtool that ships with the tarball is *ancient* (1.4, four years old). Tell them to update to a recent one. Second, at the time that libtool was current, it was actually deemed safer bet to link with gcc and add libstdc++ manually than link with g++. (Maybe the latter was even impossible, I don't know -- at the time of libtool-1.4 I did not have anything to do with it yet). How can I achieve that g++ is called and not gcc? And how to get rid of /usr/lib/libstdc++.so correctly? Tell the maintainers of that package to use an up to date libtool. Or update it yourself (1.5.18 is recent, you need to re-libtoolize for ltmain.sh and get aclocal to include the corresponding libtool.m4 into aclocal.m4). I've found the line libfam_la_LIBADD = -lstdc++ in Makefile.in. Delete that line. And while you're at it, replace AM_PROG_LIBTOOL with AC_PROG_LIBTOOL in configure.in. After all of this you should be set. Well, you won't, because the rest of the package is as unmaintained as the build infrastructure (the C++ standard conformance is rather, um, could be better). Are you sure there is not a more recent version of this package? Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: g++ is not used by libtool
Am Dienstag, 7. Juni 2005 21:31 schrieb Ralf Wildenhues: Hi Christoph, * Christoph Bartoschek wrote on Tue, Jun 07, 2005 at 08:57:26PM CEST: I'm trying to compile fam-2.6.10 from ftp://oss.sgi.com/projects/fam/download/stable/fam-2.6.10.tar.gz The problem is that fam is a C++ library and libtool is not capable of C++. Libtool /is/ capable of C++. Oh, I want to apologise for writing this sentence. Several issues: First, the libtool that ships with the tarball is *ancient* (1.4, four years old). Tell them to update to a recent one. Second, at the time that libtool was current, it was actually deemed safer bet to link with gcc and add libstdc++ manually than link with g++. (Maybe the latter was even impossible, I don't know -- at the time of libtool-1.4 I did not have anything to do with it yet). How can I achieve that g++ is called and not gcc? And how to get rid of /usr/lib/libstdc++.so correctly? Tell the maintainers of that package to use an up to date libtool. Or update it yourself (1.5.18 is recent, you need to re-libtoolize for ltmain.sh and get aclocal to include the corresponding libtool.m4 into aclocal.m4). Is this easy to do? I guess I have to read libtools documentations. I've found the line libfam_la_LIBADD = -lstdc++ in Makefile.in. Delete that line. And while you're at it, replace AM_PROG_LIBTOOL with AC_PROG_LIBTOOL in configure.in. After all of this you should be set. Well, you won't, because the rest of the package is as unmaintained as the build infrastructure (the C++ standard conformance is rather, um, could be better). Are you sure there is not a more recent version of this package? Regards, Ralf There is a more recent version ftp://oss.sgi.com/projects/fam/download/stable/fam-2.7.0.tar.gz. But it also has the same problems, although it is from 2003. I would like to omit this package, but KDE somehow depends on it and their libtool finds /usr/lib/libstdc++.la, if I do not provide my own version. But I have to prevent that any package uses /usr/lib/libstdc++.so. Thanks, Christoph ___ http://lists.gnu.org/mailman/listinfo/libtool
Say goodbye to pain
The New Breakthrough of The Antidote PROVEN FORMULA Not available in any retail outlet - To Learn More please follow: http://www.lyfdad.us/sev Ships direct from the medical research facility. Kills all Known Viruses Bacteria kept in the body as diseases before they attack. *Common flus/colds *Influenza *SARS *Cancer *HIV *Etc. The Antidote is the answer for virus/bacteria free-living. We are the only company in the world who have developed this product for sale. We're so confident you'll find it works that we offer a full-guarantee. To Learn More please follow: http://lyfdad.us/sev Sam ___ http://lists.gnu.org/mailman/listinfo/libtool
