libtool ChangeLog libltdl/m4/ltoptions.m4
CVSROOT:/sources/libtool Module name:libtool Changes by: Peter O'Gorman pogma 08/02/06 19:53:01 Modified files: . : ChangeLog libltdl/m4 : ltoptions.m4 Log message: * libltdl/m4/ltoptions.m4 (_LT_SET_OPTIONS): Only set default LT_INIT values for LT_INIT, not LTDL_INIT. Reported by Jochem Huhmann [EMAIL PROTECTED] CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool/ChangeLog?cvsroot=libtoolr1=1.2586r2=1.2587 http://cvs.savannah.gnu.org/viewcvs/libtool/libltdl/m4/ltoptions.m4?cvsroot=libtoolr1=1.11r2=1.12 ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
Native Windows through parity
Hi there (again :))! I have a few patches for libtool in my queue again :) * 1.5.24 - all tests passed * 1.5.26 - all tests passed * HEAD (2.1c) - all classic tests passed, log for new testsuite attached. I hope this time they will make it into CVS :) For HEAD, I'd need some help, please. I attached the log for test no. 5, which fails like some others too with file not found errors which I don't understand... (?) any ideas? Note: I have chosen the *-*-winnt* host-triplet for my setup, since the resulting binaries are plain native windows, so I think this is correct. Also right now I'm the only one doing this, and as far as I know, there are no collissions with others. Note: I needed to patch config.guess to recognize my compiler on interix (cygwin not done yet...). I did this for various automake releases and the gnuconfig package from portage (did you know, that portage runs on interix fine allready? :) I made a port of gentoo/alt-prefix). I attached only the automake 1.10 patch, which should make obvious what I did there. Of course this patch is not targeted at libtool, I attached it here only, since it's a prerequisite to make things work on interix... Please could somebody review the patches and the testsuite log (which is more important for me right now :)), and give me some feedback? Thanks in advance! Cheers, Markus lt-1.5.26-parity.patch.gz Description: lt-1.5.26-parity.patch.gz automake-1.10-winnt.patch.gz Description: automake-1.10-winnt.patch.gz lt-1.5.24-parity.patch.gz Description: lt-1.5.24-parity.patch.gz testsuite.log.gz Description: testsuite.log.gz
FYI - Re: _LT_ENABLE_FAST_INSTALL being expanded multiple times.
Peter O'Gorman wrote: Hi, When building ImageMagick on Mac OS X, and installing with DESTDIR Jochem Huhmann of the MacPorts project noticed that the wrapper scripts were being installed, and the binaries not. I expect on darwin that fast_install always be set to needless, eliminating the need for relinking, however, with libtool HEAD, it gets set to needless, then if your configure.ac contains both LT_INIT and next LTDL_INIT, it gets set back to 'no' again. Both LT_INIT and LTDL_INIT expand _LT_SET_OPTIONS, which duly expands _LT_ENABLE_FAST_INSTALL *twice*. _LT_SET_OPTIONS should only set the default options once (and only for LT_INIT). Peter I committed this. Peter -- Peter O'Gorman http://pogma.com 2008-02-06 Peter O'Gorman [EMAIL PROTECTED] * libltdl/m4/ltoptions.m4 (_LT_SET_OPTIONS): Only set default LT_INIT values for LT_INIT, not LTDL_INIT. Reported by Jochem Huhmann [EMAIL PROTECTED] Index: libltdl/m4/ltoptions.m4 === RCS file: /sources/libtool/libtool/libltdl/m4/ltoptions.m4,v retrieving revision 1.11 diff -u -r1.11 ltoptions.m4 --- libltdl/m4/ltoptions.m4 14 Jan 2008 21:18:49 - 1.11 +++ libltdl/m4/ltoptions.m4 6 Feb 2008 19:52:48 - @@ -62,23 +62,26 @@ [# Set options m4_foreach([_LT_Option], m4_split(m4_normalize([$2])), [_LT_SET_OPTION([$1], _LT_Option)]) -dnl -dnl Simply set some default values (i.e off) if boolean options were not -dnl specified: -_LT_UNLESS_OPTIONS([LT_INIT], [dlopen], [enable_dlopen=no -]) -_LT_UNLESS_OPTIONS([LT_INIT], [win32-dll], [enable_win32_dll=no -]) -dnl -dnl If no reference was made to various pairs of opposing options, then -dnl we run the default mode handler for the pair. For example, if neither -dnl `shared' nor `disable-shared' was passed, we enable building of shared -dnl archives by default: -_LT_UNLESS_OPTIONS([LT_INIT], [shared disable-shared], [_LT_ENABLE_SHARED]) -_LT_UNLESS_OPTIONS([LT_INIT], [static disable-static], [_LT_ENABLE_STATIC]) -_LT_UNLESS_OPTIONS([LT_INIT], [pic-only no-pic], [_LT_WITH_PIC]) -_LT_UNLESS_OPTIONS([LT_INIT], [fast-install disable-fast-install], - [_LT_ENABLE_FAST_INSTALL]) + +m4_if([$1],[LT_INIT],[ + dnl + dnl Simply set some default values (i.e off) if boolean options were not + dnl specified: + _LT_UNLESS_OPTIONS([LT_INIT], [dlopen], [enable_dlopen=no + ]) + _LT_UNLESS_OPTIONS([LT_INIT], [win32-dll], [enable_win32_dll=no + ]) + dnl + dnl If no reference was made to various pairs of opposing options, then + dnl we run the default mode handler for the pair. For example, if neither + dnl `shared' nor `disable-shared' was passed, we enable building of shared + dnl archives by default: + _LT_UNLESS_OPTIONS([LT_INIT], [shared disable-shared], [_LT_ENABLE_SHARED]) + _LT_UNLESS_OPTIONS([LT_INIT], [static disable-static], [_LT_ENABLE_STATIC]) + _LT_UNLESS_OPTIONS([LT_INIT], [pic-only no-pic], [_LT_WITH_PIC]) + _LT_UNLESS_OPTIONS([LT_INIT], [fast-install disable-fast-install], + [_LT_ENABLE_FAST_INSTALL]) + ]) ])# _LT_SET_OPTIONS
Re: problem with libtool generated version script and underscores
On Feb 6, 2008 2:51 AM, Aleksey Demakov [EMAIL PROTECTED] wrote: I try to build a library (glib to be specific) with a cross-toolchain that prepends underscore to C names. The problem is that the symbols the library has to export do not get exported. By the way my problem looks just the same as discussed here: http://lists.gnu.org/archive/html/bug-libtool/2007-05/msg00051.html Though I do not get from this discussion if it was somehow resolved. Regards, Aleksey ___ http://lists.gnu.org/mailman/listinfo/libtool
HEAD testsuite.
Hi all... Could it be, that the autotest testsuite behaves badly if building out-of-source? I'm getting a whole bunch of file not founds with relative paths within the source dir. If yes, for now I will finish my libtool port with building inside the source dir, so I manage to fugure out which failures are my fault :) Cheers, Markus ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: HEAD testsuite.
Hi Another one... The run scripts for the failed tests seem to miss some quoting (for exmaple my preprocessor is compiler -E, so i get: testsuite: invalid option: -E... Cheers, Markus Duft Markus wrote: Hi all... Could it be, that the autotest testsuite behaves badly if building out-of-source? I'm getting a whole bunch of file not founds with relative paths within the source dir. If yes, for now I will finish my libtool port with building inside the source dir, so I manage to fugure out which failures are my fault :) Cheers, Markus ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Native Windows through parity
Hi there (again :))! I have a few patches for libtool in my queue again :) * 1.5.24 - all tests passed * 1.5.26 - all tests passed * HEAD (2.1c) - all classic tests passed, log for new testsuite attached. I hope this time they will make it into CVS :) For HEAD, I'd need some help, please. I attached the log for test no. 5, which fails like some others too with file not found errors which I don't understand... (?) any ideas? Note: I have chosen the *-*-winnt* host-triplet for my setup, since the resulting binaries are plain native windows, so I think this is correct. Also right now I'm the only one doing this, and as far as I know, there are no collissions with others. Note: I needed to patch config.guess to recognize my compiler on interix (cygwin not done yet...). I did this for various automake releases and the gnuconfig package from portage (did you know, that portage runs on interix fine allready? :) I made a port of gentoo/alt-prefix). I attached only the automake 1.10 patch, which should make obvious what I did there. Of course this patch is not targeted at libtool, I attached it here only, since it's a prerequisite to make things work on interix... Please could somebody review the patches and the testsuite log (which is more important for me right now :)), and give me some feedback? Thanks in advance! Cheers, Markus lt-1.5.26-parity.patch.gz Description: lt-1.5.26-parity.patch.gz automake-1.10-winnt.patch.gz Description: automake-1.10-winnt.patch.gz lt-1.5.24-parity.patch.gz Description: lt-1.5.24-parity.patch.gz testsuite.log.gz Description: testsuite.log.gz ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with libtool generated version script and underscores
Aleksey Demakov wrote:
On Feb 6, 2008 2:51 AM, Aleksey Demakov [EMAIL PROTECTED] wrote:
I try to build a library (glib to be specific) with a cross-toolchain
that prepends underscore to C names. The problem is that the
symbols the library has to export do not get exported.
By the way my problem looks just the same as discussed here:
http://lists.gnu.org/archive/html/bug-libtool/2007-05/msg00051.html
Though I do not get from this discussion if it was somehow resolved.
Libtool does not know about the system you are building for, does not
know that an underscore is required.
What is the host triplet for the system that you are building for?
You need to set archive_expsym_cmds for that system to be similar to
interix[[3-9]]* which has:
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed s,^,_, $export_symbols
$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs
$compiler_flags ${wl}-h,$soname
${wl}--retain-symbols-file,$output_objdir/$soname.expsym
${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280`
-o $lib'
As you can see, it takes the symbol list, prepends and underscore, and
then uses that.
It is not required to change global_symbol_pipe etc.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.1b released (alpha release)
On Wed, 6 Feb 2008, Gary V. Vaughan wrote: With only one bug reported and fixed since Feb 1, either this is the most spectacularly well engineered release in the history of libtool, or else it is the least well tested release ever... I did voice one minor complaint on another list (automake). I don't like this one line in libltdl/Makefile.inc: BUILT_SOURCES += ltdl/$(ARGZ_H) since it still necessitate a recursive build when/if this Automake-contributed build rule is fixed: all: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) all-am so that it looks like all: all-am when BUILT_SOURCES is not defined and therefore avoids unnecessary recursion to achieve non-recursive build nirvana. Using BUILT_SOURCES is similarly evil to using SUBDIRS to a project desiring a completely non-recursive build. If there is a way to replace this with proper dependencies/rules prior to release, I would be very happy indeed. Ralph says this is not important but to me it is like purchasing a brand new sports car and noticing a small key mark on the driver side door. Not important to function but annoying as hell to the innate perfectionist. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Sun Studio: STL libraries
In trying to resolve a C++ issue within Open MPI we've run into an issue with Libtool automatically linking in Cstd. Because Sun Studio supports two different types of C++ STL libraries (Cstl and stlport4) we needed to remove Open MPI's reliance on STL functions so applications being compiled with Sun Studio could use either version of STL libraries (note once you link with one you cannot use the other STL library). After making Open MPI STL agnostic we found out that libtool is automatically adding in -lCstd -lCrun to CXXFLAGS which is causing our fix to make Open MPI STL agnostic useless. We currently are hacking aclocal's LT macros to *not* add the Cstd library to any of OMPI's CXXFLAGS to work around this issue. We are wondering if there is a way libtool could remove the addition of -lCstd and -lCrun to CXXFLAGS when it detects Sun Studio Compilers being used? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
In regard to: Sun Studio: STL libraries, Dan Lacher said (at 12:04pm on Feb...: In trying to resolve a C++ issue within Open MPI we've run into an issue with Libtool automatically linking in Cstd. Because Sun Studio supports two different types of C++ STL libraries (Cstl and stlport4) we needed to remove Open MPI's reliance on STL functions so applications being compiled with Sun Studio could use either version of STL libraries (note once you link with one you cannot use the other STL library). I just ran into the opposite of this problem yesterday. The short answer: you're using a version of libtool that's pretty old. This issue was fixed in 2006. Upgrade your libtool, and the problem will go away. Now, libtool doesn't force either Cstd or Crun into the libraries, which means that if you use -library=stlport4 as part of CXXFLAGS, you probably also need -library=Crun since that won't automatically be added. I personally think that libtool should still be adding -lCrun automatically, as it does for -lc, since -lCrun is compatible with stlport4, but since there's a workaround, it's no big deal. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with libtool generated version script and underscores
On Feb 6, 2008 9:18 PM, Peter O'Gorman [EMAIL PROTECTED] wrote:
What is the host triplet for the system that you are building for?
Umm the canonical host name must be something like
bfin-unknown-linux.
You need to set archive_expsym_cmds for that system to be similar to
interix[[3-9]]* which has:
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed s,^,_, $export_symbols
$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs
$compiler_flags ${wl}-h,$soname
${wl}--retain-symbols-file,$output_objdir/$soname.expsym
${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280`
-o $lib'
As you can see, it takes the symbol list, prepends and underscore, and
then uses that.
Okay, thanks for the hint.
It is not required to change global_symbol_pipe etc.
The strange thing is that libtool checks if global_symbol_pipe
needs to handle underscore with a general check, not with
a host name check.
But this knowledge is not used for archive_expsym_cmds.
For blackfin the only difference is undescore, otherwise it
looks like regular linux. So special casing bfin-linux looks
excessive. But if this okay with libtool maintainers, I may
try to create a patch that does exactly that.
Regards,
Aleksey
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with libtool generated version script and underscores
On Wednesday 06 February 2008, Aleksey Demakov wrote:
On Feb 6, 2008 9:18 PM, Peter O'Gorman [EMAIL PROTECTED] wrote:
What is the host triplet for the system that you are building for?
Umm the canonical host name must be something like
bfin-unknown-linux.
You need to set archive_expsym_cmds for that system to be similar to
interix[[3-9]]* which has:
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed s,^,_,
$export_symbols
$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs
$compiler_flags ${wl}-h,$soname
${wl}--retain-symbols-file,$output_objdir/$soname.expsym
${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280`
-o $lib'
As you can see, it takes the symbol list, prepends and underscore, and
then uses that.
Okay, thanks for the hint.
It is not required to change global_symbol_pipe etc.
The strange thing is that libtool checks if global_symbol_pipe
needs to handle underscore with a general check, not with
a host name check.
But this knowledge is not used for archive_expsym_cmds.
For blackfin the only difference is undescore, otherwise it
looks like regular linux. So special casing bfin-linux looks
excessive. But if this okay with libtool maintainers, I may
try to create a patch that does exactly that.
Blackfin is not the only target that utilizes underscore prefixes. a more
generic check (as noted in the previous thread you cited) would be to
consider the define from gcc __USER_LABEL_PREFIX__.
-mike
signature.asc
Description: This is a digitally signed message part.
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with libtool generated version script and underscores
Mike Frysinger wrote: Blackfin is not the only target that utilizes underscore prefixes. a more generic check (as noted in the previous thread you cited) would be to consider the define from gcc __USER_LABEL_PREFIX__. -mike Hi Mike, Feel free to send patches. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with libtool generated version script and underscores
On Wednesday 06 February 2008, Peter O'Gorman wrote: Mike Frysinger wrote: Blackfin is not the only target that utilizes underscore prefixes. a more generic check (as noted in the previous thread you cited) would be to consider the define from gcc __USER_LABEL_PREFIX__. Feel free to send patches. it's been a while since i looked at the issue and i'd rather we agree on the way to move forward before throwing code at the issue -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with libtool generated version script and underscores
Mike Frysinger wrote: On Wednesday 06 February 2008, Peter O'Gorman wrote: Mike Frysinger wrote: Blackfin is not the only target that utilizes underscore prefixes. a more generic check (as noted in the previous thread you cited) would be to consider the define from gcc __USER_LABEL_PREFIX__. Feel free to send patches. it's been a while since i looked at the issue and i'd rather we agree on the way to move forward before throwing code at the issue I am fine with any solution that is limited in scope to gcc and linux. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
_LT_ENABLE_FAST_INSTALL being expanded multiple times.
Hi, When building ImageMagick on Mac OS X, and installing with DESTDIR Jochem Huhmann of the MacPorts project noticed that the wrapper scripts were being installed, and the binaries not. I expect on darwin that fast_install always be set to needless, eliminating the need for relinking, however, with libtool HEAD, it gets set to needless, then if your configure.ac contains both LT_INIT and next LTDL_INIT, it gets set back to 'no' again. Both LT_INIT and LTDL_INIT expand _LT_SET_OPTIONS, which duly expands _LT_ENABLE_FAST_INSTALL *twice*. _LT_SET_OPTIONS should only set the default options once (and only for LT_INIT). Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
FYI - Re: _LT_ENABLE_FAST_INSTALL being expanded multiple times.
Peter O'Gorman wrote: Hi, When building ImageMagick on Mac OS X, and installing with DESTDIR Jochem Huhmann of the MacPorts project noticed that the wrapper scripts were being installed, and the binaries not. I expect on darwin that fast_install always be set to needless, eliminating the need for relinking, however, with libtool HEAD, it gets set to needless, then if your configure.ac contains both LT_INIT and next LTDL_INIT, it gets set back to 'no' again. Both LT_INIT and LTDL_INIT expand _LT_SET_OPTIONS, which duly expands _LT_ENABLE_FAST_INSTALL *twice*. _LT_SET_OPTIONS should only set the default options once (and only for LT_INIT). Peter I committed this. Peter -- Peter O'Gorman http://pogma.com 2008-02-06 Peter O'Gorman [EMAIL PROTECTED] * libltdl/m4/ltoptions.m4 (_LT_SET_OPTIONS): Only set default LT_INIT values for LT_INIT, not LTDL_INIT. Reported by Jochem Huhmann [EMAIL PROTECTED] Index: libltdl/m4/ltoptions.m4 === RCS file: /sources/libtool/libtool/libltdl/m4/ltoptions.m4,v retrieving revision 1.11 diff -u -r1.11 ltoptions.m4 --- libltdl/m4/ltoptions.m4 14 Jan 2008 21:18:49 - 1.11 +++ libltdl/m4/ltoptions.m4 6 Feb 2008 19:52:48 - @@ -62,23 +62,26 @@ [# Set options m4_foreach([_LT_Option], m4_split(m4_normalize([$2])), [_LT_SET_OPTION([$1], _LT_Option)]) -dnl -dnl Simply set some default values (i.e off) if boolean options were not -dnl specified: -_LT_UNLESS_OPTIONS([LT_INIT], [dlopen], [enable_dlopen=no -]) -_LT_UNLESS_OPTIONS([LT_INIT], [win32-dll], [enable_win32_dll=no -]) -dnl -dnl If no reference was made to various pairs of opposing options, then -dnl we run the default mode handler for the pair. For example, if neither -dnl `shared' nor `disable-shared' was passed, we enable building of shared -dnl archives by default: -_LT_UNLESS_OPTIONS([LT_INIT], [shared disable-shared], [_LT_ENABLE_SHARED]) -_LT_UNLESS_OPTIONS([LT_INIT], [static disable-static], [_LT_ENABLE_STATIC]) -_LT_UNLESS_OPTIONS([LT_INIT], [pic-only no-pic], [_LT_WITH_PIC]) -_LT_UNLESS_OPTIONS([LT_INIT], [fast-install disable-fast-install], - [_LT_ENABLE_FAST_INSTALL]) + +m4_if([$1],[LT_INIT],[ + dnl + dnl Simply set some default values (i.e off) if boolean options were not + dnl specified: + _LT_UNLESS_OPTIONS([LT_INIT], [dlopen], [enable_dlopen=no + ]) + _LT_UNLESS_OPTIONS([LT_INIT], [win32-dll], [enable_win32_dll=no + ]) + dnl + dnl If no reference was made to various pairs of opposing options, then + dnl we run the default mode handler for the pair. For example, if neither + dnl `shared' nor `disable-shared' was passed, we enable building of shared + dnl archives by default: + _LT_UNLESS_OPTIONS([LT_INIT], [shared disable-shared], [_LT_ENABLE_SHARED]) + _LT_UNLESS_OPTIONS([LT_INIT], [static disable-static], [_LT_ENABLE_STATIC]) + _LT_UNLESS_OPTIONS([LT_INIT], [pic-only no-pic], [_LT_WITH_PIC]) + _LT_UNLESS_OPTIONS([LT_INIT], [fast-install disable-fast-install], + [_LT_ENABLE_FAST_INSTALL]) + ]) ])# _LT_SET_OPTIONS ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.1b released (alpha release)
Gary V. Vaughan [EMAIL PROTECTED] writes: On 1 Feb 2008, at 01:06, Gary V. Vaughan wrote: The Libtool Team is pleased to announce alpha release 2.1b of GNU Libtool. With only one bug reported and fixed since Feb 1, either this is the most spectacularly well engineered release in the history of libtool, or else it is the least well tested release ever... Either way, if there are no more bugs found before Feb 10th, I plan to roll up 2.2 final. If you have any projects that you're thinking of moving to libtool-2, please test them now so that we can fix any problems you encounter before the final release!! FWIW, I re-build my stack of libraries (libidn, libtasn1, shishi, gss, gnutls, and gsasl) and it worked smoothly. Looking forward to the release, /Simon ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with libtool generated version script and underscores
* Aleksey Demakov wrote on Wed, Feb 06, 2008 at 08:01:42PM CET: On Feb 6, 2008 11:51 PM, Mike Frysinger [EMAIL PROTECTED] wrote: Blackfin is not the only target that utilizes underscore prefixes. a more generic check (as noted in the previous thread you cited) would be to consider the define from gcc __USER_LABEL_PREFIX__. Please take a look at AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE in libtool.m4. [...] That is while finding the correct global_symbol_pipe command it uses temporary variable $ac_symprfx. I think this variable could be just re-used to tell if the system requires underscore. There is no need for a separate test that relies on a gcc feature. The existing test goes through the entire chain compiler/linker/NM and therefore should be more reliable. I agree. Can we see testsuite output for Libtool 2.1b (see README) for a system that needs a change here? This failure should be exposed already. Esp. the stresstest should expose most use cases here. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HEAD testsuite.
Hello Markus, Again, for the umpteenth time: please do not top-post. * Duft Markus wrote on Wed, Feb 06, 2008 at 03:43:20PM CET: Could it be, that the autotest testsuite behaves badly if building out-of-source? No. Well, it could be, but you'd have to prove it by showing the commands you issued and the output you got (copy and paste, no editing, please; something reproducible). I'm getting a whole bunch of file not founds with relative paths within the source dir. If yes, for now I will finish my libtool port with building inside the source dir, so I manage to fugure out which failures are my fault :) My guess is, all of them. I always use a separate build tree. Another one... The run scripts for the failed tests seem to miss some quoting (for exmaple my preprocessor is compiler -E, so i get: testsuite: invalid option: -E... That *may* or may not be an issue. I'd need to know the Autoconf version used to generate the tests/testsuite file, and again, see a reproducible example. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.1b released (alpha release)
Hi Bob, * Bob Friesenhahn wrote on Wed, Feb 06, 2008 at 05:21:19PM CET: Using BUILT_SOURCES is similarly evil to using SUBDIRS to a project desiring a completely non-recursive build. I suppose you know of a better, portable way? If there is a way to replace this with proper dependencies/rules prior to release, I would be very happy indeed. If I knew one, I surely would have told you about it. Ralph says this is not important but to me it is like purchasing a brand new sports car and noticing a small key mark on the driver side door. Not important to function but annoying as hell to the innate perfectionist. But you haven't paid anything for that car (besides lots of help and testing effort, of course, for which I would like to thank you!), and that car is hardly a sportive one as it one has to run on crooked train tracks that run alongside a steep slope, and be prepared for falling rock. With such a rough car, a key mark is hardly noticeable. ;-) Ah, and I write myself with 'f'. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
Tim Mooney wrote: In regard to: Re: Sun Studio: STL libraries, Dan Lacher said (at 4:57pm on...: Even with what Tim has pointed out I am seeing the contrary with the following: o Open MPI src base o Sun Studio 12 o libtool 2.1b (just downloaded the latest) After autogen has finished the aclocal.m4 ends up with -library=Cstd -library=Crun both. So that is what is used in the creation of the libmpi_cxx.so.0 Looks like Albert's change from 2006-08-01 only went onto the 1.5 branch, and not HEAD. It should be on both branches. Thanks, I will find it and put it on HEAD. I still maintain that it would be OK to have libtool automatically add `-library=Crun', since that is generally needed whether you're using -library=stlport4 or -library=Cstd, but it's OK to not include that. We just need to make sure the correct usage is documented somewhere. If it's not currently documented (I don't know, I haven't checked the 2.x series), I would be willing to write a little blurb for the info files or some other spot, if people want. Something in notes.texi? Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
In regard to: Re: Sun Studio: STL libraries, Peter O'Gorman said (at 5:05pm...:
I still maintain that it would be OK to have libtool automatically add
`-library=Crun', since that is generally needed whether you're using
-library=stlport4 or -library=Cstd, but it's OK to not include that. We
just need to make sure the correct usage is documented somewhere.
If it's not currently documented (I don't know, I haven't checked the 2.x
series), I would be willing to write a little blurb for the info files
or some other spot, if people want.
Something in notes.texi?
How about this:
--- libtool-2.1b.orig/doc/notes.texi2008-01-26 00:21:22.0 -0600
+++ libtool-2.1b/doc/notes.texi 2008-02-06 17:32:43.89529 -0600
@@ -77,4 +77,27 @@
@code{lt_cv_sys_lib_dlsearch_path_spec} respectively to the correct search
paths.
[EMAIL PROTECTED]
+When using the C++ compiler from the Sun Workshop (formerly Forte)
+development environment on either Solaris or Linux, libtool will use
[EMAIL PROTECTED] as the linker, and will not automatically link with either
[EMAIL PROTECTED] or @file{libCrun}. This is because recent versions of
+Sun Workshop (11 and 12, as of this writing) have the option of using
[EMAIL PROTECTED] or @file{stlport4_dbg}, and those libraries are
+incompatible with @file{libCstd}.
+
+The correct method to link with the additional libraries that your project
+needs is to include each library in the @code{CXXFLAGS} when configuring your
+project. For example,
+
[EMAIL PROTECTED]
+ CXXFLAGS='-library=stlport4 -library=Crun'
[EMAIL PROTECTED] example
+
+or
+
[EMAIL PROTECTED]
+ CXXFLAGS='-library=Cstd -library=Crun'
[EMAIL PROTECTED] example
+
@end itemize
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
In regard to: Re: Sun Studio: STL libraries, Peter O'Gorman said (at 5:25pm...: Peter O'Gorman wrote: Tim Mooney wrote: In regard to: Re: Sun Studio: STL libraries, Dan Lacher said (at 4:57pm on...: Even with what Tim has pointed out I am seeing the contrary with the following: o Open MPI src base o Sun Studio 12 o libtool 2.1b (just downloaded the latest) After autogen has finished the aclocal.m4 ends up with -library=Cstd -library=Crun both. So that is what is used in the creation of the libmpi_cxx.so.0 Looks like Albert's change from 2006-08-01 only went onto the 1.5 branch, and not HEAD. It should be on both branches. Thanks, I will find it and put it on HEAD. Um, libltdl/m4/libtool.m4 has this check in _LT_SYS_HIDDEN_LIBDEPS for tag CXX: solaris*) case $cc_basename in CC*) # The more standards-conforming stlport4 library is # incompatible with the Cstd library. Avoid specifying # it if it's in CXXFLAGS. Ignore libCrun as # -library=stlport4 depends on it. case $CXX $CXXFLAGS in * -library=stlport4 *) solaris_use_stlport4=yes ;; esac # Adding this requires a known-good setup of shared libraries for # Sun compiler versions before 5.6, else PIC objects from an old # archive will be linked into the output, leading to subtle bugs. if test $solaris_use_stlport4 != yes; then _LT_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' fi ;; esac ;; So color me confused. Me too. Note that the case could be improved, because the same logic should apply if -library=stlport4_dbg is present as well. Tim, you say we still need to have -library=Crun for the stlport4 case? More than likely, yes. The stlport4 incompatibility is with libCstd, not libCrun. It looks like it was not added only because the stlport4 already depends on it (I guess from ldd output?). So there should be no harm in adding it explicitly. But if it shouldn't be needed, it might be nice to leave it off. I just checked, and libstlport4 is indeed linked to libCrun, so it shouldn't be needed explicitly. I think I should repeat my test, and make sure I'm on the right track. Part of the problem was that I was building a project with a very old version of libtool, and although I upgraded libtool to 1.5.26, I might be remembering how things were behaving with the old libtool. I'll rebuild the project and see if I get the same results. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
In regard to: Re: Sun Studio: STL libraries, Tim Mooney said (at 6:05pm on...: In regard to: Re: Sun Studio: STL libraries, Peter O'Gorman said (at 5:25pm...: Tim, you say we still need to have -library=Crun for the stlport4 case? More than likely, yes. The stlport4 incompatibility is with libCstd, not libCrun. I just tested with libtool 1.5.26: /bin/bash ../libtool --tag=CXX --mode=link CC -xO2 -library=stlport4 -xtarget=native -m64 -xarch=native -I/local/include -I/local/gnu/include -no-undefined -version-info 6:0:5 -L/local/lib/64 -L/local/gnu/lib/64 -o libtag.la -rpath /local/lib/64 tag.lo tagunion.lo fileref.lo audioproperties.lo ./mpeg/libmpeg.la ./ogg/libogg.la ./flac/libflac.la ./mpc/libmpc.la ./ape/libape.la ./toolkit/libtoolkit.la ./wavpack/libwavpack.la ./speex/libspeex.la ./trueaudio/libtrueaudio.la CC -G -zdefs -hlibtag.so.1 -o .libs/libtag.so.1.5.0 .libs/tag.o .libs/tagunion.o .libs/fileref.o .libs/audioproperties.o -z allextract ./mpeg/.libs/libmpeg.a ./ogg/.libs/libogg.a ./flac/.libs/libflac.a ./mpc/.libs/libmpc.a ./ape/.libs/libape.a ./toolkit/.libs/libtoolkit.a ./wavpack/.libs/libwavpack.a ./speex/.libs/libspeex.a ./trueaudio/.libs/libtrueaudio.a -z defaultextract -L/local/lib/64 -L/local/gnu/lib/64 -lz -library=stlport4 -lc -xtarget=native -m64 -xarch=native Undefined first referenced symbol in file void __Crun::pure_error() .libs/tag.o (symbol belongs to implicit dependency /usr/lib/64/libCrun.so.1) void*__Crun::simple_down_cast(void*,const __Crun::static_type_info*,const __Crun::static_type_info*) ./mpeg/.libs/libmpeg.a(id3v2tag.o) (symbol belongs to implicit dependency /usr/lib/64/libCrun.so.1) void __Crun::vector_des(void*,unsigned long,unsigned long,void(*)(void*)) ./mpeg/.libs/libmpeg.a(id3v1genres.o) (symbol belongs to implicit dependency /usr/lib/64/libCrun.so.1) void*operator new(unsigned long,void*) .libs/fileref.o (symbol belongs to implicit dependency /usr/lib/64/libCrun.so.1) [additional symbols elided] So, we apparently do need -library=Crun, whether or not -library=Cstd or -library=stlport4 are specified. Here's what ldd reports for libstlport4.so.1: $ldd /opt/SUNWspro/lib/stlport4/amd64/libstlport.so.1 libCrun.so.1 = /usr/lib/64/libCrun.so.1 libm.so.2 = /lib/64/libm.so.2 librt.so.1 =/lib/64/librt.so.1 libc.so.1 = /lib/64/libc.so.1 libaio.so.1 = /lib/64/libaio.so.1 libmd.so.1 =/lib/64/libmd.so.1 I wonder if some of this depends on what version of Workshop one is using? It looks like it was not added only because the stlport4 already depends on it (I guess from ldd output?). So there should be no harm in adding it explicitly. But if it shouldn't be needed, it might be nice to leave it off. I just checked, and libstlport4 is indeed linked to libCrun, so it shouldn't be needed explicitly. I was wrong about that, which is a bit of a surprise (not that I was wrong, I'm used to that ;-) ). I think I should repeat my test, and make sure I'm on the right track. I was on the right track - linking with -library=stlport4 isn't enough to pull in things like void operator delete[](void*), which come from libCrun. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HEAD testsuite.
Hi Markus, On 6 Feb 2008, at 22:17, Duft Markus wrote: Hi all... Could it be, that the autotest testsuite behaves badly if building out-of-source? I'm getting a whole bunch of file not founds with relative paths within the source dir. If yes, for now I will finish my libtool port with building inside the source dir, so I manage to fugure out which failures are my fault :) Cheers, Markus I ran 'make distcheck' successfully as part of the libtool-2.1b release process, which tests in tree, and out of tree builds. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Debugging Libtool's Insistence on Sourcing a Library from /usr/lib Rather Than LDFLAGS
I am attempting to debug an issue involving libtool from the avahi-0.6.22 package sourcing the local (i686-unknown-linux-gnu) version of libexpat (-lexpat) rather than the I one I direct it to find via LDFLAGS. The configure invocation: cd $(objdir) \ $(CURDIR)/$(srcdir)/configure \ CC=$(CC) AR=$(AR) RANLIB=$(RANLIB) STRIP=$(STRIP) \ CPPFLAGS=-I$(resultdir)../expat/usr/include \ -I$(resultdir)../gdbm/usr/include \ -I$(resultdir)../libcap/usr/include \ LDFLAGS=-L$(resultdir)../expat/usr/lib \ -L$(resultdir)../gdbm/usr/lib \ -L$(resultdir)../libcap/usr/lib \ LIBDAEMON_CFLAGS=-I$(resultdir)../libdaemon/usr/include \ LIBDAEMON_LIBS=-L$(resultdir)../libdaemon/usr/lib \ --build=$(build) \ --host=$(host) \ --disable-dbus \ --disable-glib \ --disable-gobject \ --disable-gtk \ --disable-manpages \ --disable-monodoc \ --disable-python \ --disable-qt3 \ --disable-qt4 \ --with-distro=none \ --with-xml=expat \ --prefix=/usr \ --sysconfdir=/etc \ --localstatedir=/var Failing build line: Making all in avahi-daemon make[3]: Entering directory `/tmp/src/avahi/.build/avahi-daemon' /bin/bash ../libtool --tag=CC --mode=link ppc_4xx-gcc -I/tmp/src/avahi/avahi-0.6.22 '-DDEBUG_TRAP=__asm__(int $3)' -DAVAHI_DAEMON_RUNTIME_DIR=\/var/run/avahi-daemon/\ -DAVAHI_SOCKET=\/var/run/avahi-daemon/socket\ -DAVAHI_SERVICE_DIR=\/etc/avahi/services\ -DAVAHI_CONFIG_FILE=\/etc/avahi/avahi-daemon.conf\ -DAVAHI_HOSTS_FILE=\/etc/avahi/hosts\ -DAVAHI_DBUS_INTROSPECTION_DIR=\/usr/share/avahi/introspection\ -DAVAHI_CONFIG_DIR=\/etc/avahi\ -g -O2 -Wall -W -Wextra -pedantic -pipe -Wformat -Wold-style-definition -Wdeclaration-after-statement -Wfloat-equal -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn -Wshadow -Wendif-labels -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Winline -fPIC -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -L/tmp/src/results/avahi/../expat/usr/lib -L/tmp/src/results/avahi/../gdbm/usr/lib -L/tmp/src/results/avahi/../libcap/usr/lib -o avahi-daemon avahi_daemon-main.o avahi_daemon-simple-protocol.o avahi_daemon-static-services.o avahi_daemon-static-hosts.o avahi_daemon-ini-file-parser.o avahi_daemon-setproctitle.o avahi_daemon-check-nss.o avahi_daemon-chroot.o avahi_daemon-caps.o ../avahi-common/libavahi-common.la ../avahi-core/libavahi-core.la -L/tmp/src/results/avahi/../libdaemon/usr/lib -lexpat -lcap -ldl ppc_4xx-gcc -I/tmp/src/avahi/avahi-0.6.22 -DDEBUG_TRAP=__asm__(\int \$3\) -DAVAHI_DAEMON_RUNTIME_DIR=\/var/run/avahi-daemon/\ -DAVAHI_SOCKET=\/var/run/avahi-daemon/socket\ -DAVAHI_SERVICE_DIR=\/etc/avahi/services\ -DAVAHI_CONFIG_FILE=\/etc/avahi/avahi-daemon.conf\ -DAVAHI_HOSTS_FILE=\/etc/avahi/hosts\ -DAVAHI_DBUS_INTROSPECTION_DIR=\/usr/share/avahi/introspection\ -DAVAHI_CONFIG_DIR=\/etc/avahi\ -g -O2 -Wall -W -Wextra -pedantic -pipe -Wformat -Wold-style-definition -Wdeclaration-after-statement -Wfloat-equal -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn -Wshadow -Wendif-labels -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Winline -fPIC -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -o .libs/avahi-daemon avahi_daemon-main.o avahi_daemon-simple-protocol.o avahi_daemon-static-services.o avahi_daemon-static-hosts.o avahi_daemon-ini-file-parser.o avahi_daemon-setproctitle.o avahi_daemon-check-nss.o avahi_daemon-chroot.o avahi_daemon-caps.o -L/tmp/src/results/avahi/../expat/usr/lib -L/tmp/src/results/avahi/../gdbm/usr/lib -L/tmp/src/results/avahi/../libcap/usr/lib ../avahi-common/.libs/libavahi-common.so ../avahi-core/.libs/libavahi-core.so -L/tmp/src/results/avahi/../libdaemon/usr/lib /usr/lib/libexpat.so -lcap -ldl /usr/lib/libexpat.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[3]: *** [avahi-daemon] Error 1 make[3]: Leaving directory `/tmp/src/avahi/.build/avahi-daemon' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/src/avahi/.build' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/src/avahi/.build' make: *** [build] Error 2 The most obvious potential problem was that /tmp/src/results/avahi/../expat/usr/lib did not exist or contain the desired libraries at the time of build or configuration; however, I have verified that the directory and libraries are, in fact, there. Another potential issue would be -L/usr/lib¹ getting in the argument list ahead of -L/tmp/src/results/avahi/../expat/usr/lib¹. However, that doesn¹t seem to be the case either. If I pass --debug¹ to libtool, it seems to find the correct /tmp/src/results/avahi/../expat/usr/lib/libexpat.la¹ file; however, it latter seems to ignore that and pick-up /usr/lib/libexpat.so¹ anyway: + deplibs='-L/home/gerickson/src/clients/netapp/yours/p4/prod/oob/main/results/k
Re: GNU Libtool 2.1b released (alpha release)
Quoting Gary V. Vaughan [EMAIL PROTECTED]: With only one bug reported and fixed since Feb 1, either this is the most spectacularly well engineered release in the history of libtool, or else it is the least well tested release ever... For what it's worth, swfdec and swfdec-mozilla are fine with libtool CVS trunk. Even make distcheck passes. x86_64, Fedora 8 with all updates. No exotic unices, sorry. -- Regards, Pavel Roskin ___ http://lists.gnu.org/mailman/listinfo/libtool
