discard “Configured with” line from gcc -v output
Since the latest libtool update in GCC, I've had problems building libstdc++-v3 on x86_64-linux-gnu. The symptom was an incomplete link command line, resulting from a trailing «'» character in a -L flag added by libtool. It turned out to be improperly auto-detected from the gcc -shared -v output. The issue is that, after zero or perhaps more reconfigurations of the gcc top-level, the arguments passed to the gcc configure, and that are reported by gcc -v in the build tree, look like this: Configured with: ../configure --cache-file=./config.cache -C --prefix=/l/tmp/build/toolchains/x86_64-linux-gnu --enable-checking --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt-but=gtk --disable-dssi --enable-plugin-but --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --disable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic CC='ccache gcc -fno-working-directory -m64' CXX='ccache g++ -fno-working-directory -m64' CCC='ccache g++ -fno-working-directory -m64' target_alias=x86_64-unknown-linux-gnu CFLAGS='-g -O2' LDFLAGS= CXXFLAGS='-g -O2' 'CC_FOR_TARGET=distccrel /l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/xgcc -B/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/' 'CXX_FOR_TARGET=distccrel /l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/g++ -B/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/ -nostdinc++ -L/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs' 'GCJ_FOR_TARGET=distccrel /l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/gcj -B/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/' 'GFORTRAN_FOR_TARGET=distccrel /l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/gfortran -B/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/' AR_FOR_TARGET=ar AS_FOR_TARGET=as DLLTOOL_FOR_TARGET=dlltool LD_FOR_TARGET=ld LIPO_FOR_TARGET=lipo NM_FOR_TARGET=nm OBJDUMP_FOR_TARGET=objdump RANLIB_FOR_TARGET=ranlib STRIP_FOR_TARGET=strip WINDRES_FOR_TARGET=windres WINDMC_FOR_TARGET=windmc --enable-languages=c,ada,c++,fortran,java,objc --no-create --no-recursion The attentive reader will notice the -L flag at the end of CXX_FOR_TARGET. libtool.m4 is not clever enough to realize that the trailing «'» is just closing the one before CXX_FOR_TARGET, and to disregard the whole thing, so it takes the argument at face value, with a trailing apostrophe and all. That doesn't quite work. The fix I came up with was to avoid lines that didn't contain the information libtool was interested in. It turns out that only lines started with blanks contain the actual commands line that GCC runs, so I narrowed the grep for -L flags to such lines. Here's what I'm going to installing in the GCC tree momentarily. I suggest libtool to adopt something along the same lines. for ChangeLog from Alexandre Oliva aol...@redhat.com * libtool.m4 (output_verbose_link_cmd): Require leading blank, and blank before -L. for gcc/ChangeLog from Alexandre Oliva aol...@redhat.com * configure: Rebuilt with modified libtool.m4. for libstdc++-v3/ChangeLog from Alexandre Oliva aol...@redhat.com * configure: Rebuilt with modified libtool.m4. for boehm-gc/ChangeLog from Alexandre Oliva aol...@redhat.com * configure: Rebuilt with modified libtool.m4. for libjava/ChangeLog from Alexandre Oliva aol...@redhat.com * configure: Rebuilt with modified libtool.m4. Index: libtool.m4 === --- libtool.m4.orig 2009-09-07 04:31:45.0 -0300 +++ libtool.m4 2009-09-07 04:33:09.0 -0300 @@ -5471,7 +5471,7 @@ if test $_lt_caught_CXX_error != yes; # Commands to make compiler produce verbose output that lists # what hidden libraries, object files and flags are used when # linking a shared library. - output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 21 | $GREP \-L' + output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 21 | $GREP ^ .* -L' else GXX=no @@ -5716,7 +5716,7 @@ if test $_lt_caught_CXX_error != yes; # explicitly linking system object files so we need to strip them # from the output so that they don't get included in the library # dependencies. -output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 21) | $EGREP \-L`; list=; for z in $templist; do case $z in conftest.$objext) list=$list $z;; *.$objext);; *) list=$list $z;;esac; done; $ECHO X$list | $Xsed' +output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 21) | $GREP ^ .* -L`; list=; for z in $templist; do case $z in conftest.$objext) list=$list $z;; *.$objext);; *) list=$list $z;;esac; done; $ECHO X$list | $Xsed' ;; *) if test $GXX
Re: discard “Configured with” line from gcc -v output
On Sep 8, 2009, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Alexandre Oliva wrote on Tue, Sep 08, 2009 at 05:17:28PM CEST: The symptom was an incomplete link command line, resulting from a trailing «'» character in a -L flag added by libtool. FWIW, it is not clear to me why this shouldn't have hurt you earlier. I was just as surprised. I couldn't find any particular change that would have exposed this latent problem. It *could* be related with the upgrade to a newer autoconf in GCC, which might in turn have started adding more variables to the config.status --recofigure command line. Here's what I'm going to installing in the GCC tree momentarily. I suggest libtool to adopt something along the same lines. The patch is not ok for upstream Libtool, which unfortunately also has to support other compilers that pretend to be GCC, but produce different '-v -shared' output (ICC and PathScale are in this boat IIRC). ICC won't match your changed grep, I think. Yes, it's ugly and they should be punished for being an imperfect impersonation, but that's not something you can tell users. :-) Have you checked older GCC versions for the format? Not really, although I'm pretty sure this leading whitespace oddity has bugged me for a very long time. But given the above, it shouldn't really matter. One possibility would be to grep out Configured with lines. I'll look into it. That ought to work. Thanks! -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[SCM] GNU Libtool annotated tag, release-1-3-2, deleted. release-1-3-1-13-g453b778
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The annotated tag, release-1-3-2 has been deleted was 3d22b623e62dd494382e05a8e66213c397f518f9 --- tag release-1-3-2 Tagger: Alexandre Oliva [EMAIL PROTECTED] Date: Wed May 26 00:28:32 1999 + 453b778addf1c4da6062e83128451577e5329aff * configure.in: Bumped to 1.3.2. --- hooks/post-receive -- GNU Libtool ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
[SCM] GNU Libtool annotated tag, multi-language-fork, deleted. automake_1-4-515-gfad95cc
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The annotated tag, multi-language-fork has been deleted was f75f53d202ac4f8adb15c291939b511019d5c979 --- tag multi-language-fork Tagger: Alexandre Oliva [EMAIL PROTECTED] Date: Fri Dec 3 03:21:29 1999 + fad95cc179f3861f1da488fb979d0d5aedba6523 * ltconfig.in (ac_compile): Use $ac_ext instead of .c. (ac_link): Likewise. (dlfcn.h, ac_try): Do not add filename, it is already in ac_compile. Reported by Stephane Conversy [EMAIL PROTECTED] --- hooks/post-receive -- GNU Libtool ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
[SCM] GNU Libtool annotated tag, multi-language-fork, created. multi-language-fork
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The annotated tag, multi-language-fork has been created at e993633d6fbe756826b998951c82ca8cb842b9a7 (tag) tagging 4b1b95eabf46e7b994adecb5667f73a2b9fb9d8a (commit) replaces release-1-3b tagged by Gary V. Vaughan on Thu Apr 17 13:08:59 2008 -0400 - Log - multi-language-fork Albert Cheng (1): * ltmain.in (shlibpath_var): ensure the variable is non-empty before Alexandre Oliva (13): * doc/libtool.texi (Porting inter-library dependencies): Typos * ltmain.in: Fix creation of relative links to object files in * libltdl/COPYING.LIB: Update to version 2.1. * ltconfig.in (CDPATH): Set to `:' instead of empty. * libltdl/ltdl.c (lt_dlopen): Do not search paths when the * configure.in: Move ltconfig and ltmain.sh generation back... * tests/sh.test: New test to detect uses of quotes within * libtool.m4: Do not AC_SUBST anything other than LIBTOOL. * ltconfig.in (irix6*): Do not override deplibs_check_method * configure.in: AC_SUBST variables that are used by ltconfig to * libtool.m4: Use host when --target is not specified. * ltconfig.in (linux-gnu*): Disable hardcode_into_libs until it * ltconfig.in (ac_compile): Use $ac_ext instead of .c. Bert Driehuis (1): * ltconfig.in: Updated bsdi4 soname specs to be more like Donald Anderson (1): * ltconfig.in (sco3.2v5): use pass_all deplibs_check_method Erez Zadok (2): * doc/PLATFORMS: Updated mostly *bsd platforms. * doc/PLATFORMS (i*86-*openbsd2.5): New platform. Gary V. Vaughan (18): * configure.in: bumped version to 1.3c. * README-alpha: improved the release instructions to mention * configure.in (AC_PROG_RANLIB): No longer required as we now use * libtool.m4 (mingw*, AC_PROG_LD): use tr for carriage return * ltconfig.in (ltdll.c, impgen.c): Prevent the shell from * ltconfig.in (whole-archive-flag-spec): test whether the * ltconfig.in (whole-archive-flag-spec): I had been * libtool.m4: be sure to AC_SUBST values no longer tested in * configure.in (AC_OUTPUT_COMMANDS): generate ltmain.sh * ltconfig.in: Set $FILE to @FILE@ for substitution with * ltmain.in (-no-fast-install): Wrapper script used to add the * ltmain.in (-no-install): This doesn't work on win32 since * NEWS: updtaed. * libtool.m4 (AC_PATH_PROG_VERSION_GREP): removed in favour of the * libtool.m4 (AC_PATH_FILE): new macro replaces * ltmain.in: Damnit! Cygwin cvs committed all the * libtool.m4: better use of $target instead of $host to support * ltconfig.in: Be friendlier to C++ compilers when testing Manfred Weichel (1): * ltconfig.in (sysv5): Added support required for shared Michael Forster (1): * ltconfig.in (linux-gnu*): Set hardcode_into_libs=yes. Mumit Khan (1): * ltconfig.in: Read line at a time to avoid tokenisation by Olly Betts (9): * doc/libtool.texi (C++ Libraries): fixed a typo. * NEWS: Note new user visible changes. * libtool.m4(cygwin mingw32, AC_LIBTOOL_SETUP): On second * libtool.m4(cygwin mingw32, AC_LIBTOOL_SETUP): Oops. Fix some * ltconfig.in(cygwin mingw32, archive_expsym_cmds): Only compile * libtool.m4 (AC_PROG_LD): strip carriage returns from the * doc/libtool.texi (Compile mode): typo correction. * libtool.m4: Third time lucky, with Tor's patch. * ltconfig.in (opt_cr): Handle crlf sequences output by the Pavel Roskin (2): * ltmain.in: Ensure that gcc on HPsUX uses -fPIC, or else Added pending patches file to mail subdir Stephane Conversy (1): * ltmain.in (-DPIC): changed the order of pic flags a little to Thomas Tanner (7): * doc/PLATFORMS: 1.3b passes all tests on cygwin * NEWS, TODO: updated (pic flags) * NEWS: mention fixes * ltmain.in: don't ignore convenience libraries for objects/archives * NEWS: new -no-install flag * NEWS: updated * configure.in: generate ltconfig and ltmain.sh before configuring Tor Lillqvist (2): * libtool.m4: test command used == which should be =. * libtool.m4: these was a missing `*' in the -mno-cygwin Vadim (1): * ltconfig.in (sysv): More UW7 support. --- hooks/post-receive -- GNU Libtool ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
[SCM] GNU Libtool annotated tag, release-1-3, created. release-1-3
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The annotated tag, release-1-3 has been created at 70b19aae7c43fe4894e88cad7c502d4113ce4385 (tag) tagging 1340c3dc7b314bb1f90294794d4eb17e3ae66d18 (commit) tagged by Gary V. Vaughan on Thu Apr 17 13:37:20 2008 -0400 - Log - 1.3 Alexandre Oliva (385): * demo/Makefile.am (objdir): there are no longer quotes around * libtool.m4 (CFLAGS): check whether -belf is needed on SCO, as * autogen: new script; run it to bootstrap libtool after checking * AUTHORS: added myself as a co-maintainer * ltmain.in (libobj): default value must not contain directory added a few extra headers for gnus * ltmain.in: correctly create libraries and programs with thou shalt not commit before make check :-) added a suggestion of how to create shared libraries with undefined symbols * THANKS: Added Eric Estievenart * ltconfig.in (need_locks): if neither `-c -o' nor hard links are * THANKS: Added Marc J. Fraioli * ltconfig.in (compiler_o_lo): check whether we can write directly * ltconfig.in (hardcode_minus_L): Revert Ian's patch for * libtool.m4 (sco): fix typo * ltconfig.in: On AIX, don't treat GNU ld specially. 1998-11-04 Alexandre Oliva [EMAIL PROTECTED] * THANKS: Added Thomas Tanner and Gary V. Vaughan moved from aix to c++ fixed installed * ltconfig.in: add --falback-echo, to be used if everything else * sh.test (test X): ensure that the double-quote supposed to be * ltconfig.in (sunos*, sympat, symxfrm): remove underscore * ltconfig.in: make use of '~' field separator in reload_cmds, * NEWS: updated * ltmain.in (IFS): revert Gary's patch when parsing version * NEWS: Mention -export-symbols and new dlpreopen * PORTING: Porting instructions are in the libtool manual already * ltmain.in (C_compiler): copy $CC before it is overwritten with * NEWS: -module and libtldl * ltmain.in (output_objdir): compute it from $output, not $arg * ltmain.in (installed): new variable defined within a .la file, * ltmain.in (installed): new variable defined within a .la file, * ltconfig.in (echo_test_string): the whole ltconfig script was * ltmain.in: missing `test' between `' and `$module' * mdemo/Makefile.am (hell_debug_LDFLAGS): -dlpreopen - -dlopen added message with -export-symbols syntax for various platforms * ltconfig.in (archive_cmds, osf3, osf4, solaris, sunos4): create * libltdl/ltdl.c: replace NULL with 0, so that we don't depend on * doc/PLATFORMS: updated last-tested release for platforms I've * ltconfig.in (echo): avoid shell error messages when we're * libtool.spec (URL): point to www.gnu.org Initial revision imported from autoconf CVS tree * ltconfig.in (solaris): do not use $CC for linking if GNU ld is * Makefile.am (mdemo_distfiles): libfoo[12].sym no longer exist * libtool.m4 (ac_cv_sys_symbol_underscore): `test a == b' doesn't * doc/libtool.texi (author): listed all the AUTHORS * configure.in: we no longer use PRCS C++ problems are documented * ltmain.in (convenience, deplibs): propagate dependencies * PORTING: removed the text Akim Demaille converted to .texi * configure.in (AC_CONFIG_SUBDIRS): added libltdl * ltmain.in (-DSTATIC): changed to -DLIBTOOL_STATIC, and defined * tests/Makefile.am (EXTRA_DIST): remove ltdl-*.test * demo/configure.in (BINARY_HELLDL): test whether dlopen is * libltdl/configure.in (stdlib.h, unistd.h, stdio.h): check * libltdl/Makefile.am (EXTRA_DIST): removed, nothing needed * THANKS: added Stephan Kulow; removed Gary V. Vaughan and Thomas * NEWS: Added Thomas Tanner and Gary V. Vaughan to the list of new * ltmain.in (-force-static, force_static): removed new file * Makefile.am (cvs-dist): our release tags are in lower case reverted addition of depdemo; it's completely unusable yet :-( * NEWS, configure.in, libtool.spec: Bumped to 1.2d for release missing colon at EOL cvs-dist: missing quotes in sed command * NEWS, configure.in, libtool.spec: Bumped to 1.2e for CVS * Makefile.am (SUBDIRS): prepend `.' to avoid am-recursive * libltdl/Makefile.am: install libltdl conditionally... * libltdl/Makefile.am: install libltdl conditionally... * ltmain.in (SP2NL, NL2SP): use `tr' magic to avoid passing very * ltconfig.in (cygwin, archive_cmds, archive_sym_cmds): Moved * ltmain.in (SP2NL, NL2SP): Don't delete empty lines, as this * ltmain.in (libobjs_save, oldobjs): when building an * libltdl/ltdl.c
[SCM] GNU Libtool annotated tag, autoconf_pre_2-13, deleted. start-10-ge17a168
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The annotated tag, autoconf_pre_2-13 has been deleted was 40127ffe60da20296fcaca0b292da94e1901590e --- tag autoconf_pre_2-13 Tagger: Alexandre Oliva [EMAIL PROTECTED] Date: Tue Dec 1 17:00:17 1998 + e17a1688be305b503b5f13374e6f8367dbeb9925 imported from autoconf CVS tree --- hooks/post-receive -- GNU Libtool ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
[SCM] GNU Libtool annotated tag, multi-language-merge-point, created. multi-language-merge-point
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The annotated tag, multi-language-merge-point has been created at cb5daad1957d375af11d4b3280995a568155df0b (tag) tagging 0d579bb3f6014bc7f91ea5578ab3aa7792e8bc73 (commit) replaces release-1-3b tagged by Gary V. Vaughan on Thu Apr 17 13:06:57 2008 -0400 - Log - multi-language-merge-point Akim Demaille (5): * libtool.m4: Adjust the copyright notice. * libtool.m4: Don't depend on Autoconf internals: * libtool.m4 (AC_PATH_TOOL_PREFIX): Similarly with * libtool.m4: s/[ t]*$// * ltmain.sh: Don't quote the argument of case/esac and Albert Cheng (1): * ltmain.in (shlibpath_var): ensure the variable is non-empty before Albert Chin (1): * ltcf-cxx.sh (archive_cmds) [HP-UX, GCC]: Link with -fPIC. Albert Chin-A-Young (3): * ltcf-cxx.sh (archive_cmds, irix): Added -Wl to -update_registry * ltcf-cxx.sh (old_archive_cmds): With IRIX C++ 7.3.1.1m, CC -ar * ltconfig.in: Handle case where /bin/nm -p outputs multiple Alexandre Oliva (95): * doc/libtool.texi (Porting inter-library dependencies): Typos * ltmain.in: Fix creation of relative links to object files in * libltdl/COPYING.LIB: Update to version 2.1. * ltconfig.in (CDPATH): Set to `:' instead of empty. * libltdl/ltdl.c (lt_dlopen): Do not search paths when the * configure.in: Move ltconfig and ltmain.sh generation back... * tests/sh.test: New test to detect uses of quotes within * libtool.m4: Do not AC_SUBST anything other than LIBTOOL. * ltconfig.in (irix6*): Do not override deplibs_check_method * configure.in: AC_SUBST variables that are used by ltconfig to * libtool.m4: Use host when --target is not specified. * ltconfig.in (linux-gnu*): Disable hardcode_into_libs until it * ltconfig.in (ac_compile): Use $ac_ext instead of .c. The beginnings of multi-compiler/language support in libtool. The beginnings of multi-compiler/language support in libtool. Change that is part of Alexandre's configuration tags patch but isn't Added this file. It contains all of the C compiler related Added this file. It contains C++ compiler related configuration Moved the contents of the ChangeLog of the head branch to this file so * configure.in: Bump version number to 1.4a, since this will * tagdemo/Makefile.am (lib_LTLIBRARIES): Moved libbaz.la from * libtool.m4 (_AC_PROG_LIBTOOL): Renamed from... * configure.in: Look for C++ compiler. * libtool.m4 (AC_LIBLTDL_CONVENIENCE, AC_LIBLTDL_INSTALLABLE): Adjust docs * configure.in (ACINCLUDE_M4_LIST): Removed libltdl/acinclude.m4. * ltmain.in (compile): When output object is in subdir, create * ltconfig.in: Make the output script executable after updating * ltmain.in: Output libobj file in a temporary file, then typo * ltmain.in (xform): Recognize *.class and *.java. * libtool.m4 (_AC_PROG_LIBTOOL): Run before AC_LIBTOOL_GCJ. * configure.in (GCJ): Check. * THANKS: Added Art Pope. * libtool.m4 (AM_PROG_GCJ): Quote it so that aclocal won't bring * configure.in (AM_PROG_GCJ): Re-enable, with definition copied * libtool.m4 (AC_LIBTOOL_GCJ): Require either AC_PROG_GCJ or * libtool.m4 (lt_cv_deplibs_check_method, freebsd): Do not depend * ltconfig.in (dynamic_linker, linux, powerpc): Do not disable * ltcf-c.sh (wlarc, netbsd, aout): Set wlarc to empty. * ltcf-c.sh, ltcf-cxx.sh: Check if -lc is necessary for building * ltcf-c.sh (linkopts): Don't set for test. * ltmain.in: Support GNU shtool's install. * ltmain.in (irix, major): Prepend a `.'. * ltmain.in (tagname): Use `case' instead of `grep' to infer it. * configure.in (AM_PROG_GCJ): Moved definition... * ltcf-c.sh (need_lc): Fix test message. Set wl for archive_cmds. * ltmain.in (shtool): Use echo|grep instead of expr, as in the * ltcf-c.sh, ltcf-cxx.sh, ltcf-gcj.sh (archive_cmds, * tests/link-2.test: Create hell.lo in the format expected by * demo/Makefile.am: Don't extract configuration variables directly * ltmain.in (variables_saved_for_relink): Attempt to unset them * tests/defs (CC): Extract from the libtool script. * tests/quote.test: Move the match test out of case statements, to * libtool.m4 (AM_PROG_GCJ): Removed. * ltconfig.in (enable_dlopen): Set to no when lt_cv_dlopen is no. * ltmain.in (newdlprefiles): Use dlname if it's available and * tests/mdemo-exec.test: Modify failure message. * ltdl.m4 (HAVE_LIBDL): Look for dlopen in -lsvld. * libltdl/ltdl.c (lt_dlopen): Set dlname from library_names
[SCM] GNU Libtool annotated tag, automake_1-4, created. automake_1-4
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The annotated tag, automake_1-4 has been created at f276c455108f436a79d360a5436ad799e1d8d93d (tag) tagging 67646eef648c64869164053c006f5efdbd358a6f (commit) tagged by Gary V. Vaughan on Thu Apr 17 14:44:09 2008 -0400 - Log - automake_1-4 Alexandre Oliva (120): * demo/Makefile.am (objdir): there are no longer quotes around * libtool.m4 (CFLAGS): check whether -belf is needed on SCO, as * autogen: new script; run it to bootstrap libtool after checking * AUTHORS: added myself as a co-maintainer * ltmain.in (libobj): default value must not contain directory added a few extra headers for gnus * ltmain.in: correctly create libraries and programs with thou shalt not commit before make check :-) added a suggestion of how to create shared libraries with undefined symbols * THANKS: Added Eric Estievenart * ltconfig.in (need_locks): if neither `-c -o' nor hard links are * THANKS: Added Marc J. Fraioli * ltconfig.in (compiler_o_lo): check whether we can write directly * ltconfig.in (hardcode_minus_L): Revert Ian's patch for * libtool.m4 (sco): fix typo * ltconfig.in: On AIX, don't treat GNU ld specially. 1998-11-04 Alexandre Oliva [EMAIL PROTECTED] * THANKS: Added Thomas Tanner and Gary V. Vaughan moved from aix to c++ fixed installed * ltconfig.in: add --falback-echo, to be used if everything else * sh.test (test X): ensure that the double-quote supposed to be * ltconfig.in (sunos*, sympat, symxfrm): remove underscore * ltconfig.in: make use of '~' field separator in reload_cmds, * NEWS: updated * ltmain.in (IFS): revert Gary's patch when parsing version * NEWS: Mention -export-symbols and new dlpreopen * PORTING: Porting instructions are in the libtool manual already * ltmain.in (C_compiler): copy $CC before it is overwritten with * NEWS: -module and libtldl * ltmain.in (output_objdir): compute it from $output, not $arg * ltmain.in (installed): new variable defined within a .la file, * ltmain.in (installed): new variable defined within a .la file, * ltconfig.in (echo_test_string): the whole ltconfig script was * ltmain.in: missing `test' between `' and `$module' * mdemo/Makefile.am (hell_debug_LDFLAGS): -dlpreopen - -dlopen added message with -export-symbols syntax for various platforms * ltconfig.in (archive_cmds, osf3, osf4, solaris, sunos4): create * libltdl/ltdl.c: replace NULL with 0, so that we don't depend on * doc/PLATFORMS: updated last-tested release for platforms I've * ltconfig.in (echo): avoid shell error messages when we're * libtool.spec (URL): point to www.gnu.org Initial revision imported from autoconf CVS tree * ltconfig.in (solaris): do not use $CC for linking if GNU ld is * Makefile.am (mdemo_distfiles): libfoo[12].sym no longer exist * libtool.m4 (ac_cv_sys_symbol_underscore): `test a == b' doesn't * doc/libtool.texi (author): listed all the AUTHORS * configure.in: we no longer use PRCS C++ problems are documented * ltmain.in (convenience, deplibs): propagate dependencies * PORTING: removed the text Akim Demaille converted to .texi * configure.in (AC_CONFIG_SUBDIRS): added libltdl * ltmain.in (-DSTATIC): changed to -DLIBTOOL_STATIC, and defined * tests/Makefile.am (EXTRA_DIST): remove ltdl-*.test * demo/configure.in (BINARY_HELLDL): test whether dlopen is * libltdl/configure.in (stdlib.h, unistd.h, stdio.h): check * libltdl/Makefile.am (EXTRA_DIST): removed, nothing needed * THANKS: added Stephan Kulow; removed Gary V. Vaughan and Thomas * NEWS: Added Thomas Tanner and Gary V. Vaughan to the list of new * ltmain.in (-force-static, force_static): removed new file * Makefile.am (cvs-dist): our release tags are in lower case reverted addition of depdemo; it's completely unusable yet :-( * NEWS, configure.in, libtool.spec: Bumped to 1.2d for release missing colon at EOL cvs-dist: missing quotes in sed command * NEWS, configure.in, libtool.spec: Bumped to 1.2e for CVS * Makefile.am (SUBDIRS): prepend `.' to avoid am-recursive * libltdl/Makefile.am: install libltdl conditionally... * libltdl/Makefile.am: install libltdl conditionally... * ltmain.in (SP2NL, NL2SP): use `tr' magic to avoid passing very * ltconfig.in (cygwin, archive_cmds, archive_sym_cmds): Moved * ltmain.in (SP2NL, NL2SP): Don't delete empty lines, as this * ltmain.in (libobjs_save, oldobjs): when building an * libltdl
[SCM] GNU Libtool annotated tag, release-1-2d, created. release-1-2d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The annotated tag, release-1-2d has been created at 409998bf99ad50e9bae46861d272f50e5921021f (tag) tagging bf8a4660a3a417893ca1879dee42f5b9dfef531e (commit) tagged by Gary V. Vaughan on Thu Apr 17 14:46:03 2008 -0400 - Log - 1.2d Alexandre Oliva (68): * demo/Makefile.am (objdir): there are no longer quotes around * libtool.m4 (CFLAGS): check whether -belf is needed on SCO, as * autogen: new script; run it to bootstrap libtool after checking * AUTHORS: added myself as a co-maintainer * ltmain.in (libobj): default value must not contain directory added a few extra headers for gnus * ltmain.in: correctly create libraries and programs with thou shalt not commit before make check :-) added a suggestion of how to create shared libraries with undefined symbols * THANKS: Added Eric Estievenart * ltconfig.in (need_locks): if neither `-c -o' nor hard links are * THANKS: Added Marc J. Fraioli * ltconfig.in (compiler_o_lo): check whether we can write directly * ltconfig.in (hardcode_minus_L): Revert Ian's patch for * libtool.m4 (sco): fix typo * ltconfig.in: On AIX, don't treat GNU ld specially. 1998-11-04 Alexandre Oliva [EMAIL PROTECTED] * THANKS: Added Thomas Tanner and Gary V. Vaughan moved from aix to c++ fixed installed * ltconfig.in: add --falback-echo, to be used if everything else * sh.test (test X): ensure that the double-quote supposed to be * ltconfig.in (sunos*, sympat, symxfrm): remove underscore * ltconfig.in: make use of '~' field separator in reload_cmds, * NEWS: updated * ltmain.in (IFS): revert Gary's patch when parsing version * NEWS: Mention -export-symbols and new dlpreopen * PORTING: Porting instructions are in the libtool manual already * ltmain.in (C_compiler): copy $CC before it is overwritten with * NEWS: -module and libtldl * ltmain.in (output_objdir): compute it from $output, not $arg * ltmain.in (installed): new variable defined within a .la file, * ltmain.in (installed): new variable defined within a .la file, * ltconfig.in (echo_test_string): the whole ltconfig script was * ltmain.in: missing `test' between `' and `$module' * mdemo/Makefile.am (hell_debug_LDFLAGS): -dlpreopen - -dlopen added message with -export-symbols syntax for various platforms * ltconfig.in (archive_cmds, osf3, osf4, solaris, sunos4): create * libltdl/ltdl.c: replace NULL with 0, so that we don't depend on * doc/PLATFORMS: updated last-tested release for platforms I've * ltconfig.in (echo): avoid shell error messages when we're * libtool.spec (URL): point to www.gnu.org Initial revision imported from autoconf CVS tree * ltconfig.in (solaris): do not use $CC for linking if GNU ld is * Makefile.am (mdemo_distfiles): libfoo[12].sym no longer exist * libtool.m4 (ac_cv_sys_symbol_underscore): `test a == b' doesn't * doc/libtool.texi (author): listed all the AUTHORS * configure.in: we no longer use PRCS C++ problems are documented * ltmain.in (convenience, deplibs): propagate dependencies * PORTING: removed the text Akim Demaille converted to .texi * configure.in (AC_CONFIG_SUBDIRS): added libltdl * ltmain.in (-DSTATIC): changed to -DLIBTOOL_STATIC, and defined * tests/Makefile.am (EXTRA_DIST): remove ltdl-*.test * demo/configure.in (BINARY_HELLDL): test whether dlopen is * libltdl/configure.in (stdlib.h, unistd.h, stdio.h): check * libltdl/Makefile.am (EXTRA_DIST): removed, nothing needed * THANKS: added Stephan Kulow; removed Gary V. Vaughan and Thomas * NEWS: Added Thomas Tanner and Gary V. Vaughan to the list of new * ltmain.in (-force-static, force_static): removed new file * Makefile.am (cvs-dist): our release tags are in lower case reverted addition of depdemo; it's completely unusable yet :-( * NEWS, configure.in, libtool.spec: Bumped to 1.2d for release missing colon at EOL cvs-dist: missing quotes in sed command Bruno Haible (1): * doc/libtool.texi (Tested platforms): broken `sed' programs David Heine (1): * ltmain.in (pass_all): actively pass the flags Eric Estievenart (2): * ltmain.in (output_obj): typo * doc/libtool.texi (Compile mode): Document that -o is fully Gary V. Vaughan (9): Fixed archive_cmd for cygwin32, mingw32, aix3 and aix4. Added LD path canonicalization. require AC_CANONICAL_HOST for path canonicalization Test for leading underscore on compiled symbols at configure time
[SCM] GNU Libtool annotated tag, release-1-2f, created. release-1-2f
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The annotated tag, release-1-2f has been created at 0d247ae6c56d33ecc663114b824c56a67049627f (tag) tagging d6b6c13f5b8ece8a1bad355637d65fc1a41aa64d (commit) tagged by Gary V. Vaughan on Thu Apr 17 13:38:36 2008 -0400 - Log - 1.2f Alexandre Oliva (296): * demo/Makefile.am (objdir): there are no longer quotes around * libtool.m4 (CFLAGS): check whether -belf is needed on SCO, as * autogen: new script; run it to bootstrap libtool after checking * AUTHORS: added myself as a co-maintainer * ltmain.in (libobj): default value must not contain directory added a few extra headers for gnus * ltmain.in: correctly create libraries and programs with thou shalt not commit before make check :-) added a suggestion of how to create shared libraries with undefined symbols * THANKS: Added Eric Estievenart * ltconfig.in (need_locks): if neither `-c -o' nor hard links are * THANKS: Added Marc J. Fraioli * ltconfig.in (compiler_o_lo): check whether we can write directly * ltconfig.in (hardcode_minus_L): Revert Ian's patch for * libtool.m4 (sco): fix typo * ltconfig.in: On AIX, don't treat GNU ld specially. 1998-11-04 Alexandre Oliva [EMAIL PROTECTED] * THANKS: Added Thomas Tanner and Gary V. Vaughan moved from aix to c++ fixed installed * ltconfig.in: add --falback-echo, to be used if everything else * sh.test (test X): ensure that the double-quote supposed to be * ltconfig.in (sunos*, sympat, symxfrm): remove underscore * ltconfig.in: make use of '~' field separator in reload_cmds, * NEWS: updated * ltmain.in (IFS): revert Gary's patch when parsing version * NEWS: Mention -export-symbols and new dlpreopen * PORTING: Porting instructions are in the libtool manual already * ltmain.in (C_compiler): copy $CC before it is overwritten with * NEWS: -module and libtldl * ltmain.in (output_objdir): compute it from $output, not $arg * ltmain.in (installed): new variable defined within a .la file, * ltmain.in (installed): new variable defined within a .la file, * ltconfig.in (echo_test_string): the whole ltconfig script was * ltmain.in: missing `test' between `' and `$module' * mdemo/Makefile.am (hell_debug_LDFLAGS): -dlpreopen - -dlopen added message with -export-symbols syntax for various platforms * ltconfig.in (archive_cmds, osf3, osf4, solaris, sunos4): create * libltdl/ltdl.c: replace NULL with 0, so that we don't depend on * doc/PLATFORMS: updated last-tested release for platforms I've * ltconfig.in (echo): avoid shell error messages when we're * libtool.spec (URL): point to www.gnu.org Initial revision imported from autoconf CVS tree * ltconfig.in (solaris): do not use $CC for linking if GNU ld is * Makefile.am (mdemo_distfiles): libfoo[12].sym no longer exist * libtool.m4 (ac_cv_sys_symbol_underscore): `test a == b' doesn't * doc/libtool.texi (author): listed all the AUTHORS * configure.in: we no longer use PRCS C++ problems are documented * ltmain.in (convenience, deplibs): propagate dependencies * PORTING: removed the text Akim Demaille converted to .texi * configure.in (AC_CONFIG_SUBDIRS): added libltdl * ltmain.in (-DSTATIC): changed to -DLIBTOOL_STATIC, and defined * tests/Makefile.am (EXTRA_DIST): remove ltdl-*.test * demo/configure.in (BINARY_HELLDL): test whether dlopen is * libltdl/configure.in (stdlib.h, unistd.h, stdio.h): check * libltdl/Makefile.am (EXTRA_DIST): removed, nothing needed * THANKS: added Stephan Kulow; removed Gary V. Vaughan and Thomas * NEWS: Added Thomas Tanner and Gary V. Vaughan to the list of new * ltmain.in (-force-static, force_static): removed new file * Makefile.am (cvs-dist): our release tags are in lower case reverted addition of depdemo; it's completely unusable yet :-( * NEWS, configure.in, libtool.spec: Bumped to 1.2d for release missing colon at EOL cvs-dist: missing quotes in sed command * NEWS, configure.in, libtool.spec: Bumped to 1.2e for CVS * Makefile.am (SUBDIRS): prepend `.' to avoid am-recursive * libltdl/Makefile.am: install libltdl conditionally... * libltdl/Makefile.am: install libltdl conditionally... * ltmain.in (SP2NL, NL2SP): use `tr' magic to avoid passing very * ltconfig.in (cygwin, archive_cmds, archive_sym_cmds): Moved * ltmain.in (SP2NL, NL2SP): Don't delete empty lines, as this * ltmain.in (libobjs_save, oldobjs): when building an * libltdl/ltdl.c
[SCM] GNU Libtool annotated tag, release-1-3-2, created. release-1-3-2
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The annotated tag, release-1-3-2 has been created at 1e0311748fd84597e697ace06c79d99110321119 (tag) tagging 97087392045d12b18115a5de72c1ac11de418d73 (commit) tagged by Gary V. Vaughan on Thu Apr 17 13:35:20 2008 -0400 - Log - 1.3.2 Alexandre Oliva (400): * demo/Makefile.am (objdir): there are no longer quotes around * libtool.m4 (CFLAGS): check whether -belf is needed on SCO, as * autogen: new script; run it to bootstrap libtool after checking * AUTHORS: added myself as a co-maintainer * ltmain.in (libobj): default value must not contain directory added a few extra headers for gnus * ltmain.in: correctly create libraries and programs with thou shalt not commit before make check :-) added a suggestion of how to create shared libraries with undefined symbols * THANKS: Added Eric Estievenart * ltconfig.in (need_locks): if neither `-c -o' nor hard links are * THANKS: Added Marc J. Fraioli * ltconfig.in (compiler_o_lo): check whether we can write directly * ltconfig.in (hardcode_minus_L): Revert Ian's patch for * libtool.m4 (sco): fix typo * ltconfig.in: On AIX, don't treat GNU ld specially. 1998-11-04 Alexandre Oliva [EMAIL PROTECTED] * THANKS: Added Thomas Tanner and Gary V. Vaughan moved from aix to c++ fixed installed * ltconfig.in: add --falback-echo, to be used if everything else * sh.test (test X): ensure that the double-quote supposed to be * ltconfig.in (sunos*, sympat, symxfrm): remove underscore * ltconfig.in: make use of '~' field separator in reload_cmds, * NEWS: updated * ltmain.in (IFS): revert Gary's patch when parsing version * NEWS: Mention -export-symbols and new dlpreopen * PORTING: Porting instructions are in the libtool manual already * ltmain.in (C_compiler): copy $CC before it is overwritten with * NEWS: -module and libtldl * ltmain.in (output_objdir): compute it from $output, not $arg * ltmain.in (installed): new variable defined within a .la file, * ltmain.in (installed): new variable defined within a .la file, * ltconfig.in (echo_test_string): the whole ltconfig script was * ltmain.in: missing `test' between `' and `$module' * mdemo/Makefile.am (hell_debug_LDFLAGS): -dlpreopen - -dlopen added message with -export-symbols syntax for various platforms * ltconfig.in (archive_cmds, osf3, osf4, solaris, sunos4): create * libltdl/ltdl.c: replace NULL with 0, so that we don't depend on * doc/PLATFORMS: updated last-tested release for platforms I've * ltconfig.in (echo): avoid shell error messages when we're * libtool.spec (URL): point to www.gnu.org Initial revision imported from autoconf CVS tree * ltconfig.in (solaris): do not use $CC for linking if GNU ld is * Makefile.am (mdemo_distfiles): libfoo[12].sym no longer exist * libtool.m4 (ac_cv_sys_symbol_underscore): `test a == b' doesn't * doc/libtool.texi (author): listed all the AUTHORS * configure.in: we no longer use PRCS C++ problems are documented * ltmain.in (convenience, deplibs): propagate dependencies * PORTING: removed the text Akim Demaille converted to .texi * configure.in (AC_CONFIG_SUBDIRS): added libltdl * ltmain.in (-DSTATIC): changed to -DLIBTOOL_STATIC, and defined * tests/Makefile.am (EXTRA_DIST): remove ltdl-*.test * demo/configure.in (BINARY_HELLDL): test whether dlopen is * libltdl/configure.in (stdlib.h, unistd.h, stdio.h): check * libltdl/Makefile.am (EXTRA_DIST): removed, nothing needed * THANKS: added Stephan Kulow; removed Gary V. Vaughan and Thomas * NEWS: Added Thomas Tanner and Gary V. Vaughan to the list of new * ltmain.in (-force-static, force_static): removed new file * Makefile.am (cvs-dist): our release tags are in lower case reverted addition of depdemo; it's completely unusable yet :-( * NEWS, configure.in, libtool.spec: Bumped to 1.2d for release missing colon at EOL cvs-dist: missing quotes in sed command * NEWS, configure.in, libtool.spec: Bumped to 1.2e for CVS * Makefile.am (SUBDIRS): prepend `.' to avoid am-recursive * libltdl/Makefile.am: install libltdl conditionally... * libltdl/Makefile.am: install libltdl conditionally... * ltmain.in (SP2NL, NL2SP): use `tr' magic to avoid passing very * ltconfig.in (cygwin, archive_cmds, archive_sym_cmds): Moved * ltmain.in (SP2NL, NL2SP): Don't delete empty lines, as this * ltmain.in (libobjs_save, oldobjs): when building an * libltdl/ltdl.c
Re: libtool 1.5 -static and installed libraries
On Sep 8, 2005, Howard Chu [EMAIL PROTECTED] wrote:
Ralf Wildenhues wrote:
Well, that behavior would be fine to me (and it would mean no changes to
the code, which is good!), but would not match our current
documentation:
| @item -static
| If @var{output-file} is a program, then do not link it against any
| uninstalled shared libtool libraries. If @var{output-file} is a
| library, then only create a static library.
AFAICS this has always been part of the documentation.
Indeed. And in libtool 1.4 (at least versions 1.4.2 and 1.4.3) the
behavior matched the documentation.
Yuck. I didn't know that. I guess I'll have to take that back, and
agree it is a regression.
If you want to link with static versions of uninstalled libraries,
that's relatively easy to accomplish: create a static-only version of
such libraries, with different names, perhaps even as convenience
archives, and link with them. Then you won't have to use -static for
linking, and this will take care of getting the shared version of
libdb linked in.
Tell me there's a libtool switch that does this for me and I may be OK
with it.
To create the convenienec archive, do exactly as you say below and
you'll get a convenience archive only. As long as you don't add a
`-rpath' argument, that is.
But right now we create a library with
libtool --mode=link -o libfoo.la $(OBJS)
and libtool decides what to name the shared and static libraries that
it creates. If there is no libtool switch to provide the behavior you
suggest then I think your suggestion is unreasonable.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool API suggestion: LTDL_SHLIB_PRE and/or char* ltdl_map_shared_name(const char* name)
On Aug 23, 2005, Albert Chin [EMAIL PROTECTED] wrote:
[2] ltdl.c from HEAD:
812 if (strncmp(p, -l, 2) == 0)
813 {
814 size_t name_len = 3+ /* lib */ LT_STRLEN (p
+ 2);
815 name = MALLOC (char, 1+ name_len);
816 if (name)
817 sprintf (name, lib%s, p+2);
818 }
From inspection, this appears wrong. It doesn't honor
$need_lib_prefix.
I don't think it should. need_lib_prefix refers to whether dlopen et
al support loading libraries that don't start with lib. It's
unrelated with what the linker (ld, not ld.so) does with `-lname' to
find the library to link with, which is what ltdl.c is trying to do
here. Prepending lib unconditionally here is the right thing to do,
unless the linker actually does something different. I don't know of
any linker that searches for say foo.a when given -lfoo.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5 -static and installed libraries
On Aug 29, 2005, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Howard, Alexandre, others, * Howard Chu wrote on Sun, Aug 28, 2005 at 10:19:03PM CEST: By default we link with -static so that our local libtool-generated libraries get statically linked. But we don't use -all-static; we don't want to alter the default linking for system-installed libraries. OK. AFAIK, -static and -all-static are not supposed to distinguish installed from non-installed libraries. -all-static means, do not, ever, link in a shared library. -static means just prefer static libraries, but if one library is not available in static form, go ahead with the dynamic version instead. And this is exactly the behavior you're getting. If you want to link with static versions of uninstalled libraries, that's relatively easy to accomplish: create a static-only version of such libraries, with different names, perhaps even as convenience archives, and link with them. Then you won't have to use -static for linking, and this will take care of getting the shared version of libdb linked in. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 1.5 release
On Apr 23, 2005, Ralf Wildenhues [EMAIL PROTECTED] wrote: -New in 1.5.15a: 2005-??-??; CVS version 1.5.15a, Libtool team: +New in 1.5.16: 2005-04-23; CVS version 1.5.15a, Libtool team: Erhm... If this is going out soon, could we perhaps get the patch I posted for libtool.m4 in, to avoid configuring CXX and F77 in every single libtool script, part of packages that only care about C? For reference: Index: ChangeLog from Alexandre Oliva [EMAIL PROTECTED] * libtool.m4 (_LT_AC_TAGCONFIG): Don't bring in CXX and F77 unless the corresponding AC_PROG_ macro was provided. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.81 diff -u -p -r1.314.2.81 libtool.m4 --- libtool.m4 15 Apr 2005 14:40:09 - 1.314.2.81 +++ libtool.m4 17 Apr 2005 04:49:36 - @@ -1701,6 +1701,7 @@ if test -f $ltmain test -n $tagnam echo appending configuration tag \$tagname\ to $ofile case $tagname in +AC_PROVIDE_IFELSE([AC_PROG_CXX],[ CXX) if test -n $CXX ( test X$CXX != Xno ( (test X$CXX = Xg++ `g++ -v /dev/null 21` ) || @@ -1711,6 +1712,8 @@ if test -f $ltmain test -n $tagnam fi ;; +])dnl +AC_PROVIDE_IFELSE([AC_PROG_F77],[ F77) if test -n $F77 test X$F77 != Xno; then AC_LIBTOOL_LANG_F77_CONFIG @@ -1719,6 +1722,7 @@ if test -f $ltmain test -n $tagnam fi ;; +])dnl GCJ) if test -n $GCJ test X$GCJ != Xno; then AC_LIBTOOL_LANG_GCJ_CONFIG -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
don't force CXX and F77 to be configured in
Currently, at least in the 1.5 branch, a configure.ac as simple as:
configure.ac
Description: Binary data
causes libtool to be configured for CXX and F77, in addition to the
implicitly requested CC tag.
That's caused by an undesirable interaction between _LT_AC_TAGCONFIG
and the code that detects whether AC_PROG_{CXX,F77} were used:
_LT_AC_TAGCONFIG expands unconditionally macros that AC_REQUIRE
AC_PROG_CXX and AC_PROG_F77, such that the test whether they are
provided always results positive.
This patch avoids expanding the AC_REQUIREing macros if they haven't
been explicitly brought in before, using the same logic as the
existing test, thereby fixing the problem. Ok to install?
Incidentally, I noticed that, even after the fix, adding AC_PROG_CXX
or AC_PROG_F77 after AC_PROG_LIBTOOL doesn't trigger the autoconf
AC_BEFORE error I expected; it instead now causes a configure-time
error because the CXX and F77 sections of _LT_AC_TAGCONFIG are
missing. I wish we could do better than this, but I couldn't quite
figure out how.
(Ralf, thanks for picking up the patch I posted a couple of weeks ago,
and sorry for not completing the work before noticing you'd already
done it :-)
Index: ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
* libtool.m4 (_LT_AC_TAGCONFIG): Don't bring in CXX and F77 unless
the corresponding AC_PROG_ macro was provided.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.81
diff -u -p -r1.314.2.81 libtool.m4
--- libtool.m4 15 Apr 2005 14:40:09 - 1.314.2.81
+++ libtool.m4 17 Apr 2005 04:49:36 -
@@ -1701,6 +1701,7 @@ if test -f $ltmain test -n $tagnam
echo appending configuration tag \$tagname\ to $ofile
case $tagname in
+AC_PROVIDE_IFELSE([AC_PROG_CXX],[
CXX)
if test -n $CXX ( test X$CXX != Xno
( (test X$CXX = Xg++ `g++ -v /dev/null 21` ) ||
@@ -1711,6 +1712,8 @@ if test -f $ltmain test -n $tagnam
fi
;;
+])dnl
+AC_PROVIDE_IFELSE([AC_PROG_F77],[
F77)
if test -n $F77 test X$F77 != Xno; then
AC_LIBTOOL_LANG_F77_CONFIG
@@ -1719,6 +1722,7 @@ if test -f $ltmain test -n $tagnam
fi
;;
+])dnl
GCJ)
if test -n $GCJ test X$GCJ != Xno; then
AC_LIBTOOL_LANG_GCJ_CONFIG
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: CC can be a program name *with arguments*
On Mar 3, 2005, Bob Friesenhahn [EMAIL PROTECTED] wrote: In making this decision, we must consider what existing Automake does. If it searches for installed libtool by looking for a 'libtool' program in the path, then there will be problems. Automake uses libtool the way it was designed to be used, namely, using the script created by the configure script of the package being built. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: fallback-echo, finding a suitable $ECHO
On Jan 27, 2005, Ralf Wildenhues [EMAIL PROTECTED] wrote:
Which systems do actually need libtool's --fallback-echo?
Probably ones that didn't support shell functions either. I don't
recall exactly which systems required --fallback-echo, but I do recall
it was added for a very good reason, given how disgusting it is :-)
Since we've now moved on to better systems, supporting shell functions
and all, we might as well give libtool a new try without this gunk and
see how it goes. Failing that, a shell function might be good enough,
although the fact that not even bash gets it right in some cases
doesn't exactly give me a warm fuzzy feeling about this construct :-)
func_fallback_echo ()
{
# Without the eval, Bourne shells create the here doc at definition time.
eval 'cat _LT_EOF
$*
_LT_EOF
'
: # work around bash bug
}
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Understanding -static
On Jan 5, 2005, Akim Demaille [EMAIL PROTECTED] wrote: Le 4 janv. 05, 00:02, Peter O'Gorman a crit : I have no idea what is supposed to happen in this situation. You have specified that static libraries should not be built and also asked that executables be statically linked against not-yet-installed libraries. Right. Note quite. -static, for libtool, doesn't mean `reject any dynamic libraries', it just means `prefer static libraries over dynamic ones'. Yes, it's different from what compilers and linkers have done for -static historically, but it was deemed more useful to implement it this way. If you really, really, absolutely need a static executable, use -all-static. This should get the link to fail should a library only be available in dynamic form, or the system reject static binaries altogether. Right. But linking statically a dynamic library doesn't sound absurd to me (but I may be naive here). It sounds absurd to me, FWIW :-) At least, it works fine on GNU/Linux. Are you sure? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: RFC: proposal for indirect deplibs
On Nov 24, 2004, Ralf Wildenhues [EMAIL PROTECTED] wrote: On the other hand, on systems without a needed-following linker, it is necessary to explicitly list all dependent libraries. It's a bit more complicated than this, actually. Some linkers are smart enough to look for dependencies, but they look for them in different directories than those listed in -L. GNU ld, for example, looks for DT_NEEDED libs in -rpath-link, so unless you pass -rpath-link for the needed libs, linking might pick up an old version of a library that happens to be in say /usr/lib. However, if you link the lib in explicitly with -l, then it finds it in the -L-specified search path. If you build and install libs in multiple dirs, this can get you into a very confusing situation, unless libtool takes care of issuing the corresponding -rpath-link flags. Also, the encoding of dependent libraries is only possible in dynamic libraries, so you have to know with 100% of certainty whether the linker is going to link a library statically or dynamically. This means taking flags such as -Bstatic and -Bdynamic into account, otherwise you may end up refraining from linking in the dependencies of a libtool library because you know the linker will, but then the linker ends up using the static library, and then your assumption falls apart. Personally, I'd rather not attempt to second-guess the linker, and instead use the --as-needed flag newly-added to GNU ld to implement the libtool semantics you suggest, or perhaps even use --as-needed by default whenever it's available. This would require some portability checking on whether dynamic loaders can actually handle inter-library dependencies properly. We can probably assume GNU/Linux dynamic loaders do, but I wouldn't assume the same for other OSs, particularly non-ELF ones. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Installed libstdc++.la depends on GCC build directory
On Sep 8, 2004, Bob Friesenhahn [EMAIL PROTECTED] wrote: After installing GCC 3.4.2 today, I see that it still suffers from a libtool bug which may upset builds unless the GCC build directory is removed. I have reported this bug to the GCC bug tracking system: It's not exactly a bug. The problem is that libtool can't tell that some directory needed to bring in dep libs is to be used only at build time. We need some mechanism to tell libtool to strip certain directories from the installable .la file, something like -option /dir, that would omit options such as -L/dir and -L/dir/* specified in the command line into the build-time .la file, but not into the installable one. I suspect this problem affects many packages that rely on libtool's ability to resolve libtool dep libs given as -Ldir -lib, instead of as dir/libib.la. This happens to be a security issue, since if the build tree is removed and anyone can recreate the same tree (think /tmp/build/gcc/...), all you have to do is create some libraries with carefully-chosen names in there and wait for someone to link a C++ program using libtool and run it. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Aug 11, 2004, Daniel Reed [EMAIL PROTECTED] wrote: On 2004-08-12T09:00+0900, Peter O'Gorman wrote: ) Daniel Reed wrote: ) On 2004-08-11T10:06+0900, Peter O'Gorman wrote: ) ) Daniel Reed wrote: ) ) libtool-1.4.2-multilib.patch ) )This patch is needed for multilib support. It has been sent upstream ) )but basically rejected in its current form as being too Red Hat specific. ) ) [Is this still the case? Is there an alternate solution for this problem, or ) ) is .multilib still the only one?] ) Thanks for the url. I have to agree with Scott, looks like adding this patch ) here would be a bad thing, it may break other linux distros. Someone, ) someday, will come up with a generic way of doing this that works on all ) flavours of GNU/linux. They don't seem to have done so yet. Would it be reasonable to make this a ./configure option at libtool build time? God, no! It means every package would have to use this option at configure time, otherwise it wouldn't work. I think the best we can do is to run something like: case `$CC $CFLAGS -print-file-name=libc.so || gcc -print-file-name=libc.a` in # common case, good */lib/libc.so | */lib/libc.a) libsuff= ;; # many 64/32 arches use lib for 32-bit libs and lib64 for 64-bit libs */lib64/libc.so | */lib64/libc.a) libsuff=64 ;; # mips64-linux uses lib32 for N32 */lib32/libc.so | */lib32/libc.a) libsuff=32 ;; # Shouldn't happen... What now? *) libsuff= ;; esac This should probably be amended to match Debian GNU/Linux x86_64 practice. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
On May 28, 2004, Szombathelyi Gyrgy [EMAIL PROTECTED] wrote: AFAIK it's possible to link in libdep to libfoo if libdep is static Depends on the platform. Some combinations of OSs, ABIs and hardware architectures don't allow non-PIC in shared libraries. Yes, several of the platforms that don't support this are GNU/Linux ports. Try this on x86_64-linux-gnu, for example. It won't work, unless you somehow arrange for libdep.o to not contain any relocations that aren't PIC. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking against indirect dependencies
On May 26, 2004, Bob Friesenhahn [EMAIL PROTECTED] wrote: It also depends on libtool being 100% accurate in determining if a library is a static library or a shared library since static libraries don't support library dependencies. And there's another problem. When libtool passes -ldependency in the command line, the linker will look for libdependency in the directories where it looks for libraries (-L). If libdependency is only brought in by another shared library that has it in DT_RPATH, libdependency will be looked for in the --rpath-link search path, and it will have to be a shared library, i.e., static libs will be ignored. Now consider the following scenario: - libfoo.la is linked with libdep.la, but libdep.la was PIC and static-only. Both are installed. - libdep is rebuilt as both static and shared, and reinstalled. - program links with libfoo.la, using symbols from libdep.la that weren't brought into libfoo.la - libtool sees libdep.la is available as a shared lib, so it drops it from the link command. Link fails because libfoo.so doesn't bring in libdep.a. The only way to avoid this sort of problem would be to annotate libfoo.la with some indication that libdep.la was static-only at the time libfoo.la was created, as opposed to attempting to detect what kind of lib it is at the time libfoo.la is linked into something else. I.e., for libraries that are built as both dynamic and static, libtool would have to keep two dependency lists, one for the dynamic version, and one for the static version, such that the dynamic dependency list doesn't contain dependencies that are shared libraries. I think it can be made to work, but it's going to be a significant amount of work, and there are probably some additional problems that I haven't thought of. Risky... -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with handcoded C
On Dec 9, 2003, Tom Tromey [EMAIL PROTECTED] wrote: Alexandre == Alexandre Oliva [EMAIL PROTECTED] writes: Alexandre the *_OBJECT definitions assume the absence of shell-active Alexandre characters in filenames, which is probably a safe Alexandre assumption for Makefiles. It isn't unreasonable for a Java .class file's name to contain $. Oh, but if you look closely at the macros I posted, you'll notice that this doesn't matter all that much. As long as the automake- or hand-generated definition of ofile doesn't contain shell-active characters (and IIRC automake already takes care of turning them into underscores), you're fine. And then, if it does, we need an additional variable set by the rule preamble that sets a shell-safe version of ofile. The point here is to avoid the overhead of having to run ofile through sed to protect it at build time, when we can do it at Makefile-generation time. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer [EMAIL PROTECTED], gcc.gnu.org} CS PhD student at IC-Unicamp[EMAIL PROTECTED], gnu.org} Free Software EvangelistProfessional serial bug killer ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with handcoded C
On Dec 3, 2003, Mohan Embar [EMAIL PROTECTED] wrote:
I wanted to see how much faster the libgcj build would go if I took
libtool out of the picture for some of the pieces.
I'm not all that surprised your C program is much faster that the
shell script. For starters, it fails to support all of libtool's
configure-time options, such as --disable-static, --disable-shared,
--with-pic, as well as their per-compilation equivalent command-line
flags.
That said, even if it supported them all, I do believe there's a lot
of potential for such code. It has been in libtool's roadmap since
long before I pretty much stopped working on libtool, which was a
while before release 1.5. There were a number of discussions about
doing in C what we currently do in a slow and unmaintainable shell
script. Gary V. Vaughan had a small language with a small interpreter
that could reasonably be bundled into a libtool package as a
replacement for ltconfig/ltmain.sh, but we never got as far as
integrating it an actually making the transition. I suppose if you'd
like to do that, it would be very welcome, since many people
(rightfully) complain about libtool slowing things down, and using a
fast shell with many built ins isn't quite enough to get builds fast.
Back during the GCC summit, Zack Weinberg suggested an alternative
approach that could speed things up: getting the libtool code to
define additional Makefile macros that would enable someone to inline
the libtool calls into the Makefile itself. We talked a lot about it,
and it seems to me that if we got libtool to define the macros
referenced below and automake to generate them, we could have some
significant speed up by avoiding the need for the shell to at least
parse the entire libtool script for every command. That said, we
might be able to achieve similarly good results by simply splitting
the several libtool --modes into separate files, that could then be
ran with `.', which would at least minimize parsing.
foo.lo: foo.c
lofile=$@ dir=. ofile=foo.o; \
$(LIBTOOL_BEGIN_COMPILE_CC) FLAGS foo.c \
$(LIBTOOL_END_COMPILE_CC)
given the following possible additional definitions: (yeah, it's ugly,
and I sort of doubt we can get AC_SUBST to portably emit
LIBTOOL_END_COMPILE_CC like the snippet below, but hey!, it *might*
work, even if we have to break it up in smaller pieces to avoid
running into hard-coded limitations of sed substitutions)
LIBTOOL_BEGIN_COMPILE_CC = set fnord \
LIBTOOL_END_COMPILE_CC = ; shift 1; \
{ test -d $$dir/$(libtool_libdir) || \
$(mkdir_p) $$dir/$(libtool_libdir); } \
rm -f $$lofileT $$lofile $$dir/$$ofile \
$$dir/$(libtool_libdir)/$$ofile || : ; \
$(LIBTOOL_COMPILE_CC_PIC) -o $$dir/$(libtool_libdir)/$$ofile \
$${1+$$@} \
$(LIBTOOL_COMPILE_CC_NONPIC) -o $$dir/$$ofile $${1+$$@} \
{ echo pic_object=$(LIBTOOL_PIC_OBJECT); \
echo non_pic_object=$(LIBTOOL_NONPIC_OBJECT); } $$lofileT \
mv $$lofileT $$lofile
mkdir_p = mkdir -p # or $(mkinstalldirs), depending on configure tests
libtool_libdir = .libs # or _libs, depending on configure tests
LIBTOOL_COMPILE_CC_PIC = $(CC) -fPIC -DPIC # or equivalent, or :
LIBTOOL_COMPILE_CC_NONPIC = $(CC) # or : if disable static
LIBTOOL_PIC_OBJECT = $(libtool_libdir)/$$ofile # or none
LIBTOOL_NONPIC_OBJECT = $$ofile # or none
the *_OBJECT definitions assume the absence of shell-active characters
in filenames, which is probably a safe assumption for Makefiles. In
case libtool configuration finds that $(CC) is not up to e.g. the task
of outputting to object files named in the command line, it just falls
back to running the slow libtool script, with these definitions:
LIBTOOL_BEGIN_CC_COMPILE = $(LIBTOOL) --mode=compile $(CC) -o $$lofile
LIBTOOL_END_CC_COMPILE =
The best news is that we don't really need to modify libtool to play
with these ideas. We can play with the idea with a new set of
autoconf macros that extracts configuration variables from libtool
with --config and defines the appropriate AC_SUBST variables according
to them, then use custom build rules instead of automake-generated
ones. If it proves to be a good idea, the macros can be bundled with
libtool, and then automake can gain an option to generate such rules.
It will need a lot of experimenting, and some polishing of the macro
set that I posted above, but I believe you can realize most of the
gains you intend to realize with it, and then you won't be introducing
the need for running yet another program.
Wanna give it a try?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer [EMAIL PROTECTED], gcc.gnu.org}
CS PhD student at IC-Unicamp[EMAIL PROTECTED], gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: printing exceptions?
On Mar 6, 2002, Tom Tromey [EMAIL PROTECTED] wrote: Alexandre == Alexandre Oliva [EMAIL PROTECTED] writes: Alexandre Actually, I was thinking of libgcj.la being linked with Alexandre $(THREADLIBS) first, which would solve the problem just the Alexandre same. We already do that: libgcj_la_LDFLAGS = -rpath $(toolexeclibdir) $(THREADLIBS) $(LIBLTDL) \ $(GCLIBS) $(ZLIBS) \ So something else must be required. Ok, I see the problem now. It's indeed a bug in libtool. Basically, the problem is that libtool sometimes decides it can drop duplicate -l flags from the command line, when it thinks it is safe to do so. Currently, the rules is that, if a library does not explicitly appear more than once in the dependency list of a library, libtool assumes there's no problem if it simply discards any previous occurrences of such a library. On the other hand, if a library appears more than once in a dependency list (say, libjava is linked with -lgcc_s -lc -lgcc_s), libtool considers the duplicate library as a special library that strongly depends on ordering, and does not move it. The problem is that -lpthread ends up being removed from before the first copy of -lgcc_s, because it is not explicitly duplicated and thus it's taken as a movable library, while the first copy of -lgcc_s remains, as it is taken as unmovable. I don't see an easy way to fix this problem in libtool. It would require every unmovable library to establish a barrier such that no libraries that appear before it can be dropped. Since every C++ library has -lgcc_s -lc -lgcc_s in its dependency list, this would defeat the whole purpose of the duplicate-removal of dependencies, that was an absolute must for large packages with hundreds of libraries, such as KDE. Without such an optimization, building KDE would easily overflow the command line size on most, if not all OSs (except any one that does not impose fixed limits on command line sizes), due to exponential explosion of `-lm -lgcc -lc -lgcc' in the command line. Ideally, libtool should try to tell whether a library is dynamic or static in order to decide whether to eliminate all but the first or all but the last duplicates of -l flags (except for static libraries marked as special), but I'm not even sure this would be correct. Anyway, there are several ways to alleviate the impact of this problem in libjava and GCC. The simplest solution I could come up with was to drop from the link command of executables any libraries that were already in the dependency list of libgcj, so they'd be automatically brought in. This was enough to fix the problem at hand: now gij is linked with -lpthread before -lgcc_s, since there's no duplicate of -lpthread after the first implicit occurrence of -lgcc_s that was brought in from libgcj.la itself. The patch that fixes this problem is attached. Another possibility that occurred to me, that would further alleviate the problem of duplicate shared libraries, would be to get GCC to no longer issue the `-lgcc_s -lc -lgcc_s' sequence, but instead, to use just `-lgcc_s -lc'. I believe this would be a perfectly safe thing to do in the context of a shared -lgcc_s, no? We'd might still have to add duplicates for -lgcc and -lgcc_eh, so it might end up not being of much help. It's probably worth a shot, though. Any opposition to my changing the GCC specs to that effect? Yet another solution would be to get libtool to recognize libraries and object files implicitly linked in especially. It already does something to that effect, but it still considers duplicate libraries at such points as special. Sometimes I think adding the code to peek into the flags implicitly passed by g++ to the linker was a mistake, but then I think of how nice it is to be able to link with a libtool (possibly static) library using `libtool gcc', even if the library itself contains C++ code and has to be linked with -lstdc++, with the certainty that libtool will add the -lstdc++ dependency by itself since it learned about such dependency when looking at the arguments g++ passed to the linker when creating the original library. And then, sometimes libtool just can't use (old versions of) g++ to link shared libraries, because they're broken, and then it's essential for it to figure out which flags g++ would pass to the linker, drop those that would break (such as static libstdc++ that can't be linked into a shared library) and go with the rest of the args running the linker directly. Other libtoolers, any further suggestions as to how to fix this real libtool bug? Anyway, here's the patch for libjava. I'm checking it in mainline and in the 3.1 branch. Bootstrapped on athlon-pc-linux-gnu with --enable-threads, and verified by visual inspection that the link command line of gij and other libjava executables did contain -lpthread before -lgcc_s -lc -lgcc_s. Index: libjava/ChangeLog from Alexandre Oliva [EMAIL PROTECTED] * Makefile.am (jv_convert_LDADD): Don't
Re: printing exceptions?
On Mar 15, 2002, Richard Henderson [EMAIL PROTECTED] wrote:
On Fri, Mar 15, 2002 at 07:43:43PM -0300, Alexandre Oliva wrote:
Another possibility that occurred to me, that would further alleviate
the problem of duplicate shared libraries, would be to get GCC to no
longer issue the `-lgcc_s -lc -lgcc_s' sequence, but instead, to use
just `-lgcc_s -lc'.
Seems ok.
Yay! I'll try to implement this in the next few days.
We'd might still have to add duplicates for -lgcc and -lgcc_eh...
Not for gcc_eh. The point of the duplicate is to cater to a libc
that uses e.g. __divdi3.
More specifically, and static libc that uses __divdi3, since a shared
one would have its own __divdi3, no?
However, I kind of fail to see the point of having -lgcc before -lc.
I understand the idea is to resolve symbols of the program with the
implementations in libgcc, but what if the program doesn't reference a
symbol, but libc does? Then, we won't get the definition from libgcc,
but rather from libc itself. Could this ever be a problem? If not,
why don't we just drop the -lgcc from before -lc and stick with the
one after -lc only?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: printing exceptions?
On Mar 15, 2002, Andreas Schwab [EMAIL PROTECTED] wrote:
Alexandre Oliva [EMAIL PROTECTED] writes:
| However, I kind of fail to see the point of having -lgcc before -lc.
The point of having -lgcc before -lc is that -lgcc can add references to
-lc functions that were not referenced before.
Oh! Yes, indeed. I forgot about that. Thanks for the reminder.
So, -lgcc -lc -lgcc is indeed one of the special cases that libtool is
going to have to learn to live with. Perhaps it could learn to treat
them as a unit, though...
Fortunately, libtool only peeks into flags implicitly passed to the
linker in non-C tags, which means we're only going to get -lgcc_s
(because of the implicit -shared-libgcc in g++ and gcj), and things
will Just Work (TM).
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: No static libraries?
On Mar 1, 2002, Anthony Green [EMAIL PROTECTED] wrote:
Libtool isn't building static libraries for my project, although it does
try to install them (and fail).
What's the exact failure mode (snipped of the make output)? What does
libtool --features print? What is in the .la file that it's trying to
install?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: Fix libtool to support Linux/mips
On Feb 7, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
What is libbfd.la good for? It has
dependency_libs=' -L/export/build/gnu/binutils-import/build-i686-linux/libiberty/pic
-liberty'
In your case, nothing. If libiberty were a libtool library, you'd get
appropriate pathnames for its install location in the dependency list
of libbfd, such that you'd be able to link with libbfd.la and you'd
get libiberty linked in automatically, as God intended.
I simply don't like the idea of dependency on static
libraries under Linux.
You're free to not like it, but it's necessary for correct linking of
static libraries. Try --disable-shared on binutils, install libbfd
and try to link with it and you'll see what I mean. Try both
libbfd.la and libbfd.a to tell the difference.
When I need libiberty.a, I will add -liberty.
If you want to have to do that, don't use libtool once the library is
installed, and get rid of the .la file so that you don't get tempted
to use it again :-)
I don't need libtool to add things which don't belong there.
You don't have to use libtool. Especially if you don't want to.
libtool should just behave like ld/ar and nothing more.
If that's what you want, omit -liberty from the link command of
libbfd. You'll get a perfectly broken libbfd then, just the way you
want :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: Fix libtool to support Linux/mips
On Feb 7, 2002, Andreas Schwab [EMAIL PROTECTED] wrote:
Then why wasn't this done explicitly in the first place? Why is there an
incomplete test for architectures != arm when it is much more robust to
make a single check for arm?
Because for unlisted architectures, the status was unknown, so libtool
took the conservative approach of assuming that linking static
libraries into shared libraries didn't always work.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: Fix mips*-*-linux*
On Feb 7, 2002, Robert Boehne [EMAIL PROTECTED] wrote:
You have my approval to un-do my mistsake.
Thanks, I've just installed the patch.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: Fix mips*-*-linux*
On Feb 7, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
Well, there is no libiberty.so. You wind up with always linking files
in libiberty.a when libtool is used, no matter they are needed or
not.
And what is the problem with linking libiberty.a, if libbfd actually
depends on it?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: Fix libtool to support Linux/mips
On Feb 4, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
On Mon, Feb 04, 2002 at 09:52:04AM -0200, Alexandre Oliva wrote:
On Feb 4, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
* libtool.m4 (lt_cv_deplibs_check_method): Support Linux/mips.
Before I waste any further time on it, is it any different from the
patch I rejected some months ago? It seems to still have the same
problem.
I don't remember why you rejected it. FWIW, my patch is in the current
libtool source in CVS:
All this means is that you managed to get the patch in while I wasn't
looking, and in spite of my strong objections to the patch. Oh,
well... :-(
*sigh*
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: Fix libtool to support Linux/mips
On Feb 4, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
On Mon, Feb 04, 2002 at 09:52:04AM -0200, Alexandre Oliva wrote:
On Feb 4, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
* libtool.m4 (lt_cv_deplibs_check_method): Support Linux/mips.
Before I waste any further time on it, is it any different from the
patch I rejected some months ago? It seems to still have the same
problem.
I don't remember why you rejected it.
The reason was that your patch enabled dependency tracking control
that is unnecessary for most GNU/Linux systems. It was only necessary
for old ARM systems whose glibc was broken. Perhaps such dependency
control is also necessary for mips, because of the way its relocations
are set up, in which case you could have removed mips|mipsel from the
list of cpus that can use pass_all, and added a case for mips|mipsel
with a file_magic that handled the output of file on mips. I.e., fix
the problem you had without causing problems for others, exactly the
way I had asked for earlier.
But no, you had to go ahead and make libtool slower on all other
GNU/Linux architectures slower because you didn't understand what was
going on and chose not to take my advice. Nice move! :-/
Now please submit a patch for libtool that reverts your incorrect
patch and introduces the correct fix I suggest above.
Thanks in advance,
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: Fix libtool to support Linux/mips
On Feb 7, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
Please read my original message again.
Please read my original reply again.
# gcc -fPIC -c foo.c
# ar rcs libfoo.a foo.o
# gcc -fPIC -c bar.c
# gcc -shared -o libar.so bar.o -lfoo -L.
The linker will include files in libfoo.a to generate libbar.so. In
libbar.so, there is no dependency on libfoo.a.
Of course. There couldn't possibly be any such dependence. DT_NEEDED
can only refer to other shared libraries.
However, for some strange reason, libtool decides not to includes
files from libfoo.a whene generating libbar.so.
Huh? Libtool doesn't decide anything. Libtool would pass -lfoo to
the link command such that the linker would make this decision.
However, after your patch, it no longer passes -lfoo to the linker
when it finds that libfoo is a static library, because with your
change you're telling libtool that it's not safe to link shared
libraries with static libraries. On most GNU/Linux ports, it is.
If something was dropping members of libfoo.a from libbar.so, it was
the linker, and that's exactly what it's supposed to do when you link
a static library in, no matter if it's into a program or another
shared library. It links in only members of an archive that are
necessary, unless the --whole-archive option is in effect. But you
already knew that.
Instead, it puts a dependency on libfoo.a
in libar.la.
That, it does regardless of whether libfoo is static or dynamic, and
that's correct. In case both libbar.a and libfoo.a are static, when
you link with libbar.la you have to get libfoo.a linked in too, such
that dependencies are resolved. Also, a number of linkers will fail
if -lfoo is omitted when -lbar depends on it even if both are dynamic
libraries, and it doesn't hurt to pass -lfoo anyway, so libtool does
it. Or did it, before your change. Now, it's broken. Unless you
managed to break it further with that other patch that I rejected.
That is not what the Linux linker does. If you can fix this libtool
bug, I will be more than happy to send a patch to revert my change.
If you can describe the bug, I might attempt to fix it. But so far
you have only described correct and expected behavior.
Please don't tell me it is a libtool feature. It is a real bug.
Then show me the actual bug you're trying to fix. The sequence of
commands again doesn't even involve libtool.
I am not interested in any explanation why libtool has to/should do
it that way.
So you want to modify libtool without understanding what's going on.
This won't work. In fact, it has already failed. It's too bad that
your incorrect patch went in and broke what was working fine.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: Fix mips*-*-linux*
On Oct 23, 2001, Robert Boehne [EMAIL PROTECTED] wrote:
Here is the patch reworked for HEAD. If noone objects
I'll commit it.
*wakes up*
*stretches*
*yawns*
*looks around*
*thinks*
-- Hmm... It's been a long time since I last posted in
libtool-patches. In fact, it's been a while since I last opened
its mail folder, so I had completely missed this one. I wonder if
it's too late...
*shouts*
-- OBJECTION!
*looks at the CVS repo*
*thinks*
-- Hmm... No, it *was* too late :-(
Oh, well. I really think this shouldn't have gone in, for the reasons
brought up in gcc-patches and libtool mailing lists. But, after such
a long silence, I don't feel I'm entitled to just come back and start
checking in or reverting patches, so... Ok to revert that patch, by
checking this one in? Tested on athlon-pc-linux-gnu, no regressions,
so this must be right for at least GNU/Linux/x86, right? ;-)
For the record, the reason is that, contrary to the claim in the
patch, on a number of OSs it's not safe to link a static library into
a shared library and, on those in which it is safe, using file_magic
is pointless: pass_all is supposed to behave exactly the way
H.J. intended.
Sorry for having dropped the ball for so long. It's too bad I don't
foresee this changing in the near future :-(
Index: ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
Reverted incorrect patch:
2001-10-24 H.J. Lu [EMAIL PROTECTED]
* ltmain.sh: Allow link against an archive when building a
shared library.
* libtool.m4 (lt_cv_deplibs_check_method): Always use
file_magic for Linux ELF.
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/ltmain.in,v
retrieving revision 1.286
diff -u -p -r1.286 ltmain.in
--- ltmain.in 29 Jan 2002 22:58:35 - 1.286
+++ ltmain.in 7 Feb 2002 06:58:05 -
@@ -2990,13 +2990,6 @@ EOF
*) potlib=`$echo X$potlib | $Xsed -e 's,[^/]*$,,'`$potliblink;;
esac
done
- # It is ok to link against an archive when
- # building a shared library.
- if $AR -t $potlib /dev/null 21; then
- newdeplibs=$newdeplibs $a_deplib
- a_deplib=
- break 2
- fi
if eval $file_magic_cmd \\$potlib\ 2/dev/null \
| ${SED} 10q \
| egrep $file_magic_regex /dev/null; then
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.247
diff -u -p -r1.247 libtool.m4
--- libtool.m4 30 Jan 2002 16:39:24 - 1.247
+++ libtool.m4 7 Feb 2002 06:58:08 -
@@ -1949,7 +1949,6 @@ linux*)
# glibc up to 2.1.1 does not perform some relocations on ARM
lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[LM]]SB (shared object|dynamic lib )' ;;
esac
- lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[LM]]SB (shared object|dynamic lib )'
lt_cv_file_magic_test_file=`echo /lib/libc.so* /lib/libc-*.so`
;;
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
Re: PATCH: Fix libtool to support Linux/mips
On Feb 7, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
# gcc -fPIC -c foo.c
# ar rcs libfoo.a foo.o
# gcc -fPIC -c bar.c
# gcc -shared -o libar.so bar.o -lfoo -L.
I don't want ANY dependency of libfoo.a in libbar.so.
With the commands above, you don't get any dependency of libtool.a in
libbar.so. I don't understand what you're complaining about. This
doesn't even use libtool.
That is I can give libbar.so to someone. He/she can use it without
libfoo.a. With the current binutils in CVS, I got
/bin/sh ./libtool --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes
-g -O2 -o libbfd.la -rpath /export/tools/lib -release 2.11.93 archive.lo
archures.lo bfd.lo cache.lo coffgen.lo corefile.lo format.lo init.lo libbfd.lo
opncls.lo reloc.lo section.lo syms.lo targets.lo hash.lo linker.lo srec.lo binary.lo
tekhex.lo ihex.lo stabs.lo stab-syms.lo merge.lo dwarf2.lo archive64.lo `cat ofiles`
-L../libiberty/pic -liberty
Did you see
dependency_libs=' -L/export/build/gnu/binutils-import/build-i686-linux/libiberty/pic
-liberty'
Ah, ok, so it's the -liberty in libbfd.la that troubles you?
If all you want is to be able to give libbfd.so to someone else, do
so. You don't have to take libbfd.la along with it; just get rid of
it. And make sure you don't give libbfd.a away either, because it's
useless without the libiberty.a that you don't want to include in your
package.
That is completely bogus for Linux.
Nope, it's absolutely correct.
Try to link with libbfd.la with -static, then drop -liberty from the
command line you get and you'll see why.
Please fix it.
You still haven't shown that there's anything to be fixed.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: Fix libtool to support Linux/mips
On Feb 4, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
* libtool.m4 (lt_cv_deplibs_check_method): Support Linux/mips.
Before I waste any further time on it, is it any different from the
patch I rejected some months ago? It seems to still have the same
problem.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool hates twiddling
On Jan 15, 2002, Tom Tromey [EMAIL PROTECTED] wrote:
Alexandre == Alexandre Oliva [EMAIL PROTECTED] writes:
Alexandre In general, I recommend specifying the tag name explicitly,
Alexandre like some Makefiles already do, and automake should
Alexandre eventually do.
Could you submit an automake PR for that?
Otherwise I guarantee we'll forget about it :-)
Done
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: MLB merge is done! Hurray!
On Jul 11, 2001, Gary V. Vaughan [EMAIL PROTECTED] wrote:
On Wednesday 11 July 2001 3:56 am, Alexandre Oliva wrote:
Congratulations for completing the merge, and sorry about my long
absence. I'm afraid it will still last for a while, though :-(
No problem. Is your PhD demanding more attention these days?
Nope. In fact, I wish I could have dedicated more to my PhD lately.
But my lack of time for libtool has been a combination of time devoted
to my job at Red Hat and random personal appointments that have
managed to take up most of the remaining time that I used to devote to
free software projects :-(
Why not leave it officially closed so that we needn't pay it any attention,
but unnofficially maintain it purely to expedite the GCC project?
The GCC release manager agreed to accept local patches in the GCC 3.0
branch, as long as I enforce the policy that they make it to the
libtool CVS tree first. So, we're not going to need the branch any
more.
Thanks anyway!
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: MLB merge is done! Hurray!
Congratulations for completing the merge, and sorry about my long
absence. I'm afraid it will still last for a while, though :-(
On Jun 24, 2001, Gary V.Vaughan [EMAIL PROTECTED] wrote:
Anyway, I would like to declare MLB officially dead, and reopen HEAD for
development.
Hmm... This would be a bit of a problem. The recently-released GCC
3.0 is based on the MLB branch of libtool, and I don't yet feel
confident enough to just drop the branch and adopt the result of your
merge for GCC 3.0.1; the risk of regressions is way too high. Still,
people have been finding and fixing some minor bugs and porting
issues, and in GCC we have a rule of not modifying libtool files in
place, but rather of only merging from the libtool tree. This is the
only way I could find to make sure patches proposed by GCC developers
don't get lost, failing to make it to the libtool tree.
Unfortunately, the end result is that I have to either temporarily
lift the rule in the GCC CVS tree, or reopen the MLB branch in the
libtool CVS tree, perhaps renamed to GCC 3.0 branch and used solely
for this purpose, and never having a patch checked in that is not
backed by a corresponding patch for libtool mainline.
Would anybody mind if I kept using the libtool MLB for this purpose,
and explain to anybody who happens to post a patch for that branch
that a corresponding patch for mainline is required before the patch
can go in the branch?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool: not configured to build any kind of library
On Jun 27, 2001, [EMAIL PROTECTED] wrote:
Libtool builds only shared or static libraries. If you tell it to do
neither, how is it going to work?
It used to default to static-libraries only, in this case. I guess it
was broken during the merge :-(
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: dll cross-compile, .libs/impgen is a win-exe, not a linux-binary
On Jun 20, 2001, Olly Betts [EMAIL PROTECTED] wrote:
The name CC_FOR_BUILD is preferable - see the discussion stemming
from the first url below - perhaps libtool ought to change to this?
I'd approve any reasonable patch that fixed this :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: spec-files ?
On Jun 20, 2001, Enrico Weigelt [EMAIL PROTECTED] wrote:
could anyone write an specfile for libtool ?
Sure. In fact, a number of people already did. Just pick your
preferred RPM-based GNU/Linux distribution and get the spec file from
the libtool source RPM package.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: ld --auto-import for cygwin and libtool
On Jun 11, 2001, Robert Collins [EMAIL PROTECTED] wrote:
I think the shlib_overrides_runpath means the LDPATH on unix systems,
and PATH on win32 systems, overriding the -rpath compiled in path. In
which case it should be yes on win32, because AFAIK the compiled in path
is ignored :].
We should probably fix this problem by getting the compiled-in path
set up in a wrapper executable.
Oh, and I'd like to take the opportunity to publicly congratulate Paul
Sokolovsky for proving me wrong in my impression that it was
impossible to create shared libraries without source decoration on
Windows. Great job, Paul! :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: dll installation logic
On Jun 8, 2001, Gary V. Vaughan [EMAIL PROTECTED] wrote:
Unfortunately this probably comes dow to wrapper scripts, which is ugly too
Since we're talking Cygwin, shouldn't it be a wrapper executable?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: dll installation logic
On Jun 8, 2001, Guido Draheim [EMAIL PROTECTED] wrote:
hmmm, or an autoconf wrapper macro?
Nope, this wouldn't work for libraries that are not installed in
libdir, but in a subdir thereof.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Fortran support in multi-language branch?
On Jun 15, 2001, Robert Boehne [EMAIL PROTECTED] wrote:
One thing I'd like to see in Libtool is support for
multiple-language libraries where f90 C and C++ sources can be used
together in a single shared library.
I suppose you can already do this by creating single-language
convenience libraries, then linking them all together into a single
libtool archive.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Enabling/disabling shared or static libs from Makefile.am
On Jun 8, 2001, Pierre Sarrazin [EMAIL PROTECTED] wrote:
libutils_la_LDFLAGS = -version-info 0:0:0 -no-undefined -static
But the source files are still compiled twice.
Use the multi-language branch of libtool and add `--tag disable-shared'
to AM_CFLAGS.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Line length limitations
On Jun 5, 2001, Robert Boehne [EMAIL PROTECTED] wrote:
So I'm sure how to check the limits under SGI without
the 'wc' command.
Use cmp.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: objc/2902: collect2 doesn't ...: libtool should use collect2?
On May 31, 2001, John David Anglin [EMAIL PROTECTED] wrote:
OTOH, since we do know it is safe to link in libgcc, because it's PIC,
we might just get rid of the -nostdlib, and let GCC do the library
magic by itself. This should be good enough for objc.
Could you test such a change and re-post the patch, in case it works?
It does. Test results for hppa1.1-hp-hpux10.20 are here:
http://gcc.gnu.org/ml/gcc-testresults/2001-05/msg00734.html. I
also ran `-static'. The revised patch is enclosed.
Thanks, installing.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: make install-strip with libtool (CVS HEAD) automake (CVS HEAD) fails
On Jun 3, 2001, Robert Collins [EMAIL PROTECTED] wrote:
automake's makefile calls libtool:
STRIPPROG='strip' /bin/sh ./libtool --mode=install -s hello.exe
/usr/src/hellolib/build/t
/usr/local/bin/hello.exe
Looks like the name of the `install' program is missing between
`--mode=install' and `-s'.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool for C++, Windows and Unix
On May 31, 2001, Esben Haabendal Soerensen [EMAIL PROTECTED] wrote:
So am I going to run into trouble when I move my stuff to HP-UX ?
Yep.
Or can I avoid trouble by only using dynamic libraries ?
Static libraries, you mean? Yes, this would help.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool for C++, Windows and Unix
On May 30, 2001, Esben Haabendal Soerensen [EMAIL PROTECTED] wrote:
I am using libtool 1.3.3 for my C++ project using libtool and
libltdl. I seem to have it working. What are the reasons I should
need the ML-branch ?
Because libtool works for C++ only on the few targets on which it uses
the compiler for linking. On most targets that don't support linking
static libraries into shared libraries, libtool runs the linker
directly, which means that you won't get either of the C++ library or
the dynamic-constructor support object files linked in.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libjava testsuite problem under i686-pc-linux-gnu
On May 28, 2001, John David Anglin [EMAIL PROTECTED] wrote:
LD_LIBRARY_PATH is ignored for dependencies of shared libraries.
What does work for me, is adding `rpath' options for the relink
based on the path in LD_LIBRARY_PATH.
How about setting LD_RUN_PATH?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libjava testsuite problem under i686-pc-linux-gnu
On May 28, 2001, John David Anglin [EMAIL PROTECTED] wrote:
I still don't understand why libtool doesn't use `-B' and `-L' when it
creates the `rpath' list for building the preinstall version of an
application.
Because -B and -L specify static link (compile)-time search paths,
whereas -R and -rpath specify the dynamic link (run)-time search path.
If libtool got -rpath from -B and you built any executable for the
target in the GCC tree, that executable would search for libgcc in the
build tree, even after being installed.
Why does it matter whether a library is a libtool library
in the magic .libs subdirectory or a non-libtool library?
libtool knows whether a library is in the build tree or has already
been installed, and creates executables that, when installed, look for
libraries in their installed locations, but that locate libraries in
the build tree when run inside the build tree.
It get increasingly difficult to do this when one to-be-installed
library depends on another yet-to-be-installed library. If we want to
get that library to automatically find its dependencies, we may need
to create two copies of that library, since you have found out
LD_LIBRARY_PATH doesn't affect this search. Libtool takes care of
this problem too, but it can only do it when the library being linked
in is a libtool library.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: objc/2902: collect2 doesn't ...: libtool should use collect2?
On May 28, 2001, John David Anglin [EMAIL PROTECTED] wrote:
It's possible that libtool runs the linker directly on HP-UX for the
same reason it does on Solaris: because non-PIC static libraries can't
be linked into shared ones. In the old pre-MLB days, this caused a
lot of grief to g++, that would link in libstdc++ even when it was not
a shared library. With MLB, this is no longer an issue. But it's
hard to tell whether we can safely make this change. But I suppose
we're going to have to bite the bullet and try it. Libtoolers,
GCCers, does anybody disagree?
As far as I know, using the linker directly won't help resolve this
under hpux. We're talking about `gcc -shared', not `g++ -shared',
for the shared archive link command when we have gcc.
Yep. But, before MLB, there was no distinction between gcc and g++,
as far as libtool could tell, and this is where the problem stemmed
from. libtool didn't know about the implicitly linked in libraries.
When a static libstdc++ was implicitly linked into a shared library,
things broke. I believe this is the reason why we use ld directly on
a number of platforms that don't support this kind of linkage. So I'm
convinced the way to go is to go back to using GCC -shared, without
-nostdlib, since we no longer have to worry about libstdc++ in the
C configuration.
This shouldn't be a problem unless people don't do a full bootstrap.
I was thinking of a unified tree build, in which binutils are also
built using libtool.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libjava testsuite problem under i686-pc-linux-gnu
On May 26, 2001, John David Anglin [EMAIL PROTECTED] wrote:
As a result, the pre-install version of Array_1 (lt-Array_1) has an
incorrect runtime location for libgcc_s.so.0. It uses the old
version in the install directory rather than the new version in the
gcc build directory.
As posted in the libgcj mailing list, the problem is that libgcc_s is
not a libtool library, so libtool can't do its magic of handling
to-be-installed libraries. Setting LD_LIBRARY_PATH so that libgcc_s
is found in the right place might work, but then, it's possible that
LD_LIBRARY_PATH is ignored when looking for dependencies of dependence
libraries. I seem to recall such an odd behavior is present on some
platform; perhaps Solaris?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: objc/2902: collect2 doesn't ...: libtool should use collect2?
On May 25, 2001, John David Anglin [EMAIL PROTECTED] wrote:
Here is a libtool fix for the above problem. It changes libtool to use
`gcc -shared' for linking shared archives under hpux when $with_gcc = yes.
It also makes libtool use -nostdlib, which is most definitely wrong
without a definition of output_verbose_link_cmd. It appears to me
that you have simply copied the definitions from ltcf-cxx.sh, where
output_verbose_link_cmd is set whenever the compiler is GCC.
ltcf-c.sh doesn't.
I suppose the right solution for this problem is to introduce
ltcf-objc.sh, perhaps mostly as a copy of ltcf-gcj.sh, where this
problem should already have been taken care of. [checks...] No, it
isn't, and this is certainly going to be a problem whenever libgcj is
ported to HP-UX. Perhaps we could kill both problems at the same
time. Or, ever better, we might introduce a ltcf-gcc.sh to take care
of all languages supported by GCC in a generic way, instead of
duplicating it over all language-specific scripts.
However, this may only be the tip of the ice berg. The same problem
may apply to quite a few other oses.
True. But there's certainly a reason why we don't use GCC -shared on
HP-UX; it was used on all OSs in which it worked, back in the early
days of libtool. I wish I knew what reason it was, in the case of
HP-UX :-(
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: install phase fails
On May 23, 2001, Brian May [EMAIL PROTECTED] wrote:
for some reason this hasn't been a problem (with libtool 1.4) until
just now (maybe upgrading to glibc 2.2.3 from 2.2.2 triggered it)?
The problem has to do with requiring relinking at install time. This
is necessary when one library in the build tree depends on another
library in the build tree. The other library must be installed first,
and, when the former is to be installed, the other must already be
accessible in its previously-specified installation path, which is
different from the prefix you have specified at install time.
In general, when relinking is necessary, you must not use a different
prefix to install than the one used to build.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: DLLs with mingw or cygwin
On May 22, 2001, Sebastien Sable [EMAIL PROTECTED] wrote:
As far as I know, those are as recent as they can get, but still no
dll anywhere :
AC_LIBTOOL_WIN32_DLL ?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Removing duplicate occurences from dependency_libs
On May 20, 2001, Martin Baulig [EMAIL PROTECTED] wrote:
If you have a complicated dependency setup, this will slow down linking
in a very extreme way (it is more than 5 times slower for me) because I get
libraries like -lm or -ldl listed over 30 times in the dependency_libs.
Is it possible to add an argument to libtool to get back the old behavior,
for instance -unique-dependency-libs ?
Just make sure no library appears explicitly more than once in the
dependence list of any library or program, and you'll get exactly what
you want.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Removing duplicate occurences from dependency_libs
On May 20, 2001, Martin Baulig [EMAIL PROTECTED] wrote:
I'll debug it later on.
Thanks!
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Removing duplicate occurences from dependency_libs
On May 20, 2001, Sander Vesik [EMAIL PROTECTED] wrote:
ld.so never sees static libraries.
But libtool does. That's the difference. It's not just about
creating shared libraries. It must take creation of static libraries
into account.
Besides, there are indeed a number of dynamic linkers that don't
support inter-library dependencies properly.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [egagnon@j-meg.com: Bug#97759: libtool: build problem]
On May 17, 2001, Ossama Othman [EMAIL PROTECTED] wrote:
Bug report for libtool 1.4 from a Debian user. Any ideas?
My first guess would be that libffi has been mis-installed. What does
/usr/lib/libffi.la look like?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: lots of -lresolv added to command line?
On May 17, 2001, Ossama Othman [EMAIL PROTECTED] wrote:
On the other hand, shouldn't libtool be able to handle stuff like this
without producing dozens of consecutive duplicates?
The heuristics we use is that, if a library is explicitly listed more
than once in the dependence list of a single library, we don't ever
remove duplicates of it. If such a library is used as a dependence of
multiple other libraries, the duplicate dependency will end up
appearing multiple times in their dependency lists.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [MLB] BUG in install when piecewise linking
On May 17, 2001, Robert Boehne [EMAIL PROTECTED] wrote:
Can we get around these problems easier in the binary-branch?
I'm not sure it's going to be easier, but it's hopefully going to be
far more efficient :-)
I envision a binary libtool that could do all of the processing
itself, without needing to use sed or shell until it needed to
call a compiler.
Yep.
Since users can use GNU sed on the two affected platforms, there's a
simple workaround, and that leads me to a more protracted but more
complete solution to the problem.
Agreed. In fact, that's the only way out for the moment. I wish we
could at least warn the users about the problem, though. That would
be better than simply failing.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: custom wrapper script hooks
On May 17, 2001, Havoc Pennington [EMAIL PROTECTED] wrote:
Does that sound like a reasonable feature?
While this has pretty much nothing to do with building and using
libraries, I'll give you that this is a very nice feature, and it fits
in nicely with one of the most important features of libtool, which is
that of helping testing of uninstalled programs, so I'd vote for
installing a patch that implemented it. Would any other libtool
maintainer oppose to this feature?
I suppose this new switch could be useful not only at library creation
time, but also at program creation time.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool: link order problem affecting gij
On May 16, 2001, Bryce McKinlay [EMAIL PROTECTED] wrote:
Jeff Sturm wrote:
On Sun, 13 May 2001, Bryce McKinlay wrote:
libtool inserting lib flags (-lgcc_s -lc -lgcc_s) into the gcj link
command line _before_ other lib flags which we are passing to it. This
means that libc is being linked before libpthread, which is bad:
Yeah. This has been happening for a little while:
http://gcc.gnu.org/ml/java/2001-04/msg00297.html
Does Zack's patch help?
http://gcc.gnu.org/ml/java-patches/2001-q2/msg00166.html
By eliminating libsupc++ from the build, its side effects (linking with
explicit -lc) should go away.
Zack's patch does indeed fix this problem and I notice that he has checked
it in. Thanks Zack!
Seconded.
FYI, my current inclination is to arrange for libtool to not add to a
library's dependencies any switches passed implicitly by the compiler
driver to the linker. I'm not convinced this is right at all times
(perhaps only for convenience libraries?), but it would have avoided
this problem.
To clue other libtoolers into the problem: libjava is thread-aware, so
it must be linked with the thread library. However, the thread
library must be linked in before the regular (thread-unaware) C
library. The problem seems to be that libtool was picking the
dependency list from a C++ convenience library, that included the
shared libgcc and libc, as above, which resulted in libc being linked
in before the thread library.
One simple solution would have been to move -lpthread first in the
list of dependencies of libjava. But I'd hope libtool might be more
helpful in cases in which library ordering matters so much. I'm not
sure we should introduce thread-awareness in libtool (actually, extend
the almost-do-nothing already-existing thread flag) or somehow adjust
libtool such that the postdeps of the compiler are handled as a unit,
or something like that.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool for C++, Windows and Unix
On May 16, 2001, Lars von Wedel [EMAIL PROTECTED] wrote:
Do I have to take a look into the multi-language branch
To properly support C++, yes.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: I think binary-branch is almost ready for play time
On May 13, 2001, Bruce Korb [EMAIL PROTECTED] wrote:
Alexandre Oliva wrote:
In other words, your new macro should not need to do this:
[= test-and-exit test = (get test) ... =]
because it would be redundant.
Good. But I had meant to write ``I'd like *you* to implement ...''
:-)
Then I would need to understand better what you wanted to have
happen.
I just need one macro implemented in terms of another. The idea was
that test-OR-exit would call test with the same condition, and append
to the else clause the commands to output the error message and the
exit command. Or something like that.
[= test-OR-exit msg = start-[= gather-the-message =]-end =]
is now accepted. What happens is that the string sta...end
is gathered up at load time. When this invocation fires,
an anonymous template is created with that text and then processed.
The output is redirected to an unlinked file (no Windows here),
and read back in.
This won't help much in this case (but it was indeed one of the major
requirements for AutoGen to be usable here). What I need is the
definition of test-OR-exit to refer to other macros.
I would not nest macros, I would add an argument, and
maybe some sanity checks thus:
The issue is not about how to implement test, it's about how to
implement macros in terms of others.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [MLB] BUG in install when piecewise linking
On May 9, 2001, Robert Boehne [EMAIL PROTECTED] wrote:
So the problem seems to be that when relink_command is formed,
it's passed through bug-ridden vendor sed. If there is another way
to build $relink_command without running into this problem, I'd
like to hear suggestions. :)
One alternative would be to try to figure out the maximum line length
supported by sed, and use that as an upper bound for the command-line
length limit. Then, we could use new-lines instead of semicolons as
command separators in relink_command.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool drops -static from LDFLAGS?
On May 8, 2001, Ossama Othman [EMAIL PROTECTED] wrote:
Right, but the problem is that is it prevents users who know what
they're doing from using gcc's -static option.
Nope. -all-static does that. It's in the libtool manual. If they
``know what they're doing'', they should know that :-D
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool drops -static from LDFLAGS?
On May 7, 2001, Ossama Othman [EMAIL PROTECTED] wrote:
Libtool drops the user supplied -static flag (e.g. in $LDFLAGS) from
the link command. Is this what we want?
Yep. To really force static linking, use -all-static. -static tells
libtool to *prefer* static libraries, not to *require* them.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: crosscompiled .exe (Re: crosscompiling dll linux-mingw32)
On Apr 28, 2001, Gary V. Vaughan [EMAIL PROTECTED] wrote:
libtool would need to build a wrapper program on Windows which would
call the wrapper script to set the environment up to load the
correct DLLs and then call the actual program in the .libs
subdirectory.
I like this idea. It's been in my to-do list for a while.
Along the same lines, we should probably not even bother to create the
wrapper script/program when cross compiling. I'm not sure we already
do this.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Installing convenience libraries
On Apr 30, 2001, Nick Hudson [EMAIL PROTECTED] wrote:
Are there really platforms that do not allow the equivalent of ar
PIC objects?
I believe the oddities of MS-Windows DLLs could break this in certain
cases.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Installing convenience libraries
On Apr 26, 2001, Nick Hudson [EMAIL PROTECTED] wrote:
What I'd like is a archive of -fPIC compiled code.
Compile the code with -prefer-pic and create a -static library.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: crosscompiling dll linux-mingw32
On Apr 26, 2001, Guido Draheim [EMAIL PROTECTED] wrote:
I did just need to change a single line in ltmain.sh which
enabled me afterwards to actually *build* a dll.
Looks like you were not using -no-undefined when creating the
library. This is required to build a DLL on MS-Windows.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool-1.4
On Apr 24, 2001, Gary V.Vaughan [EMAIL PROTECTED] wrote:
Since I don't want to hold up the release any longer, I am going to
break the commit rules and remove all use of the inline keyword (and
the AC_C_INLINE) from libltdl before I roll up the release -- unless
someone asks me not to in the next few hours.
I've finally understood the problem, and it seems that removing all
uses of inline is probably excessive. We just can't declare functions
with static variables as inline. `static inline' (but not `inline
static') is ok for functions without static variables, as long as
`inline' is defined away for compilers that don't support it (which
AC_C_INLINE should take care of).
Of course, re-enabling inline is not a requirement for the release,
since we can always re-enable it later.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.3e (1.913) test results for i386-unknown-netbsd1.4.1
On Apr 25, 2001, Nick Hudson [EMAIL PROTECTED] wrote:
These fails due to a problem in ld.aout_so (see lib/10940) that has
recently been fixed and is available in the netbsd-1-4 tagged sources.
Nick, would you mind submitting a patch to libtool that will disable
shared libraries in case the fix isn't present?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Making hardcode.test more robust [patch against HEAD]
On Apr 22, 2001, [EMAIL PROTECTED] wrote:
It does retain the original behaviour on other platforms. The case
statement is only for particular hosts. All other hosts keep the
result from the fgrep test.
Indeed.
BTW, another possible solution is to compile with CFLAGS=-s. Compiling
without CFLAGS=-g solves the problem on Solaris and with CFLAGS=-s
solves the problem on IRIX 6.x.
I'm not sure how portable -s is. Hmm... Any takers?
Good point about host != build. How would I even begin to solve that?
Only do the improved test when host = build. Which amounts to falling
back to the original version when cross compiling. And then, I wonder
whether we really want potentially different results for the same host
platform...
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool and Pkg-Config
On Apr 22, 2001, Martijn van Beers [EMAIL PROTECTED] wrote:
Maybe you should actually take a look at pkg-config instead of listening
to people talking about it inaccurately.
Err... Perhaps if I had been pointed at it, instead of having had the
impression it was some tool in an early design phase, I would have
looked at it :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool and Pkg-Config
On Apr 22, 2001, Havoc Pennington [EMAIL PROTECTED] wrote:
pkg-config has some intelligence, i.e. if you request two libs at once
it will nuke duplicate flags and order the -l flags properly.
Err... It won't always remove duplicate -l flags, will it? This
isn't always correct.
Also, it can gripe about missing dependencies or conflicting
libraries.
Good.
I think for libtool it's as simple as having a concept of a package
in addition to a concept of a library, so we can pass gtk+-2.0 to
libtool instead of -L/home/hp/unst/lib -L/usr/X11R6/lib -lgtk-x11-1.3
-lgdk-x11-1.3 -lXext -lgdk_pixbuf-1.3 -lm -lpangox -lX11 -lpango
-lgobject-1.3 -lgmodule-1.3 -ldl -lglib-1.3
Well, you can already create a dummy libtool library that will be
replaced with all of this when it's linked in. In fact,
gtk-x11-1.3.la may be that (no longer dummy) library.
Then the remaining thing to add is the RPM-style version comparisons,
which is beyond my ability to implement in shell, but I'm sure someone
can figure it out. ;-)
In shell? I was hoping pkg-config could be implemented in something
more reasonable...
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Making hardcode.test more robust [patch against HEAD]
On Apr 22, 2001, [EMAIL PROTECTED] wrote:
Patch below to override the fgrep test for IRIX 6.x, Solaris 2.x,
and Tru64 UNIX 4.x, 5.x.
It should at least retain the original behavior on other platforms.
And you shouldn't assume host == build, which you seem to do by
invoking host-specific programs on the build machine.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool and Pkg-Config
On Apr 21, 2001, Eric Lemings [EMAIL PROTECTED] wrote:
2.0 spawned a separate tool called pkg-config that allows all packages
to use one tool rather than several different scripts to query compile
flags, link flags, and other configuration data.
What I don't understand is how pkg-config is going to find the
configuration info of the various packages. I hope it's not going to
require having them all installed in the same prefix. One of the
beauties of the *-config scripts is that all one had to tweak to get
them to work and get the respective libraries found is the PATH (or a
directory containing links).
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Fix: Interlibrary dependencies SCO Uw7
On Apr 19, 2001, Matthew Schalit [EMAIL PROTECTED] wrote:
Does the fact that the libtool passes all 83 tests,
including the
deplib.test
file mean that we're good?
That's the kind of problem deplib tests are supposed to catch, but it
may not cover all possible ways a platform may lose when linking
non-PIC into a shared library.
Anyway, if it passes all these tests, the patch is probably fine for
*this* version of UnixWare. This doesn't make it good for older
versions.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Duplicates in library auto-dependencies
On Apr 18, 2001, Robert Boehne [EMAIL PROTECTED] wrote:
I'm in a bad situation with the loss of complete and draconian
duplicate removal in dependency tracking.
Err... Was it really removed? I thought we had decided to keep it
in, along with the fix I posted and installed a few days ago.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Duplicates in library auto-dependencies
On Apr 18, 2001, "Gary V. Vaughan" [EMAIL PROTECTED] wrote:
However, I still think we might want to revert to the 2 year old
relatively complaint free (but marginally error-prone) duplicate
removal for the release of 1.4.
Yeah, I'm all for it. When I thought it was a bad thing, I hadn't
realized it used a carefully-chosen heuristics to decide when certain
duplicates couldn't be removed. Now that I know that, I agree it's
right to leave the duplicate-removal code enabled.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Downtime... musings... libtool-1.4
On Apr 18, 2001, "Gary V. Vaughan" [EMAIL PROTECTED] wrote:
However, I just deleted my savannah#2 certificate, and I can can now
get in.
Me too. Sorry about the noise.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Mainline bootstrap failure (Re: libstdc++ execute tests)
On Apr 16, 2001, "Gary V. Vaughan" [EMAIL PROTECTED] wrote:
I like this idea. Would you add it to the libtool TODO file please,
Ok to install?
Index: ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
* TODO: Add -L- flag.
Index: TODO
===
RCS file: /cvsroot/libtool/libtool/TODO,v
retrieving revision 1.42
diff -u -p -r1.42 TODO
--- TODO 2001/01/31 16:26:48 1.42
+++ TODO 2001/04/18 04:43:45
@@ -18,6 +18,13 @@ be desirable.
* Lists of exported symbols should be stored in the pseudo library
so that the size of lt_preloaded_symbols can be reduced.
+* Have some option to tell libtool not to include -L flags that point
+into a certain tree in the dependence list of an installed library.
+For example: -L-$top_builddir would let one link with libtool
+libraries in sibling subdirectories within a project, using the -L
+notation, without getting builddir pathnames ever mentioned in .la
+files that get installed.
+
In the future:
**
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Configuring libtool HEAD branch.
On Apr 16, 2001, Russ Allbery [EMAIL PROTECTED] wrote:
Some vague memory also tells me that this is how shared library versioning
is done (with differently named shared objects).
Yep, this matches my understanding of the way shared libraries work on
AIX.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: ld.so.1: dlopen: fatal: foo: can't find symbol
On Apr 16, 2001, Christopher Lintz [EMAIL PROTECTED] wrote:
handle = dlopen("/home/cjl/.libs/foo.so.0", RTLD_LAZY );
[...]
if ((fptr = (int (*) () )dlsym(RTLD_DEFAULT, "foo")) != NULL)
make it `handle'
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: shared library linking on Darwin
On Apr 17, 2001, Chris Leishman [EMAIL PROTECTED] wrote:
*** Warning: This library needs some functionality provided by
extra/libextra.a.
Unfortunately I can't get the application to load the libshared.a file
as a dynamic module (not unsurprising). Even if I specify -dlopen on
the command line it still barfs
How exactly are you specifying this flag, and what exactly happens?
I'm just wondering why it can't just suck the object files out of the
archive when linking the shared library?
Because they're likely to be non-PIC, and several platforms don't
support non-PIC in shared libraries. If Darwin does, all you have to
do is to post a patch that sets deplibs_check_method=pass_all.
That seems to be how it works on other platforms.
You haven't tested on enough other platforms :-)
Alternatively I can compile the subdir as a shared library, but that
means I need to use inter library dependencies when module loading -
Compile it as a libtool convenience archive. That's exactly the
purpose of this feature.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Mainline bootstrap failure (Re: libstdc++ execute tests)
On Apr 12, 2001, Franz Sirl [EMAIL PROTECTED] wrote:
Additionally libstdc++ installs a $prefix/lib/libstdc++.la which
includes the libstdc++ *build* directories in dependency_libs, with
the result that libtool aware applications like KDE2 use them for
their -L flags during linking...
Uh oh. This is bad.
The problem is that libtool has no way to tell which directories
specified with -L are part of ``the current build'', so it assumes any
dependencies of the library being built might be in one of those
directories after the library is installed, so the directories must be
added to the search path of libtool.
I see two ways to avoid this:
- not use any -L flags when creating libtool libraries; instead,
specify library names explicitly. This does The Right Thing (or at
least is supposed to) if the dependence libraries are libtool
libraries (which, unfortunately, is not the case) or static
libraries. The shared libgcc would be a problem in this case, and
more so before the -L flag is taken implicitly from the flags the
compiler driver passes down to the linker.
- create some way to tell libtool ``look, this -L flag is to be used
only when building this particular library, it's not needed for any of
its dependencies after the library is installed.'' This might be
accomplished by specifying the root of the current build tree. So,
libstdc++-v3 would be configured such that it would pass to libtool
something like, say -L-$(top_builddir)/$(MULTILIBTOP)/.., and libtool
would compare the prefix of the canonicalized full pathname
corresponding to $(MULTILIBTOP)/.. with that of each directory passed
in -L, and remove it from dependency_libs in the installable .la file.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: problems compiling latest cvs of gcc_3.0 branch..
On Apr 6, 2001, Michael Matz [EMAIL PROTECTED] wrote:
2001-04-05 Michael Matz [EMAIL PROTECTED]
* ltmain.in: recognize "C" as default --tag argument to resolve
also ambiguities with that language.
Thanks. I've checked this in, except that I renamed the tag to CC,
for symmetry with CXX and GCJ. We can always add alternatives later,
if needed.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: problems compiling latest cvs of gcc_3.0 branch..
On Apr 6, 2001, Nick Hudson [EMAIL PROTECTED] wrote:
Michael Matz wrote:
2001-04-05 Michael Matz [EMAIL PROTECTED]
* ltmain.in: recognize "C" as default --tag argument to resolve
also ambiguities with that language.
FWIW I've done something similar in NetBSD pkgsrc libtool - I've done it
a different way and called it CC.
Yeah, I recall your posting about it. But I don't recall having seen
a patch; did you get to post it?
I think CC is the right tag name. Anyway, given that it's just a case
matching, we might recognize all of `C', `CC' and `default'. But we
should probably arrange for ltconfig to reject creating such tags, to
avoid confusion.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: FYI: duplicate removal patch [Was Re: ok, new libtool forcygwinupdates]
On Apr 5, 2001, Stephan Kulow [EMAIL PROTECTED] wrote:
I would like to add that all KDE libraries are labeled with
-no-undefined, so there should be no guessing involved. So if you
see a -lb you can be sure all references to it are resolved if you
put the given LIBADDs of liba behind it. Perhaps this -no-undefined
should be part of the .la file?
This would be a good idea, if it were not for the fact that
-no-undefined means the library *plus its dependencies* have no
references to external symbols, not the library by itself. So we
still don't have much freedom to drop or move -lname flags around :-(
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
