portability of -Lrelative_directory_name
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
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 21
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.
* libltdl/config/general.m4sh (func_show_eval): Use it.
*** libltdl/config/ltmain.m4sh.bak 2008-01-20 17:08:53.0 +0100
--- libltdl/config/ltmain.m4sh 2008-01-20 17:13:06.0 +0100
***
*** 96,109
--- 96,114
# 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_env=
for lt_var in LANG LANGUAGE LC_ALL LC_CTYPE
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 memory.h is also available through string.h. 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
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 21 | 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 21
+ # would be better.
+ output_verbose_link_cmd='echo'
+
+ # Archives containing C++ object files must be created using
+ # CC -xar, where CC is the Sun C++ compiler. This is
+ # necessary to make sure instantiated templates are included
+ # in the archive.
+ _LT_AC_TAGVAR(old_archive_cmds, $1)='$CC -xar -o $oldlib $oldobjs'
+ ;;
esac
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
