RE: HEAD testsuite.
Gary V. Vaughan <> wrote: > 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 Aye... This made me dig a little deeper, and i found that i had a damaged ln in my PATH... Arg... Thanks anyway, now a whole lot of fails disappeared. Cheers, Markus ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
Let me see if I can clarify what we are attempting to accomplish, sorry if I was not clear in the beginning. o the desire is to create a completely agnostic library that has no dependence on Cstd or stlport4 for the following reasons: * we don't use any STL in the OMPI C++ library * we want libraries or application that link against the OMPI C++ library to be able to choose which ever STL library they want The key point seems to be that having the OMPI C++ library link against either one of the STL libraries automatically includes some kind of dependencies and/or bootstrapping from that STL library, making downstream libraries/applications to use the same STL that OMPI's C++ library was created with. Attached is a simple tarball that tests several combinations: - Create a trivial C++ library (that uses no STL) in several different ways: --library=Crun --library=Cstd --library=stlport4 target: build_clean - Compiles a trivial C++ application (that uses no STL) against the above libraries. target: run_clean - Runs the trivial C++ applications (that uses no STL) and shows that an application compiled including stlport against a library that has Cstd will dump at runtime target: build_std - Compiles a trivial C++ application (that usesd STL) against the above libraries. Shows that when attempting to compile the trivial program against the stlport4 library will result in an error testprog.tar.gz Description: GNU Zip compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
In regard to: Re: Sun Studio: STL libraries, Dan Lacher said (at 1:05pm on...: Sorry, I forgot the last point: As a result, we need a way to have Libtool not link in any STL library at all. How can we do this? Thanks for clarifying what you're trying to accomplish. What happens if you use CXXFLAGS="-library=%none -library=no%libC" Does libtool still thwart your efforts? 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: AIX: More troubles
Another problem: If -brtl is used on the flags, it doesn't build shared
libraries. Why is this the case, and could there be a way to still
output shared libraries regardless?
Daniel Sands wrote:
I have an executable that dlopens modules, and the modules make use
of symbols provided by the executable. Since AIX does not export
symbols unless either it has to (if needed for direct linkage to a
shared object) or you REALLY want it to (either by -bexpall or by
providing an exports list), these symbols don't resolve. So it
either crashes (if compiled without -brtl) or complains about
unresolved references. Is there a Libtool-standard way to make the
executable export all of its symbols?
The standard is to add libtool flag -export-dynamic to executable
LDFLAGS but may be libtool is not ported to you linker.
For GNU linker:
./libtool --config | grep export_dynamic
export_dynamic_flag_spec="\${wl}--export-dynamic"
Roumen
.
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
Sorry, I forgot the last point: As a result, we need a way to have Libtool not link in any STL library at all. How can we do this? Dan Lacher wrote: Let me see if I can clarify what we are attempting to accomplish, sorry if I was not clear in the beginning. o the desire is to create a completely agnostic library that has no dependence on Cstd or stlport4 for the following reasons: * we don't use any STL in the OMPI C++ library * we want libraries or application that link against the OMPI C++ library to be able to choose which ever STL library they want The key point seems to be that having the OMPI C++ library link against either one of the STL libraries automatically includes some kind of dependencies and/or bootstrapping from that STL library, making downstream libraries/applications to use the same STL that OMPI's C++ library was created with. Attached is a simple tarball that tests several combinations: - Create a trivial C++ library (that uses no STL) in several different ways: --library=Crun --library=Cstd --library=stlport4 target: build_clean - Compiles a trivial C++ application (that uses no STL) against the above libraries. target: run_clean - Runs the trivial C++ applications (that uses no STL) and shows that an application compiled including stlport against a library that has Cstd will dump at runtime target: build_std - Compiles a trivial C++ application (that usesd STL) against the above libraries. Shows that when attempting to compile the trivial program against the stlport4 library will result in an error ___ http://lists.gnu.org/mailman/listinfo/libtool ___ 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 1:05pm > on...: > >> Sorry, I forgot the last point: As a result, we need a way to have >> Libtool not link in any STL library at all. How can we do this? > > Thanks for clarifying what you're trying to accomplish. > > What happens if you use > > CXXFLAGS="-library=%none -library=no%libC" > > Does libtool still thwart your efforts? Seems probable. Workaround for now is to edit libtool after it is generated, changing postdeps so it is empty. Not sure what to do in the general case. Can either: 1) Allow the setting of a cache var to select if these are added. (something like attached patch). 2) Only add the -library=Cstd -library=Crun etc if building with no undefined symbols. Toughts? Peter -- Peter O'Gorman http://pogma.com Index: libtool.m4 === RCS file: /sources/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.196 diff -u -r1.314.2.196 libtool.m4 --- libtool.m4 1 Feb 2008 16:58:19 - 1.314.2.196 +++ libtool.m4 7 Feb 2008 22:13:01 - @@ -4015,15 +4015,17 @@ # Sun C++ 5.9 # # 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 -if test "$solaris_use_stlport4" != yes; then +# incompatible with the Cstd library. +AC_CACHE_CHECK([if we need to add -library=Cstd -library=Crun], + [lt_cv_add_cstd_crun],[ + lt_cv_add_cstd_crun=yes + case " $CXX $CXXFLAGS " in + *" -library=stlport4 "*) +lt_cv_add_cstd_crun=no +;; + esac +]) +if test "$lt_cv_add_cstd_crun" != no; then _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' fi ;; @@ -4033,20 +4035,19 @@ 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 +AC_CACHE_CHECK([if we need to add -library=Cstd -library=Crun], + [lt_cv_add_cstd_crun],[ + lt_cv_add_cstd_crun=yes + case " $CXX $CXXFLAGS " in + *" -library=stlport4 "*) +lt_cv_add_cstd_crun=no +;; + esac +]) +if test "$lt_cv_add_cstd_crun" != no; then _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' fi ;; ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: AIX: More troubles
Roumen Petrov wrote:
Daniel Sands wrote:
I have an executable that dlopens modules, and the modules make use of
symbols provided by the executable. Since AIX does not export symbols
unless either it has to (if needed for direct linkage to a shared
object) or you REALLY want it to (either by -bexpall or by providing
an exports list), these symbols don't resolve. So it either crashes
(if compiled without -brtl) or complains about unresolved references.
Is there a Libtool-standard way to make the executable export all of
its symbols?
The standard is to add libtool flag -export-dynamic to executable
LDFLAGS but may be libtool is not ported to you linker.
For GNU linker:
./libtool --config | grep export_dynamic
export_dynamic_flag_spec="\${wl}--export-dynamic"
Roumen
Since Daniel's e-mail address return mails - reason: User unknown
so I quote response.
You're right: On AIX this flag is blank. I'm also scratching my head
> because I'm sure I got a successful run without -brtl once the symbols
> were exported. But today that is not the case: Both the library and
> the executable must be built with -brtl if the library references
> symbols within the executable. So those flags should also be added to
> the AIX platform. Basically, -bexpall (or do the nm > exports trick)
> on executables, and -brtl on everything.
I could not help him to resolve issue (I don't have access to AIX, nor
experience ).
Daniel please find attached file bootstrap.sh.gz with sample code and
build based on autotools. The sample is strip down of C++ version.
Please could you adapt to you host environment and post result to list
so that people with experience on AIX to help you.
Also it is wort to try libtool version 1.2.26 where AIX support is
improved or may be to check 2.1b since it will be rool up soon.
Roumen
bootstrap.sh.gz
Description: application/gzip
___
http://lists.gnu.org/mailman/listinfo/libtool
CVS HEAD test 30
I'm getting an "UNEXPECTED PASS" on test 30 of the new test suite on my UnixWare 7.1.4 box. A testlog generated with "gmake check-local TESTSUITEFLAGS='-d -x 30'" is attached. I don't seem to understand the new test suite well enough to figure this out. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]# -*- compilation -*- 30. archive-in-archive.at:26: testing ... + cat + 1> foo.c 0<< + cat + 1> bar.c 0<< + cd . + pwd + thisdir=/usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 + /usr/local/src/gnu/libtool-2.x/libtool --mode=compile --tag=CC cc -g -c -o foo.lo foo.c libtool: compile: cc -g -c foo.c -KPIC -DPIC -o .libs/foo.o libtool: compile: cc -g -c foo.c -o foo.o >/dev/null 2>&1 + /usr/local/src/gnu/libtool-2.x/libtool --mode=compile --tag=CC cc -g -c -o bar.lo bar.c libtool: compile: cc -g -c bar.c -KPIC -DPIC -o .libs/bar.o libtool: compile: cc -g -c bar.c -o bar.o >/dev/null 2>&1 + /usr/local/src/gnu/libtool-2.x/libtool --mode=link --tag=CC --tag=disable-shared cc -g -o libfoo.la foo.lo -version-info 1:0:0 -rpath /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 libtool: link: ar cru .libs/libfoo.a foo.o libtool: link: : .libs/libfoo.a libtool: link: ( cd ".libs" && rm -f "libfoo.la" && ln -s "../libfoo.la" "libfoo.la" ) + /usr/local/src/gnu/libtool-2.x/libtool --mode=install cp libfoo.la /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 libtool: install: cp .libs/libfoo.lai /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30/libfoo.la libtool: install: cp .libs/libfoo.a /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30/libfoo.a libtool: install: chmod 644 /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30/libfoo.a libtool: install: : /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30/libfoo.a -- Libraries have been installed in: /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-R,LIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- + /usr/local/src/gnu/libtool-2.x/libtool --mode=link --tag=CC --tag=disable-shared cc -g -o libbar.la bar.lo ./libfoo.a -version-info 1:0:0 -rpath /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 *** Warning: Linking the shared library libbar.la against the *** static library ./libfoo.a is not portable! libtool: link: ar cru .libs/libbar.a ./libfoo.a bar.o UX:ar: ERROR: ./libfoo.a is in archive format - embedded archives are not allowed + /usr/local/src/gnu/libtool-2.x/libtool --mode=install cp libbar.la /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 libtool: install: `libbar.la' is not a valid libtool archive libtool: install: Try `libtool --help --mode=install' for more information. /opt/src/gnu/libtool-2.x/tests/archive-in-archive.at:48: ar -t libbar.a | grep libfoo.a + grep libfoo.a + ar -t libbar.a stderr: UX:ar: ERROR: Archive libbar.a not found stdout: + ar -t libbar.a UX:ar: ERROR: Archive libbar.a not found + archive_contents='' 30. archive-in-archive.at:26: 30. static library contains static library (archive-in-archive.at:26): UNEXPECTED PASS(sys0m0.23s) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio: STL libraries
* Peter O'Gorman wrote on Thu, Feb 07, 2008 at 11:15:57PM CET: > Tim Mooney wrote: > > CXXFLAGS="-library=%none -library=no%libC" > Not sure what to do in the general case. Can either: > > 1) Allow the setting of a cache var to select if these are added. > (something like attached patch). I prefer that. But I'd prefer a cache variable to be general, in the sense of setting the C++ library not only for the Sun compiler, and not only on Solaris. There have been users complaining that they want only libsupc++ instead of libstdc++ with g++. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: AIX: More troubles
> >Daniel Sands wrote: > >>I have an executable that dlopens modules, and the modules make use > >>of symbols provided by the executable. Since AIX does not export > >>symbols unless either it has to (if needed for direct linkage to a > >>shared object) or you REALLY want it to (either by -bexpall or by > >>providing an exports list), these symbols don't resolve. So it > >>either crashes (if compiled without -brtl) or complains about > >>unresolved references. Is there a Libtool-standard way to make the > >>executable export all of its symbols? I know about this issue on AIX. What I don't know yet is why the normal exporting of all symbols doesn't work out of the box (it should, for AIX always_export_symbols is set), and when I will have time to look into it. Does adding -export-symbols-regex ".*" serve as a portable workaround? I suppose you can work around it on AIX by adding -Wl,-bexpall to LDFLAGS? * NOT SPAM wrote on Thu, Feb 07, 2008 at 09:07:28PM CET: > Another problem: If -brtl is used on the flags, it doesn't build shared > libraries. Why is this the case, and could there be a way to still > output shared libraries regardless? First, please do not top-post. Second, please do not hijack unrelated threads. Third, I'm not sure what you mean, as shared libraries are built with or without -brtl, just that /without/ it, they are named libfoo.a (just as AIX does with its own shared libraries). Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: CVS HEAD test 30
Hi Tim, * Tim Rice wrote on Fri, Feb 08, 2008 at 03:00:05AM CET: > > I'm getting an "UNEXPECTED PASS" on test 30 of the new test suite > on my UnixWare 7.1.4 box. > > A testlog generated with "gmake check-local TESTSUITEFLAGS='-d -x 30'" is > attached. Thanks for the bug report. I've installed this patch. Cheers, Ralf 2008-02-08 Ralf Wildenhues <[EMAIL PROTECTED]> * tests/archive-in-archive.at (static library contains static library): Test also the actual broken link command, and the following install command, as UnixWare ar rightly refuses to put an archive into an archive. Report by Tim Rice. Index: tests/archive-in-archive.at === RCS file: /cvsroot/libtool/libtool/tests/archive-in-archive.at,v retrieving revision 1.1 diff -u -r1.1 archive-in-archive.at --- tests/archive-in-archive.at 4 Jun 2007 03:01:11 - 1.1 +++ tests/archive-in-archive.at 8 Feb 2008 06:53:45 - @@ -1,6 +1,6 @@ # dmacks.at -- test for dmacks bug -*- Autotest -*- # -# Copyright (C) 2007 Free Software Foundation, Inc. +# Copyright (C) 2007, 2008 Free Software Foundation, Inc. # Written by Peter O'Gorman, 2007 # # This file is part of GNU Libtool. @@ -42,9 +42,10 @@ $LIBTOOL --mode=link --tag=CC --tag=disable-shared $CC $CFLAGS $LDFLAGS \ -o libfoo.la foo.lo -version-info 1:0:0 -rpath $thisdir $LIBTOOL --mode=install cp libfoo.la $thisdir -$LIBTOOL --mode=link --tag=CC --tag=disable-shared $CC $CFLAGS $LDFLAGS \ --o libbar.la bar.lo ./libfoo.a -version-info 1:0:0 -rpath $thisdir -$LIBTOOL --mode=install cp libbar.la $thisdir +AT_CHECK([$LIBTOOL --mode=link --tag=CC --tag=disable-shared $CC $CFLAGS $LDFLAGS \ +-o libbar.la bar.lo ./libfoo.a -version-info 1:0:0 -rpath $thisdir], +[], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=install cp libbar.la $thisdir], [], [ignore], [ignore]) AT_CHECK([ar -t libbar.a | grep libfoo.a],[1],[ignore],[ignore]) archive_contents=`ar -t libbar.a` AT_XFAIL_IF([case "$archive_contents" in *"libfoo.a"*) : ;; esac]) ___ http://lists.gnu.org/mailman/listinfo/libtool
