Re: support for SunPRO C/C++ on Linux
Hi Bruno,
* Bruno Haible wrote on Wed, May 10, 2006 at 02:01:31PM CEST:
Here is a revised patch. I changed the recognition of the Sun compilers,
and the whole_archive_flag_spec and postdeps, so that now all 112 tests PASS.
Cool.
With this patch, the FAILs are turned into PASS; all tests PASS or SKIP.
Which ones skip?
Good question. I had many SKIPs, but this was either because I had forgotten
to copy a recent config.guess, or because I did
./configure
make
make check
- not knowing that after modifying libtool.m4, a simple make does not
update the aclocal.m4 and configure files in the subdirectories;
Yes. This issue has been fixed in CVS HEAD. I won't backport it though.
Some notes:
*** 3353,3358
--- 3353,3379
# 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'
;;
+ *)
+ if LC_ALL=C $CC -V 21 | sed 1q | grep Sun C /dev/null; then
If that LC_ALL=C was really necessary, then that is a bug. Autoconf
resets the locale, and many configure tests depend on this. Any reason
not to simplify this to something like this?
case `$CC -V 21 /dev/null` in
*Sun\ C*)
(several instances)
+ _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? There
has been a significant fix for this on Solaris post-1.5.22 (on
2006-02-03, after several tries in the past), and only the CVS HEAD
Libtool testsuite exposes the known failures fully. Related question:
are you volunteering for the forward-port of the patch? (If not, I can
do it, but it'll take longer then.)
Rest looks good, except there will be issues mixing C++ libraries
compiled with different compilers (as expected).
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..
Cheers,
Ralf
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: patch fixing FreeBSD shlib versioning
Hi Jean-Yves, Sorry for the delay. * Jean-Yves Lefort wrote on Fri, May 05, 2006 at 09:54:15PM CEST: Hi, could you please commit the attached patch (for branch-1-5)? It fixes shared library versioning on FreeBSD. Could you point me to the FreeBSD specific change that prompts this? I looked for it now, but could not find it. It seems the libtool port was reorganized somewhat. IIRC there was some mismatch between the version-type the FreeBSD ports-installed Libtool used and the one GNU Libtool uses; the danger is that when we change this, simple recompilations of some packages will cause to weird failures. I agree that if the mismatch is existent, we have a problem anyway. But I'd like to know about the existing installed base of libraries, so we can estimate the amount of breakage. One idea could be to make the transition only when going to Libtool-2.0. But honestly at the moment I feel I have too little knowledge to be able to decide that. It'd be good if FreeBSD ports maintainers could comment on this (are you one by chance?). Btw, I could not find the part of HEAD which numbers shared libraries, maybe you can point it out for me? The following files more or less correspond each other: branch-1-5 HEAD -- ltmain.in libltdl/config/ltmain.m4sh libtool.m4 libltdl/m4/libtool.m4 I hope that helps a bit. Cheers, Ralf
Re: patch fixing FreeBSD shlib versioning
On Wed, 10 May 2006 18:15:37 +0200 Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Jean-Yves, Sorry for the delay. * Jean-Yves Lefort wrote on Fri, May 05, 2006 at 09:54:15PM CEST: Hi, could you please commit the attached patch (for branch-1-5)? It fixes shared library versioning on FreeBSD. Could you point me to the FreeBSD specific change that prompts this? I looked for it now, but could not find it. It seems the libtool port was reorganized somewhat. There has been no FreeBSD change. The libtool shlib numbering on FreeBSD always was broken afaik. IIRC there was some mismatch between the version-type the FreeBSD ports-installed Libtool used and the one GNU Libtool uses; the danger is that when we change this, simple recompilations of some packages will cause to weird failures. I agree that if the mismatch is existent, we have a problem anyway. But I'd like to know about the existing installed base of libraries, so we can estimate the amount of breakage. One idea could be to make the transition only when going to Libtool-2.0. But honestly at the moment I feel I have too little knowledge to be able to decide that. It'd be good if FreeBSD ports maintainers could comment on this (are you one by chance?). No I'm not. I've CC'ed the port maintainer as well as the relevant authority within FreeBSD. They should be able to explain you why they would like this bug to be fixed upstream. Btw, I could not find the part of HEAD which numbers shared libraries, maybe you can point it out for me? The following files more or less correspond each other: branch-1-5 HEAD -- ltmain.in libltdl/config/ltmain.m4sh libtool.m4 libltdl/m4/libtool.m4 I hope that helps a bit. Yes, thanks. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgp2U99wSDYDs.pgp Description: PGP signature
Libtool apparantly removing path parameters on FreeBSD
Hi, I encountered a problem while trying to build a softwarepackage (JRTPLib [1]) which uses libtool on FreeBSD 6.0. The library path (-L /usr/local/lib) added on the libtool commandline, seems to be removed and not passed on to GCC. I will try with more recent versions, but I did not find anything that seemed to solve this in the changelogs. Any hints? [EMAIL PROTECTED] make Making all in src /usr/local/bin/bash ../libtool --tag=CXX --mode=link g++ -O2 -o libjrtp.la -rpath /usr/local/lib -release 3.5.2 -L /usr/local/lib -ljthread -lpthread rtpdebug.lo rtpsession.lo rtperrors.lo rtpudpv4transmitter.lo rtcpsdesinfo.lo rtppollthread.lo rtppacket.lo rtppacketbuilder.lo rtpsessionparams.lo rtpsources.lo rtpinternalsourcedata.lo rtpsourcedata.lo rtpipv4address.lo rtcpcompoundpacket.lo rtcpapppacket.lo rtcpbyepacket.lo rtcprrpacket.lo rtcpsdespacket.lo rtcpsrpacket.lo rtplibraryversion.lo rtcppacket.lo rtcpcompoundpacketbuilder.lo rtprandom.lo rtcpscheduler.lo rtcppacketbuilder.lo rtpsessionsources.lo rtpcollisionlist.lo rtpipv6address.lo rtpudpv6transmitter.lo rtptimeutilities.lo rtpfaketransmitter.lo g++ -shared -nostdlib /usr/lib/crti.o /usr/lib/crtbeginS.o .libs/rtpdebug.o .libs/rtpsession.o .libs/rtperrors.o .libs/rtpudpv4transmitter.o .libs/rtcpsdesinfo.o .libs/rtppollthread.o .libs/rtppacket.o .libs/rtppacketbuilder.o .libs/rtpsessionparams.o .libs/rtpsources.o .libs/rtpinternalsourcedata.o .libs/rtpsourcedata.o .libs/rtpipv4address.o .libs/rtcpcompoundpacket.o .libs/rtcpapppacket.o .libs/rtcpbyepacket.o .libs/rtcprrpacket.o .libs/rtcpsdespacket.o .libs/rtcpsrpacket.o .libs/rtplibraryversion.o .libs/rtcppacket.o .libs/rtcpcompoundpacketbuilder.o .libs/rtprandom.o .libs/rtcpscheduler.o .libs/rtcppacketbuilder.o .libs/rtpsessionsources.o .libs/rtpcollisionlist.o .libs/rtpipv6address.o .libs/rtpudpv6transmitter.o .libs/rtptimeutilities.o .libs/rtpfaketransmitter.o -L/usr/home/takis/jrtplib-3.5.2-pi/src -ljthread -lpthread -L/usr/lib -lstdc++ -lm -lgcc_pic /usr/lib/crtendS.o /usr/lib/crtn.o -Wl,-soname -Wl,libjrtp-3.5.2.so -o .libs/libjrtp-3.5.2.so /usr/bin/ld: cannot find -ljthread *** Error code 1 Stop in /usr/home/takis/jrtplib-3.5.2-pi/src. *** Error code 1 Stop in /usr/home/takis/jrtplib-3.5.2-pi. [EMAIL PROTECTED] [EMAIL PROTECTED] ./libtool --version ltmain.sh (GNU libtool) 1.5.14 (1.1220.2.195 2005/02/12 12:12:33) Copyright (C) 2005 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. With friendly regards, Takis [1] http://research.edm.uhasselt.be/jori/jrtplib/jrtplib.html ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool apparantly removing path parameters on FreeBSD
Hi Panagiotis, * Panagiotis Issaris wrote on Wed, May 10, 2006 at 01:05:50PM CEST: I encountered a problem while trying to build a softwarepackage (JRTPLib [1]) which uses libtool on FreeBSD 6.0. The library path (-L /usr/local/lib) added on the libtool commandline, seems to be removed and not passed on to GCC. I will try with more recent versions, but I did not find anything that seemed to solve this in the changelogs. Any hints? Two comments here: - please use -L/usr/local/lib (i.e., no space between -L and the argument); then it should work. - there was actually a regression in 1.5.22 over 1.5.20 which caused some paths to be incorrectly removed on FreeBSD and some other BSD variants. Has since been fixed in CVS branch-1-5 (and HEAD). Cheers, Ralf [EMAIL PROTECTED] ./libtool --version ltmain.sh (GNU libtool) 1.5.14 (1.1220.2.195 2005/02/12 12:12:33) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: support for SunPRO C/C++ on Linux
Hello Ralf,
Here is a revised patch. I changed the recognition of the Sun compilers,
and the whole_archive_flag_spec and postdeps, so that now all 112 tests PASS.
With this patch, the FAILs are turned into PASS; all tests PASS or SKIP.
Which ones skip?
Good question. I had many SKIPs, but this was either because I had forgotten
to copy a recent config.guess, or because I did
./configure
make
make check
- not knowing that after modifying libtool.m4, a simple make does not
update the aclocal.m4 and configure files in the subdirectories; now I do
./configure
make
make dist
make check
and it works much better!
2006-05-09 Bruno Haible [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG, AC_LIBTOOL_POSTDEP_PREDEP):
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-09 03:55:44.0 +0200
***
*** 3353,3358
--- 3353,3379
# 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'
;;
+ *)
+ if LC_ALL=C $CC -V 21 | sed 1q | grep Sun C /dev/null; then
+ # 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`new_convenience=; for conv in $convenience\\; do
test -z \$conv\ || new_convenience=\$new_convenience,$conv\; done; $echo
\$new_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'
+ fi
+ ;;
esac
;;
lynxos*)
***
*** 3872,3877
--- 3893,3905
_LT_AC_TAGVAR(postdeps,$1)=
;;
+ linux*)
+ if LC_ALL=C $CC -V 21 | sed 1q | grep Sun C /dev/null; then
+ # Sun C++ 5.9
+ _LT_AC_TAGVAR(postdeps,$1)='-lCstd -lCrun'
+ fi
+ ;;
+
solaris*)
case $cc_basename in
CC*)
***
*** 4991,4996
--- 5019,5030
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
;;
*)
+ if LC_ALL=C $CC -V 21 | sed 1q | grep Sun C /dev/null; then
+ # Sun C++ 5.9
+ _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+ _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
+ fi
;;
esac
;;
***
*** 5237,5242
--- 5271,5284
# All Alpha code is PIC.
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
;;
+ *)
+ if LC_ALL=C $CC -V 21 | sed 1q | grep Sun C /dev/null; then
+ # Sun C 5.9
+ _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+ _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ fi
+ ;;
esac
;;
***
*** 5547,5559
ifc* | ifort*) # Intel Fortran compiler
tmp_addflag=' -nofor_main' ;;
esac
! _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared'$tmp_addflag' $libobjs
$deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
if test $supports_anon_versioning = yes; then
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo { global:
$output_objdir/$libname.ver~
cat $export_symbols | sed -e s/\(.*\)/\1;/ $output_objdir/$libname.ver~
$echo local: *; }; $output_objdir/$libname.ver~
! $CC -shared'$tmp_addflag' $libobjs $deplibs $compiler_flags
${wl}-soname $wl$soname ${wl}-version-script ${wl}$output_objdir/$libname.ver
-o $lib'
fi
else
Re: Libtool apparantly removing path parameters on FreeBSD
Hi, Please ignore. The space between the -L and the /usr/local/lib was the culprit. With friendly regards, Takis ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool apparantly removing path parameters on FreeBSD
On 2006-05-10, Ralf Wildenhues [EMAIL PROTECTED] wrote: - there was actually a regression in 1.5.22 over 1.5.20 which caused some paths to be incorrectly removed on FreeBSD and some other BSD variants. Has since been fixed in CVS branch-1-5 (and HEAD). Is there likely to be a 1.5.24 release soon? I've just spent a while trying to extract that patch from CVS to see if it fixed so odd build issues I've been seeing on some of the BSDs, but it appears to be impossible to do without a very recent CVS which allows you to diff between two dates on a branch (1.12.12.1 can, but 1.12.9 can't and that's the version in debian unstable!) I'm not especially keen to install CVS from source just to extract a patch! I can probably track the patch down on the libtool patches list (and hope that the latest version posted was close to that applied) but I noticed from the ChangeLog that there are a number of other fixes which sound useful, and that it's been longer since 1.5.22 than between other recent releases, so I was wondering if a release was imminent. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool release plan (was: Libtool apparantly removing path parameters on FreeBSD)
Hi Olly, * Olly Betts wrote on Wed, May 10, 2006 at 04:38:08PM CEST: On 2006-05-10, Ralf Wildenhues [EMAIL PROTECTED] wrote: - there was actually a regression in 1.5.22 over 1.5.20 which caused some paths to be incorrectly removed on FreeBSD and some other BSD variants. Has since been fixed in CVS branch-1-5 (and HEAD). Is there likely to be a 1.5.24 release soon? Oh dear. Don't ask about my original plans. They were something like this: have Autoconf-2.60 in March, then Libtool-1.5.24 soon after that, then Libtool-2.0 soon after that. :-/ I know Libtool-1.5.24 is important to get out, due to the regressions I put in 1.5.22. And it will be my primary focus once Autoconf-2.60 is done. However, there are some other systems that need fixes, HP-UX being one of them; and a few more patches which have queued up since. As I don't like to plan on an 1.5.26 (at least not before releasing 1.5.24), I would like to have at least all the currently-known serious stuff in 1.5.24, so that then we can finally concentrate on 2.0 again. :-/ The good thing being that I expect Autoconf-2.60 to be done this month. I've just spent a while trying to extract that patch from CVS to see if it fixed so odd build issues I've been seeing on some of the BSDs, but it appears to be impossible to do without a very recent CVS which allows you to diff between two dates on a branch (1.12.12.1 can, but 1.12.9 can't and that's the version in debian unstable!) I'm not especially keen to install CVS from source just to extract a patch! The two regressions: http://lists.gnu.org/archive/html/libtool-patches/2006-03/msg7.html http://lists.gnu.org/archive/html/libtool-patches/2006-03/msg6.html Another important patch (for DragonFly): http://lists.gnu.org/archive/html/libtool-patches/2006-03/msg00027.html I can probably track the patch down on the libtool patches list (and hope that the latest version posted was close to that applied) but I noticed from the ChangeLog that there are a number of other fixes which sound useful, Definitely. and that it's been longer since 1.5.22 than between other recent releases, so I was wondering if a release was imminent. Well, the longer delay has been due to me working primarily on Autoconf, and few people working on Libtool meanwhile. I know this isn't good, and to some extent it may not have been a good idea in hindsight, but OTOH Autoconf users have been waiting almost 3 years for a new release, and some pretty desperately. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: [png-mng-implement] -version-number and BeOS
From: Christian Biesinger It seems to me that this is a bug in any case. Not only is -version-number inconsistent with -version-info here. Even if BeOS has a versioning system for libraries and libtool gets support for that, this would still leave -version-number broken for other platforms where version_type=none (seems to be amigaos, os2 and sysv4 (in some cases)). It's like evaluating 0/0 - on an OS with no version numbering there is no defined way to map the non-existent OS version number back to the corresponding version info data. The fix isn't really a hack because it simply defines that such OSes go through the path shared by linux, macos(darwin) and windows. The result is later discarded by the version-info code so the actual values are not important. An alternative fix is to simply set all the values to '1', but that would be a bigger change... It would be better if we could use version-info across all the platforms, but it is not possible to obtain consistent behaviour across the various platforms with a single set of current:age:revision. That's because some platforms produce a 'major' of (current-age) and some calculate a major of (current). With libpng we ensure that minor package revisions (e.g. package 1.2.8-1.2.9) change the ABI compatibly, so we need the 'major' to remain constant on all platforms across a minor package revision. For example compare the code for the determination of major in the cases for freebsd-elf (major=.$current) and linux (major=.($current - $age). This defines an inconsistent set of ABI versions for any package currently running on both FreeBSD and Linux (even though the semantic of a major version change is defined the same on FreeBSD as Linux - indeed it is actually documented on FreeBSD!) A compatible ABI change, such as the add of a new interface, increments current and age, so the major remains unchanged (compatible ABI) on Linux but there is a new ABI on FreeBSD. Fortunately -version-number does what libpng requires - ensures that the major version *only* changes on an incompatible ABI change. Apart from the two bugs (failure in 'none' and irix fails if the major version number is 0) we haven't seen any problems (yet). I've seem to have run into a similar problem, what _is_ really the problem? /bin/sh ../libtool --tag=CC --mode=link ppc-amigaos-gcc -g -O2 -Wall -W -o libtiff.la -rpath /usr/local/amiga/lib -no-undefined -version-number 3:8:2 tif_aux.lo tif_close.lo tif_codec.lo tif_color.lo tif_compress.lo tif_dir.lo tif_dirinfo.lo tif_dirread.lo tif_dirwrite.lo tif_dumpmode.lo tif_error.lo tif_extension.lo tif_fax3.lo tif_fax3sm.lo tif_flush.lo tif_getimage.lo tif_jpeg.lo tif_luv.lo tif_lzw.lo tif_next.lo tif_ojpeg.lo tif_open.lo tif_packbits.lo tif_pixarlog.lo tif_predict.lo tif_print.lo tif_read.lo tif_strip.lo tif_swab.lo tif_thunder.lo tif_tile.lo tif_unix.lo tif_version.lo tif_warning.lo tif_write.lo tif_zip.lo ../port/libport.la -ljpeg -lz -lm -lc libtool: link: CURRENT `' must be a nonnegative integer libtool: link: `3:8:2' is not valid version information -- Nicolas Mendoza http://utilitybase.com ___ http://lists.gnu.org/mailman/listinfo/libtool
