libtool 1.5.14 on mingw: DLLs must be installed executable
Hi,
Using libtool 1.5.14 to install libiconv built for mingw, any program linked
against the such installed libiconv-2.dll crashes on startup with a dialog
box:
The application failed to initialize properly (0xc022)
The reason, as explained in
http://www.mail-archive.com/cygwin@cygwin.com/msg23724.html
is that libtool installs the DLL without the execution bit. Here is a fix.
2005-07-08 Bruno Haible <[EMAIL PROTECTED]>
* libtool.m4 (postinstall_cmds) [cygwin,mingw,pw32]: Make DLL
executable after installing it.
*** libtool.m4 19 May 2005 17:18:59 - 1.10
--- libtool.m4 8 Jul 2005 12:40:57 -
***
*** 1227,1233
dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i;echo
\$dlname'\''`~
dldir=$destdir/`dirname \$dlpath`~
test -d \$dldir || mkdir -p \$dldir~
! $install_prog $dir/$dlname \$dldir/$dlname'
postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; echo \$dlname'\''`~
dlpath=$dir/\$dldll~
$rm \$dlpath'
--- 1227,1234
dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i;echo
\$dlname'\''`~
dldir=$destdir/`dirname \$dlpath`~
test -d \$dldir || mkdir -p \$dldir~
! $install_prog $dir/$dlname \$dldir/$dlname~
! chmod a+x \$dldir/$dlname'
postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; echo \$dlname'\''`~
dlpath=$dir/\$dldll~
$rm \$dlpath'
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: new module 'ldd'
[redirected to bug-libtool, from bug-gnulib] Ralf Wildenhues wrote: > > The fact that a libtool created "program" is not actually a program but a > > script, is a problem of libtool. Fix that, then we can also use > > "gdb program" instead of the surprising syntax "libtool gdb program". > > Two comments: I have yet to see a proposal how uninstalled programs may > load uninstalled libraries on all systems, without using a wrapper of > some sort. Here is a proposal that works on glibc systems and possibly other systems: Create the uninstalled program in the current directory, with -rpath linker options that refer to directories containing uninstalled libraries. During installation "libtool --mode=install" will have to create a different executable, with different -rpath options. This works on glibc systems because the -rpath directories have precedence over the LD_LIBRARY_PATH directories. The most important Unix systems (Linux, Solaris, HP-UX, AIX, IRIX, OSF/1, FreeBSD, OpenBSD, NetBSD) all support -rpath or equivalent for executables. But on some the precedence is reversed, for example on IA64 HP-UX, the LD_LIBRARY_PATH is consulted before the embedded rpath. On these systems my proposal will not work. > Note on some systems (GNU/Linux/GCC for example) there is > a trade-off to make wrt. fast-install Being a developer, I'm asking to make the trade-offs in favour of the developer's comfort, i.e. optimized for "make", "gdb", and "make check", at the expense of a slower "make install" :-) > So, no, I don't acknowledge that as bug, but as (necessary) limitation. glibc systems are the platforms on which most of us are developing. Isn't it worth to optimize libtool for these platforms? > (Your unrelated issue about the last path component of argv[0] starting > with `lt-' is a different beast: it's a bug I'd like to fix eventually.) Thanks in advance! Bruno ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
support for SunPRO C/C++ on Linux
Hi,
Here is a patch that adds support for Sun's C and C++ compilers 5.9, ported
from Solaris to Linux. They exist for x86 and x86_64; I tested it only on x86.
The compiler executable for C is called 'c89' and 'c99' (two slightly
different programs); for C++ it is called 'CC'.
Without this patch, several tests fail:
PASS: cdemo-static.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-static.test
FAIL: demo-make.test
FAIL: demo-exec.test
FAIL: demo-inst.test
PASS: demo-unst.test
PASS: depdemo-static.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: mdemo-static.test
FAIL: mdemo-make.test
SKIP: mdemo-exec.test
SKIP: mdemo-inst.test
PASS: mdemo-unst.test
SKIP: cdemo-conf.test
SKIP: cdemo-make.test
SKIP: cdemo-exec.test
SKIP: demo-conf.test
SKIP: demo-make.test
SKIP: demo-exec.test
SKIP: demo-inst.test
SKIP: demo-unst.test
SKIP: deplibs.test
SKIP: depdemo-conf.test
SKIP: depdemo-make.test
SKIP: depdemo-exec.test
SKIP: depdemo-inst.test
SKIP: depdemo-unst.test
SKIP: mdemo-conf.test
SKIP: mdemo-make.test
SKIP: mdemo-exec.test
SKIP: mdemo-inst.test
SKIP: mdemo-unst.test
SKIP: dryrun.test
PASS: demo-nofast.test
FAIL: demo-make.test
FAIL: demo-exec.test
FAIL: demo-inst.test
PASS: demo-unst.test
PASS: demo-pic.test
FAIL: demo-make.test
FAIL: demo-exec.test
PASS: demo-nopic.test
FAIL: demo-make.test
FAIL: demo-exec.test
PASS: depdemo-nofast.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
SKIP: cdemo-shared.test
SKIP: cdemo-make.test
SKIP: cdemo-exec.test
SKIP: demo-shared.test
SKIP: demo-make.test
SKIP: demo-exec.test
SKIP: demo-inst.test
SKIP: hardcode.test
SKIP: build-relink.test
SKIP: noinst-link.test
SKIP: demo-unst.test
SKIP: depdemo-shared.test
SKIP: depdemo-make.test
SKIP: depdemo-exec.test
SKIP: depdemo-inst.test
SKIP: build-relink2.test
SKIP: depdemo-unst.test
SKIP: mdemo-shared.test
SKIP: mdemo-make.test
SKIP: mdemo-exec.test
SKIP: mdemo-inst.test
SKIP: mdemo-unst.test
PASS: assign.test
PASS: link.test
PASS: link-2.test
PASS: nomode.test
PASS: quote.test
PASS: sh.test
PASS: suffix.test
SKIP: pdemo-conf.test
SKIP: pdemo-make.test
SKIP: pdemo-exec.test
SKIP: pdemo-inst.test
SKIP: mdemo-conf.test
SKIP: mdemo-make.test
SKIP: mdemo2-conf.test
SKIP: mdemo2-make.test
SKIP: mdemo2-exec.test
PASS: duplicate_members.test
PASS: link-order.test
PASS: tagdemo-static.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
SKIP: tagdemo-conf.test
SKIP: tagdemo-make.test
SKIP: tagdemo-exec.test
SKIP: tagdemo-shared.test
SKIP: tagdemo-make.test
SKIP: tagdemo-exec.test
PASS: f77demo-static.test
PASS: f77demo-make.test
PASS: f77demo-exec.test
SKIP: f77demo-conf.test
SKIP: f77demo-make.test
SKIP: f77demo-exec.test
SKIP: f77demo-shared.test
SKIP: f77demo-make.test
SKIP: f77demo-exec.test
With this patch, the FAILs are turned into PASS; all tests PASS or SKIP.
Additionally, with the corresponding patch to config.rpath, the
autoconf-lib-link testsuite passes as well.
2006-05-05 Bruno Haible <[EMAIL PROTECTED]>
* libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG): Add support for Sun C++ 5.9
on Linux.
(AC_LIBTOOL_PROG_COMPILER_PIC): Add support for Sun C 5.9 and
Sun C++ 5.9.
(AC_LIBTOOL_PROG_LD_SHLIBS): Add support for Sun C 5.9.
*** libtool-1.5.22/libtool.m4.bak 2005-12-18 22:53:17.0 +0100
--- libtool-1.5.22/libtool.m4 2006-05-07 02:17:19.0 +0200
***
*** 3353,3358
--- 3353,3377
# dependencies.
output_verbose_link_cmd='templist=`$CC -shared $CFLAGS -v
conftest.$objext 2>&1 | grep "ld"`; templist=`echo $templist | $SED
"s/\(^.*ld.*\)\( .*ld .*$\)/\1/"`; list=""; for z in $templist; do case $z in
conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac;
done; echo $list'
;;
+ CC*)
+ # Sun C++ 5,9
+ _LT_AC_TAGVAR(no_undefined_flag, $1)=' -zdefs'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag}
-h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects
$compiler_flags'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G${allow_undefined_flag}
-h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects
$compiler_flags ${wl}-retain-symbols-file ${wl}$export_symbols'
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
+ _LT_AC_TAGVAR(whole_archive_flag_spec,
$1)='${wl}--whole-archive$convenience ${wl}--no-whole-archive'
+
+ # Not sure whether something based on
+ # $CC $CFLAGS -v conftest.$objext -o libconftest$shared_ext 2>&1
+ # would be better.
+ output_verbose_link_cmd='echo'
+
+ # Archives containing C++ object files must be created using
+ # "CC -xar", where "CC" is the
Re: support for SunPRO C/C++ on Linux
Hello Ralf, Thanks for the quick feedback. > > The compiler executable for C is called 'c89' and 'c99' (two slightly > > different programs); for C++ it is called 'CC'. > > How unfortunate. Several compilers on GNU/Linux install themselves with > links or wrappers named c89 or c99. I don't think all of them > understand -KPIC, and none of the others will understand '-Qoption ld'. > We should probably do a --version|-V test as well to disambiguate. Something like this, or test whether "$CC -flags > /dev/null" gives no error... Does the same hold also for the name 'CC' of the C++ compiler? I'll resend a new patch. Bruno ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: support for SunPRO C/C++ on Linux
Hello Ralf,
> Some notes:
> > *** 3353,3358
> > --- 3353,3379
> > # dependencies.
> > output_verbose_link_cmd='templist=`$CC -shared $CFLAGS -v
> > conftest.$objext 2>&1 | grep "ld"`; templist=`echo $templist | $SED
> > "s/\(^.*ld.*\)\( .*ld .*$\)/\1/"`; list=""; for z in $templist; do case
> > $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list
> > $z";;esac; done; echo $list' ;;
> > + *)
> > + if LC_ALL=C $CC -V 2>&1 | sed 1q | grep "Sun C" > /dev/null; then
>
> If that LC_ALL=C was really necessary, then that is a bug.
It may not be necessary within the context of a configure script. I put it
there because I tested the English output only, not the Japanese or Chinese
or Thai one... Had forgotten that autoconf already disables i18n.
> Any reason not to simplify this to something like this?
> case `$CC -V 2>&1 >/dev/null` in
> *Sun\ C*)
Yes. HP-UX /bin/sh is known to dump core in
case `command that produces more than 1 KB of output` in
and I don't know how much output other compilers generate when given the -V
option.
> > + _LT_AC_TAGVAR(whole_archive_flag_spec,
> > $1)='${wl}--whole-archive`new_convenience=; for conv in
> > +$convenience\"\"; do test -z \"$conv\" ||
> > new_convenience=\"$new_convenience,$conv\"; done; $echo
> > \"$new_convenience\"`+${wl}--no-whole-archive'
>
> Are you sure the compiler driver won't reorder arguments here?
I used this backquoted glue-with-commas construct precisely because the
compiler driver did reorder the arguments. Earlier I used
${wl}--whole-archive$convenience ${wl}--no-whole-archive
which had the effect of passing to the compiler driver flags like
-Wl,--whole-archive .libs/libfoo.a .libs/libbar.a -Wl,--no-whole-archive
and the compiler driver passed these options to the linker:
--whole-archive --no-whole-archive .libs/libfoo.a .libs/libbar.a
The patch I submitted now passes to the compiler driver flags
-Wl,--whole-archive,.libs/libfoo.a,.libs/libbar.a -Wl,--no-whole-archive
and the linker gets these options:
--whole-archive .libs/libfoo.a .libs/libbar.a --no-whole-archive
So in general this should make --whole-archive actually work.
The only drawback of this approach is if no other object file is used, i.e.
the whole contents to be linked is inside --whole-archive, the compiler driver
refuses to do the link because it complains about no object files to link.
I don't know if it is a real use-case of libtool; if so, probably a fix could
be to add $convenience at the end of whole_archive_flag_spec, so that the
compiler sees the libraries too. (The linker would then see them twice, the
first time with --whole-archive, the second time without. That should be ok,
I hope?)
> only the CVS HEAD
> Libtool testsuite exposes the known failures fully.
Do you have two test cases, one for a whole library plus some other objects,
and one for two libraries and no other objects?
> Related question:
> are you volunteering for the forward-port of the patch? (If not, I can
> do it, but it'll take longer then.)
No. Generally I submit patches relative to the latest release. Everything
beyond that is IMO the maintainer's job. (I hope that this attitude will
convince some people to make releases more frequently ;-)).
> Do you happen to know whether Sun changed their minds and offered this
> compiler suite for free (as in beer) now? So that I could integrate it
> into testing..
Yes, it is available for download at
http://developers.sun.com/prodtech/cc/downloads/tech_preview.jsp
and they distributed copies of it at LinuxTag a week ago. But I have no idea
whether the compilers will stay zero-cost when they are out of beta.
Bruno
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: support for SunPRO C/C++ on Linux
Ralf Wildenhues wrote:
> > Yes. HP-UX /bin/sh is known to dump core in
> >
> > case `command that produces more than 1 KB of output` in
> >
> > and I don't know how much output other compilers generate when given the
> > -V option.
>
> But say, why is that HP-UX shell issue not listed in the Autoconf
> portability section? FWIW, I can't reproduce it on some HP-UX systems;
> the oldest I have access to is an HP-UX 10.20.
Then it must be have been in HP-UX 9 (which was in use around 1992 to 1996).
It'd be good to know
> about the impact of this -- do you have pointers to bug reports? (Also
> note that the shell selection algorithm of Autoconf-2.59c will select
> /usr/bin/posix/sh there.)
>
> > > > + _LT_AC_TAGVAR(whole_archive_flag_spec,
> > > > $1)='${wl}--whole-archive`new_convenience=; for conv in
> > > > +$convenience\"\"; do test -z \"$conv\" ||
> > > > new_convenience=\"$new_convenience,$conv\"; done; $echo
> > > > \"$new_convenience\"`+${wl}--no-whole-archive'
> > >
> > > Are you sure the compiler driver won't reorder arguments here?
> >
> > ...
>
> IIRC, on Solaris, this:
> | _LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}-z ${wl}allextract`for conv
> | in $convenience\"\"; do test -n \"$conv\" &&
> | new_convenience=\"$new_convenience,$conv\"; done; $echo
> | \"$new_convenience\"` ${wl}-z ${wl}defaultextract'
>
> caused some problems somewhere; cf. for example this thread:
> http://lists.gnu.org/archive/html/bug-libtool/2005-10/msg00040.html
> and note that with C++, your patch sets ${wl} to `-Qoption ld ' as well,
> not to `-Wl,'.
>
> Also, consider this: in a (maybe partially) static linking case, the
> objects from the convenience archive require some symbol from a library
> specified later. If the driver reorders, we may be out of luck here, as
> the needed library may happen to end up listed earlier. OTOH, the
> driver on Solaris knows '-z allextract' and understands what to do with
> the following arguments. So that had a chance of actually working
> across Solaris versions (the driver happens to also reorder differently
> across versions).
>
> Now, if the driver understands --whole-archive/--no-whole-archive on
> GNU/Linux, I think that should be used plainly, without ${wl}. If it
> doesn't, then, depending on how it reorders, we should file a bug
> report.
Sun C on Linux appears to put linker options first, before the object files
to be linked; therefore the needed libraries will come later - no problem.
Bruno
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: support for SunPRO C/C++ on Linux
Ralf Wildenhues wrote:
> and note that with C++, your patch sets ${wl} to `-Qoption ld ' as well,
> not to `-Wl,'.
Yes. Indeed I don't know whether -Qoption ld arg1,arg2,arg3will
pass arg1, arg2, arg3 separately to the linker or glued together. I hope
the tests in libtool HEAD will detect whether this makes problems.
Bruno
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
hardcode_direct_absolute description
Hi,
Albert Chin-A-Young pointed me to this description of hardcode_direct_absolute
in the libtool CVS:
_LT_TAGDECL([], [hardcode_direct_absolute], [0],
[Set to "yes" if using DIR/libNAME${shared_ext} during linking hardcodes
DIR into the resulting binary and the resulting library dependency is
"absolute", i.e impossible to change by setting ${shlibpath_var} if the
library is relocated])
The phrase "hardcodes DIR into the resulting binary" is misleading, because
1) This hardcoding affects only the given library dependency, not other
library dependencies. See execution trace below. In other words, it hardcodes
the file name DIR/libNAME${shared_ext} in the resulting binary.
2) If DIR is a relative pathname, it is first made absolute before being
hardcoded in the binary. In other words, it's not DIR/libNAME${shared_ext}
which is hardcoded, but `cd DIR && pwd`/libNAME${shared_ext}.
I would therefore suggest to change this description to
_LT_TAGDECL([], [hardcode_direct_absolute], [0],
[Set to "yes" if using DIR/libNAME${shared_ext} during linking hardcodes
the absolute filename `cd DIR && pwd`/libNAME${shared_ext} into the
resulting
binary and the resulting library dependency is "absolute", i.e impossible to
change by setting ${shlibpath_var} if the library is relocated])
Bruno
== execution log on HP-UX 11 ==
$ ls -l hplibs*/*
lrwxrwxrwx 1 haible13 May 23 20:00 hplibs1/libiconv.sl ->
libiconv.sl.3
-r-xr-xr-x 1 haible996057 Feb 19 2003 hplibs1/libiconv.sl.3
lrwxrwxrwx 1 haible12 May 23 20:00 hplibs2/libintl.sl ->
libintl.sl.7
-r-xr-xr-x 1 haible 61723 Feb 12 2005 hplibs2/libintl.sl.7
$ cc hello.c hplibs1/libiconv.sl.3 -Lhplibs2 -lintl
$ chatr a.out
...
shared library list:
static/home/haible/hplibs1/libiconv.sl.3
dynamic hplibs2/libintl.sl.7
dynamic /usr/lib/libc.2
...
$ mv hplibs2/libintl.sl* hplibs1/
$ chatr a.out
...
shared library list:
static/home/haible/hplibs1/libiconv.sl.3
dynamic hplibs2/libintl.sl.7
dynamic /usr/lib/libc.2
...
$ ./a.out
/usr/lib/dld.sl: Can't open shared library: hplibs2/libintl.sl.7
/usr/lib/dld.sl: No such file or directory
ABORT instruction
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: hardcode_direct_absolute description
Albert Chin-A-Young wrote:
> > 2) If DIR is a relative pathname, it is first made absolute before being
> >hardcoded in the binary. In other words, it's not
> > DIR/libNAME${shared_ext} which is hardcoded, but `cd DIR &&
> > pwd`/libNAME${shared_ext}.
>
> Really?
> $ cc a.c /opt/TWWfsw/zlib11/lib/../lib/libz.sl
> $ chatr a.out
> ...
> shared library list:
> static/opt/TWWfsw/zlib11/lib/../lib/libz.sl.2
> dynamic /usr/lib/libc.2
> ...
OK, you got me. I only meant to say that if DIR is not an absolute pathname,
the current directrory is prepended. As you point out, ".." (and probably
symlinks too) are apparently not resolved at link time.
Bruno
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: strings.h in argz.c?
Simon Josefsson wrote: > I assume that memory.h is a side-effect of using strings.h, and that > memory.h is not needed today either? Yes. Even on older systems like Solaris 2.4, AIX 4.3, IRIX 6.5, HP-UX 11, OSF/1 4.0, the contents of is also available through . Bruno ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
libtool makes it hard to create multithreaded programs on HP-UX
Hi, A special "feature" in libtool 1.5.24 is making some multithreaded programs nonfunctional on HP-UX 11.00. To reproduce: Get and unpack http://www.haible.de/bruno/gnu/gettext-0.16.2-pre6.tar.gz . $ export PATH=/usr/bin:$PATH $ export CC="cc -Ae" CXX="aCC" $ cd gettext-0.16.2-pre6 $ ./configure $ make $ cd gettext-tools/gnulib-tests $ make test-lock source='test-lock.c' object='test-lock.o' libtool=no \ DEPDIR=.deps depmode=hp /bin/sh ../../build-aux/depcomp \ cc -Ae -DHAVE_CONFIG_H -I. -I.. -I. -I. -I.. -I./.. -I../gnulib-lib -I./../gnulib-lib-g -c test-lock.c /bin/sh ../libtool --tag=CC--mode=link cc -Ae -g-o test-lock test-lock.o ../gnulib-lib/libgettextlib.la -lpthread -lrt mkdir .libs chmod 777 .libs libtool: link: warning: this platform does not like uninstalled shared libraries libtool: link: `test-lock' will be relinked during installation cc -Ae -g -o .libs/test-lock test-lock.o ../gnulib-lib/.libs/libgettextlib.sl /udd/marceau/gettext-0.16.2-pre6/gettext-tools/intl/.libs/libintl.sl -lc -lcurses -lpthread -lrt -Wl,+b -Wl,/udd/marceau/gettext-0.16.2-pre6/gettext-tools/gnulib-lib/.libs:/udd/marceau/gettext-0.16.2-pre6/gettext-tools/intl/.libs:/usr/local/lib creating test-lock $ ./test-lock Starting test_lock ...ABORT instruction The problem is that pthread_create() returns ENOSYS instead of creating a thread and returning 0. [1] explains that pthread_create is only a stub in libc, and well defined in libpthread. If a program is linked with "-lc -lpthread", the stub in libc will take precedence. If a program is linked with just "-lpthread", or with "-lpthread -lc", the well defined function in libpthread takes precedence. test-lock was created like this: /bin/sh ../libtool --tag=CC--mode=link cc -Ae -g-o test-lock \ test-lock.o ../gnulib-lib/libgettextlib.la -lpthread -lrt So I try to put the -lpthread once before and once after libgettextlib.la: $ /bin/sh ../libtool --tag=CC--mode=link cc -Ae -g-o test-lock \ test-lock.o -lpthread ../gnulib-lib/libgettextlib.la -lpthread -lrt libtool: link: warning: this platform does not like uninstalled shared libraries libtool: link: `test-lock' will be relinked during installation cc -Ae -g -o .libs/test-lock test-lock.o ../gnulib-lib/.libs/libgettextlib.sl /udd/marceau/gettext-0.16.2-pre6/gettext-tools/intl/.libs/libintl.sl -lc -lcurses -lpthread -lrt -Wl,+b -Wl,/udd/marceau/gettext-0.16.2-pre6/gettext-tools/gnulib-lib/.libs:/udd/marceau/gettext-0.16.2-pre6/gettext-tools/intl/.libs:/usr/local/lib creating test-lock $ ./test-lock Starting test_lock ...ABORT instruction As you can see, this had no effect on the cc command line: libtool has moved the -lpthread so that it comes after -lc. So I try to create the test-lock program differently, bypassing libtool: $ cc -Ae -g -o .libs/test-lock test-lock.o ../gnulib-lib/.libs/libgettextlib.sl /udd/marceau/gettext-0.16.2-pre6/gettext-tools/intl/.libs/libintl.sl -lpthread -lc -lcurses -lrt -Wl,+b -Wl,/udd/marceau/gettext-0.16.2-pre6/gettext-tools/gnulib-lib/.libs:/udd/marceau/gettext-0.16.2-pre6/gettext-tools/intl/.libs:/usr/local/lib $ ./test-lock Starting test_lock ... OK Starting test_rwlock ... OK Starting test_recursive_lock ... OK Starting test_once ... OK Conclusion: libtool's positioning of -lc before -lpthread causes the problem. The -lc actually comes from the libintl library: It is created through /bin/sh ../libtool --mode=link cc -Ae -g-o libintl.la gettext.lo ... \ -lc -version-info 8:1:0 -rpath /usr/local/lib -no-undefined and without the "-lc" the -no-undefined option causes an error on many platforms. The value of build_libtool_need_lc is irrelevant for this issue. I can solve the problem by omitting the -lc from the libtool command line for libintl (specially for HP-UX). But why is libtool reordering my link specifications at all? Bruno [1] http://docs.hp.com/en/1896/pthreads.html ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
libtool runs compiler command in wrong locale
Hi,
I have my environment variables set to German (LANG=de_DE.UTF-8), and
nevertheless the gcc compiler emits its warnings in English *if* invoked
by libtool.
Example (when compiling CLN-1.2.0):
$ /bin/sh ../libtool --mode=compile g++ -g -O2 -Wall -I../include -I../include
-I./base -c ./base/cl_as_exception.cc
g++ -g -O2 -Wall -I../include -I../include -I./base -c
./base/cl_as_exception.cc -fPIC -DPIC -o .libs/cl_as_exception.o
In file included from ./base/cl_N.h:6,
from ./base/cl_as_exception.cc:13:
../include/cln/number.h: In constructor 'cln::cl_number::cl_number(float)':
../include/cln/number.h:238: warning: type-punning to incomplete type might
break strict-aliasing rules
../include/cln/number.h: In member function 'cln::cl_number&
cln::cl_number::operator=(float)':
../include/cln/number.h:238: warning: type-punning to incomplete type might
break strict-aliasing rules
../include/cln/number.h: In constructor 'cln::cl_number::cl_number(double)':
../include/cln/number.h:239: warning: type-punning to incomplete type might
break strict-aliasing rules
../include/cln/number.h: In member function 'cln::cl_number&
cln::cl_number::operator=(double)':
../include/cln/number.h:239: warning: type-punning to incomplete type might
break strict-aliasing rules
g++ -g -O2 -Wall -I../include -I../include -I./base -c
./base/cl_as_exception.cc -o cl_as_exception.o >/dev/null 2>&1
But just copying the shown command into a shell prompt yields the warnings
in English:
$ g++ -g -O2 -Wall -I../include -I../include -I./base -c
./base/cl_as_exception.cc -fPIC -DPIC -o .libs/cl_as_exception.o
In file included from ./base/cl_N.h:6,
from ./base/cl_as_exception.cc:13:
../include/cln/number.h: In constructor »cln::cl_number::cl_number(float)«:
../include/cln/number.h:238: Warnung: Type-Punning auf unvollständigen Typen
kann strict-aliasing-Regeln verletzen
../include/cln/number.h: In member function »cln::cl_number&
cln::cl_number::operator=(float)«:
../include/cln/number.h:238: Warnung: Type-Punning auf unvollständigen Typen
kann strict-aliasing-Regeln verletzen
../include/cln/number.h: In constructor »cln::cl_number::cl_number(double)«:
../include/cln/number.h:239: Warnung: Type-Punning auf unvollständigen Typen
kann strict-aliasing-Regeln verletzen
../include/cln/number.h: In member function »cln::cl_number&
cln::cl_number::operator=(double)«:
../include/cln/number.h:239: Warnung: Type-Punning auf unvollständigen Typen
kann strict-aliasing-Regeln verletzen
Find attached a patch for it, relative to libtool-1.5.24 (tested),
and a tentative patch relative to the libtool CVS (untested).
Note that $ltenv can only be applied to commands that run a program, not to
shell builtins like "eval ..." or "(cd ... && ...)".
Bruno
2008-01-20 Bruno Haible <[EMAIL PROTECTED]>
* ltmain.in (lt_env): New variable. Use it when running commands.
*** ltmain.in.bak 2007-06-24 03:30:51.0 +0200
--- ltmain.in 2008-01-20 17:11:15.0 +0100
***
*** 113,126
--- 113,131
# These must not be set unconditionally because not all systems understand
# e.g. LANG=C (notably SCO).
# We save the old values to restore during execute mode.
+ lt_env=
for lt_var in LANG LC_ALL LC_CTYPE LC_COLLATE LC_MESSAGES
do
eval "if test \"\${$lt_var+set}\" = set; then
save_$lt_var=\$$lt_var
+ lt_env=\"$lt_var=\$$lt_var \$lt_env\"
$lt_var=C
export $lt_var
fi"
done
+ if test -n "$lt_env"; then
+ lt_env="env $lt_env"
+ fi
# Make sure IFS has a sensible default
lt_nl='
***
*** 956,962
$run $rm "$lobj" "$output_obj"
$show "$command"
! if $run eval "$command"; then :
else
test -n "$output_obj" && $run $rm $removelist
exit $EXIT_FAILURE
--- 961,967
$run $rm "$lobj" "$output_obj"
$show "$command"
! if $run eval $lt_env "$command"; then :
else
test -n "$output_obj" && $run $rm $removelist
exit $EXIT_FAILURE
***
*** 1028,1034
command="$command$suppress_output"
$run $rm "$obj" "$output_obj"
$show "$command"
! if $run eval "$command"; then :
else
$run $rm $removelist
exit $EXIT_FAILURE
--- 1033,1039
command="$command$suppress_output"
$run $rm "$obj" "$output_obj"
$show "$command"
! if $run eval $lt_env "$command"; then :
else
$run $rm $removelist
exit $EXIT_FAILURE
2008-01-20 Bruno Haible <[EMAIL PROTECTED]>
* libltdl/config/ltmain.m4sh (lt_env): New variable.
* libltd
Re: libtool runs compiler command in wrong locale
Ralf Wildenhues wrote:
> func_show_eval is also called like this:
>
> | func_show_eval '( cd "$output_objdir" && $RM "$outputname" && $LN_S
> "../$outputname" "$outputname" )' 'exit $?'
OK, what about this patch, then? (Untested.)
Bruno
2008-01-20 Bruno Haible <[EMAIL PROTECTED]>
* libltdl/config/ltmain.m4sh (lt_switch_to_user_locale,
lt_switch_to_safe_locale): New variables.
* libltdl/config/general.m4sh (func_show_eval): Use them.
*** libltdl/config/general.m4sh.bak 2008-01-20 17:22:16.0 +0100
--- libltdl/config/general.m4sh 2008-01-21 00:41:49.0 +0100
***
*** 1,6
m4_if([general.m4sh -- general shell script boiler plate -*- Autoconf -*-
!Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
Written by Gary V. Vaughan, 2004
This file is part of GNU Cvs-utils.
--- 1,6
m4_if([general.m4sh -- general shell script boiler plate -*- Autoconf -*-
!Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
Written by Gary V. Vaughan, 2004
This file is part of GNU Cvs-utils.
***
*** 337,344
--- 337,346
}
if ${opt_dry_run-false}; then :; else
+ eval "$lt_switch_to_user_locale"
eval "$my_cmd"
my_status=$?
+ eval "$lt_switch_to_safe_locale"
if test "$my_status" -eq 0; then :; else
eval "(exit $my_status); $my_fail_exp"
fi
*** libltdl/config/ltmain.m4sh.bak 2008-01-20 17:08:53.0 +0100
--- libltdl/config/ltmain.m4sh 2008-01-21 00:41:42.0 +0100
***
*** 4,10
# ltmain.sh (GNU @PACKAGE@@TIMESTAMP@) @VERSION@
# Written by Gordon Matzigkeit <[EMAIL PROTECTED]>, 1996
! # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007 2008 Free Software Foundation, Inc.
# This is free software; see the source for copying conditions. There is NO
# warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--- 4,10
# ltmain.sh (GNU @PACKAGE@@TIMESTAMP@) @VERSION@
# Written by Gordon Matzigkeit <[EMAIL PROTECTED]>, 1996
! # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
# This is free software; see the source for copying conditions. There is NO
# warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
***
*** 96,107
--- 96,111
# Only set LANG and LC_ALL to C if already set.
# These must not be set unconditionally because not all systems understand
# e.g. LANG=C (notably SCO).
+ lt_switch_to_user_locale=
+ lt_switch_to_safe_locale=
for lt_var in LANG LANGUAGE LC_ALL LC_CTYPE LC_COLLATE LC_MESSAGES
do
eval "if test \"\${$lt_var+set}\" = set; then
save_$lt_var=\$$lt_var
$lt_var=C
export $lt_var
+ lt_switch_to_user_locale=\"$lt_var=\$save_$lt_var; \$lt_switch_to_user_locale\"
+ lt_switch_to_safe_locale=\"$lt_var=C; \$lt_switch_to_safe_locale\"
fi"
done
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
portability of -L
Hi, A while ago someone said that if in a build directory I have a (not yet installed) ../lib/libfoo.la, to link with this library I should *not* use libtool ... -L../lib -lfoo but rather mention the .la file explicitly: libtool ... -L../lib ../lib/libfoo.la or libtool ... ../lib/libfoo.la Now I see the same advice in the second-to-last paragraph of http://wiki.finkproject.org/index.php/Fink:Porting_Notes Is it true that references to non-yet-installed libool libraries should not be made with -l? If so, it would be worth to document this in the libtool documentation. I didn't find it there. Bruno ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
