Re: Need help with libtool + BeOS (solved)
Found the problem myself - it was the RTTI-setting, not libtool that was the problem. Lars J
libtool 1.3.4 on BeOS doesn't produce shared libs
Hi guys, I'm programming on some automake/autoconf/libtool based projects on Linux and BeOS. A while back we upgraded from libtool 1.2f to libtool 1.3.4 and libtool stopped producing shared libraries. We upgraded automake to 1.4a and autoconf to 1.14.1 at the same time - whether this is related to the problem, I don't know. Anyways, libtool doesn't create shared libraries, only static ones, even though configure reports like this: checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no The final linking produces this weird warning that might have something to do with the problem: /bin/sh ../libtool --mode=link gcc -g -O2 -o libsimage.la -rpath /boot/users/larsa/lib -version-info 0:0:0 -release 0.9 simage.lo simage_png.lo simage_tga.lo simage_rgb.lo simage_pic.lo -lpng -lz libtool: link: warning: undefined symbols not allowed in i586-pc-beos shared libraries mkdir .libs (cd . && ln -s simage.lo simage.o) (cd . && ln -s simage_png.lo simage_png.o) (cd . && ln -s simage_tga.lo simage_tga.o) (cd . && ln -s simage_rgb.lo simage_rgb.o) (cd . && ln -s simage_pic.lo simage_pic.o) ar cru .libs/libsimage.a simage.o simage_png.o simage_tga.o simage_rgb.o simage_pic.o ranlib .libs/libsimage.a creating libsimage.la (cd .libs && rm -f libsimage.la && ln -s ../libsimage.la libsimage.la) Creating the shared library manually isn't any problem, though: [667] simage > cd src/ [668] src > ld -shared *.o -o libsimage.so [669] src > file libsimage.so libsimage.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped [670] src > ls -l libsimage.so -rwxr-xr-x 1 larsaSIM 64755 Feb 15 16:29 libsimage.so* [671] src > If anyone wants to look at the gory details, they will find the following files at http://www.sim.no/~larsa/libtool-beos/> configure.in.txt configure.in from the simage library project aclocal.m4.txt aclocal.m4 from simage/ src-Makefile.am.txt Makefile.am from simage/src/ config.log.txt config.log in $top_builddir configure-log.txtoutput of configure run make-log.txt output of make run Any help is appreciated... Lars J
Re: libtool 1.3.4 on BeOS doesn't produce shared libs
On Tue, Feb 15, 2000 at 04:49:15PM +0100, Lars J. Aas wrote: : I'm programming on some automake/autoconf/libtool based projects on : Linux and BeOS. A while back we upgraded from libtool 1.2f to libtool : 1.3.4 and libtool stopped producing shared libraries. [...] I did this change in the generated "libtool", and got libtool to create a shared library again: # Flag that allows shared libraries with undefined symbols to be built. - allow_undefined_flag="unsupported" + allow_undefined_flag="supported" Lars J
Re: libtool 1.3.4 on BeOS doesn't produce shared libs
On Tue, Feb 15, 2000 at 02:08:13PM -0200, Alexandre Oliva wrote: : On Feb 15, 2000, "Lars J. Aas" <[EMAIL PROTECTED]> wrote: : : > Creating the shared library manually isn't any problem, though: : : Look for `-no-undefined' in the libtool manual. Will do. : Has the restriction on undefined symbols in BeOS libraries been : lifted? Doesn't look that way on R4.5. I had two png-libraries, one old which didn't include all the symbols libsimage needed. A manual ld -shared didn't work against it. When I removed it and used the other libpng, it worked. libtool played it safe independent of the libpng library setup. BeOS R5 is released in a few weeks - I'll check again then. Lars J
Re: libtool 1.3.4 on BeOS doesn't produce shared libs
On Tue, Feb 15, 2000 at 11:18:44AM -0500, Frank Ch. Eigler wrote: : Hi - : : > /bin/sh ../libtool --mode=link gcc -g -O2 -o libsimage.la -rpath :/boot/users/larsa/lib -version-info 0:0:0 -release 0.9 simage.lo simage_png.lo :simage_tga.lo simage_rgb.lo simage_pic.lo -lpng -lz : : Try adding "-no-undefined" too. | /bin/sh ../libtool --mode=link gcc -g -O2 -o libsimage.la -rpath |/boot/users/larsa/lib -no-undefined -version-info 0:0:0 -release 0.9 simage.lo |simage_png.lo simage_tga.lo simage_rgb.lo simage_pic.lo -lpng -lz | mkdir .libs | (cd . && ln -s simage.lo simage.o) | (cd . && ln -s simage_png.lo simage_png.o) | (cd . && ln -s simage_tga.lo simage_tga.o) | (cd . && ln -s simage_rgb.lo simage_rgb.o) | (cd . && ln -s simage_pic.lo simage_pic.o) | gcc -nostart simage.o simage_png.o simage_tga.o simage_rgb.o simage_pic.o -lpng |-lz -Wl,-soname -Wl,libsimage.so -o .libs/libsimage.so | creating libsimage.la | (cd .libs && rm -f libsimage.la && ln -s ../libsimage.la libsimage.la) Yeay! Where would be the correct place to add that option? In src/Makefile.am like this? | libsimage_la_LDFLAGS = \ | -no-undefined \ | -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) \ | -release $(LT_RELEASE) Cheers, Lars J
BeOS and inter-library dependencies
I'm using libtool (1.3.4) to create a shared C++ library on BeOS. In the final linking stage, libtool drops all the libraries my library depends on, resulting in a load of undefined reference error messages. | /bin/sh ../../../libtool --mode=link c++ -g -O2 -DSOBE_DEBUG=1 -fno-rtti |-fno-exceptions -W -Wall -Wno-unused -Wno-multichar -L/boot/users/larsa/lib |-L/boot/users/larsa/lib -o libSoBe.la -rpath /boot/users/larsa/lib -no-undefined |-version-info 0:0:0 -release 0.1 SoBe.lo SoBeComponent.lo SoBeGLWidget.lo |SoBeRenderAreaExtra.lo SoBeRenderArea.lo common/libSoCommon.la |devices/libSoBeDevices.la extensions/libSoBeExtensions.la widgets/libSoBeWidgets.la |-lCoin -lMesaGL -lsimage -lpng -lz -lbe | rm -fr .libs/libSoBe.la .libs/libSoBe.* .libs/libSoBe-0.1.* | | *** Warning: inter-library dependencies are not known to be supported. | *** All declared inter-library dependencies are being dropped. | *** The inter-library dependencies that have been dropped here will be | *** automatically added whenever a program is linked with this library | *** or is declared to -dlopen it. | gcc -nostart SoBe.o SoBeComponent.o SoBeGLWidget.o SoBeRenderAreaExtra.o |SoBeRenderArea.o -Wl,--whole-archive common/.libs/libSoCommon.al |devices/.libs/libSoBeDevices.al extensions/.libs/libSoBeExtensions.al |widgets/.libs/libSoBeWidgets.al -Wl,--no-whole-archive -Wl,-soname -Wl,libSoBe.so |-o .libs/libSoBe.so Now, if I hardcode "deplibs_check_method=pass_all" into ltmain.sh, the libraries are passed through to gcc, and the library links fine. What's the status on this? Is it just something that hasn't been checked out, hence not implemented in libtool, am I missing a libtool option, or will the hack I've done break down at a later stage so it can't be done like this anyway? Lars J
Need help with libtool + BeOS
I have a problem with libtool for beos, which is that I can't derive the classes in the standard shared libraries without causing a crash. I'm trying to derive BGLView in a libtool library, and everything seems fine until I add it to a window. I've created a minimal demonstration-archive located at http://www.sim.no/~larsa/minimal.tar.gz (127K) (<2K sourcefiles) If anyone can take a look at it and explain to me what I'm doing wrong with the autoconf/automake/libtool setup (plain makefile setup also included to show that the sources actually work), I would be a very happy man. Will the multi-language-branch of libtool (haven't tried it out yet) handle this problem? Desperately, Lars J
Re: libtool + beos
On Mon, Mar 20, 2000 at 02:41:03AM +0100, Erik Eriksson wrote: : Hi, : : I have problems getting libtool to create shared libraries under BeOS. : When examining the libtool-script and comparing with another platform, : it seems that if I change the definition below: : : # Flag that allows shared libraries with undefined symbols to be built. : allow_undefined_flag="unsupported" : : to: : : allow_undefined_flag="" : : , I get my libraries, and everything seems to work perfectly fine. Instead of hardcoding this into libtool, add "-no-undefined" to LDFLAGS in your Makefile.am files, like this: libreg_la_LDFLAGS = \ -no-undefined \ -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) \ -release $(LT_RELEASE) I notice I've hardcoded "deplibs_check_method=pass_all" myself in ltmain.sh in some project, because libtool kept dropping the libs my library depend on... I should really investigate this more thorough, but now that things work it's more satisfying to work on the library itself than on the build process... Lars J
Re: Multiple interfaces to a single library.
On Sun, Mar 19, 2000 at 10:16:13PM -0500, Kevin Atkinson wrote: : Some one in personal email said: : : > This is what proper design of header files is all about. Don't put : > what you don't want used in the installed header files. : : I just KNEW someone would say that. The thing is programs that USE the : library use a different part than those who IMPLEMENT part of the library. Of course. That's why you don't install private header files - just the public ones. Building the library happens inside the source tree where you have both private and public headers. When you build against the library, it is installed and only public headers are available. Also, setting up a _INTERNAL define in the library build setup will help you trap unwanted access of private header files... Lars J
Re: libtool + beos
On Mon, Mar 20, 2000 at 11:44:08PM -0300, Alexandre Oliva wrote: : On Mar 20, 2000, "Lars J. Aas" <[EMAIL PROTECTED]> wrote: : > I notice I've hardcoded "deplibs_check_method=pass_all" myself in ltmain.sh : > in some project, because libtool kept dropping the libs my library depend : > on... : : It would also be nice to have this defined for BeOS, if it works : properly. But I don't know if it works properly on all releases of : BeOS. Does anybody? How would I know if it really works properly? Are there problems beyond just linking up references to the dependent libraries and loading them at run-time? I know this works for x86 BeOS 4.5, and I believe (I could be mistaken) it has worked for PPC BeOS as long as I've been programming on it (since DR8). Lars J
Re: Making libtool use c++ to link c++ shared libraries.
On Tue, Mar 28, 2000 at 06:26:20PM -0300, Alexandre Oliva wrote: : On Mar 28, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote: : > How do I make the multi-lang libtool use c++ to link c++ shared libraries : > so that the c++ libraries are linked in. : : IIRC, you'd have to arrange for libtool to get an additional : configuration section with information about the C++ compiler. Which, : in configure.in speak, translates to adding a call to AC_LIBTOOL_CXX : :-) This can possibly solve my sub-project linking problem, but autoconf complains about not finding AC_LIBTOOL_CXX - where is it? Using: autoconf (GNU autoconf) 2.14.1 (the infamous one, I know) automake (GNU automake) 1.4a ltmain.sh (GNU libtool) 1.3.4 (1.385.2.196 1999/12/07 21:47:57) Lars J
Re: ML branch: okay to switch to CVS automake/autoconf?
On Sat, Jun 03, 2000 at 06:15:34PM -0700, Mo DeJong wrote: : On 3 Jun 2000, Alexandre Oliva wrote: : > Unless there's a very pressing reason to do it, I'd rather be able to : > use libtool with older releases of autoconf and automake. I don't : > like the idea of forcing people to upgrade more than one tool at a : > time, since this makes it harder to figure out where problems that : > show up with the upgrades are. : : Well, the CVS version of libtool does not work with the current CVS : version of autoconf. I am not sure if that is a "very pressing reason" : but it sure seems like a problem that is worth solving. I consider it a pressing reason. It's the reason why I, and I bet a lot of other developers too, do not follow CVS libtool, and consequently the CVS version of libtool has (a lot) less users/developers/contributers. Lars J
Re: changequote used incorrectly
On Thu, Sep 07, 2000 at 01:41:58PM -0400, Pavel Roskin wrote: : Index: ChangeLog : --- ChangeLog Thu Sep 7 08:22:46 2000 : +++ ChangeLog Thu Sep 7 13:36:19 2000 : @@ -0,0 +1,5 @@ : +2000-09-07 Pavel Roskin <[EMAIL PROTECTED]> : + : + * libtool.m4 (_LT_AC_LTCONFIG_HACK): fixed incorrect use of : + changequote : + : Index: libtool.m4 : --- libtool.m4Thu Sep 7 13:30:38 2000 : +++ libtool.m4Thu Sep 7 13:30:57 2000 : @@ -597,16 +597,16 @@ : ## END FIXME : : # Check for any special shared library compilation flags. : -changequote(,)dnl : if test -n "$ac_cv_prog_cc_shlib"; then :AC_MSG_WARN([\`$CC' requires \`$ac_cv_prog_cc_shlib' to build shared libraries]) : + changequote(,)dnl :if echo "$old_CC $old_CFLAGS " | egrep -e "[ ]$ac_cv_prog_cc_shlib[ ]" :>/dev/null; then : : + changequote([,])dnl Why not remove the changequote macros completely and use: if echo "$old_CC $old_CFLAGS " | egrep -e "[[ ]]$ac_cv_prog_cc_shlib[[ ]]" >/dev/null; then : Lars J
Re: changequote used incorrectly
On Fri, Sep 08, 2000 at 09:05:57AM -0400, Pavel Roskin wrote: : I'll try to remove changequote()s from libtool.m4 as long as it remains : compatible with Autoconf-2.13 I don't see how this can be a problem - it's strictly an m4 parse issue, and the m4 parsing is the same, no matter which autoconf you are using. Lars J
Re: Forbidden strings
On Fri, Nov 03, 2000 at 06:39:02PM +0100, Bernard Dautrevaux wrote: : So the obvious: : : what is Autoshell? Autoconf macros for partable shell scripting. : Note that my question was due to the fact that i *do* use AS_FLAGS for Can't you use ASFLAGS? You don't see C_FLAGS and CPP_FLAGS, etc. Making libtool use ARFLAGS might be pushing it, though...? Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
multi-language-branch with CVS Autoconf / Automake
I've just successfully started using CVS libtool `multi-language-branch' together with the latest and greatest CVS Autoconf and CVS Automake. I got lots of warnings while bootstrapping the archive though, and I got into a circular dependency problem in the projects trying to use libtool which I fixed with the below attached patch. Can anyone verify the validity of it, and eventually commit it to the repository? Cheers, Lars J Index: libtool.m4 === RCS file: /home/cvs/libtool/libtool.m4,v retrieving revision 1.71.2.43 diff -u -r1.71.2.43 libtool.m4 --- libtool.m4 2000/12/16 13:43:52 1.71.2.43 +++ libtool.m4 2001/01/09 14:59:24 @@ -778,8 +778,7 @@ AC_DEFUN([AC_LIBTOOL_CXX], [AC_REQUIRE([_AC_LIBTOOL_CXX])]) AC_DEFUN([_AC_LIBTOOL_CXX], -[AC_REQUIRE([AC_PROG_LIBTOOL]) -AC_REQUIRE([AC_PROG_CXX]) +[AC_REQUIRE([AC_PROG_CXX]) AC_REQUIRE([AC_PROG_CXXCPP]) LIBTOOL_DEPS=$LIBTOOL_DEPS" $ac_aux_dir/ltcf-cxx.sh" lt_save_CC="$CC" ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[PATCH] uncooperating autoconf/libtool exeext tests
Libtool 1.3.5 comes with it's own poor exe extension test (ltconfig). The Autoconf macro detects the correct exe-ext, but later when libtool is being configured, libtool doesn't inherit what configure already has detected, except if you use a cache file. You're OK with the default behaviour if you use Autoconf 2.13, but not with the latest CVS Autoconf in other words. To make Autoconf's tests override the ltconfig tests, we only need to export the variable $ac_cv_exeext. I therefore propose the following patch for CVS Autoconf: 2001-01-11 Lars J. Aas <[EMAIL PROTECTED]> * aclang.m4 (_AC_COMPILER_EXEEXT_DEFAULT,_AC_COMPILER_EXEEXT_O): Export ac_cv_exeext to environment to override incorrect exeext test in ltconfig from libtool-1.3.5. Index: aclang.m4 === RCS file: /cvs/autoconf/aclang.m4,v retrieving revision 1.106 diff -u -r1.106 aclang.m4 --- aclang.m4 2001/01/11 15:17:13 1.106 +++ aclang.m4 2001/01/11 17:23:49 @@ -659,6 +659,7 @@ case $ac_file in *.$ac_ext | *.out | *.o | *.obj | *.xcoff | *.tds | *.d | *.pdb ) ;; *) ac_cv_exeext=`expr "$ac_file" : ['[^.]*\(\..*\)']` + export ac_cv_exeext break;; esac done], @@ -684,6 +685,7 @@ case $ac_file in *.$ac_ext | *.o | *.obj | *.xcoff | *.tds | *.d | *.pdb ) ;; *) ac_cv_exeext=`expr "$ac_file" : ['[^.]*\(\..*\)']` + export ac_cv_exeext break;; esac done], ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Dynamically loading C++ Modules on Solaris
On Mon, Jan 22, 2001 at 12:57:33PM -0500, Kevin Atkinson wrote: : I should also add that I am using the multi-lib branch of libtool. multi-language, perhaps? Lars J -- Innovation is one percent inspiration and ninetynine percent perspiration, and in my case; twice that... -- Norville Barnes, `The Hudsucker Proxy' ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[patch] libtool.m4
2001-01-29 Lars J. Aas <[EMAIL PROTECTED]> * libtool.m4 (_LT_AC_LTCONFIG_HACK): clear $CYGWIN variable on cygpath invokation to avoid garbage output (depending on the setting of $CYGWIN) when the "$srcdir" argument is the empty string. Index: libtool.m4 === RCS file: /cvs/libtool/libtool.m4,v retrieving revision 1.142 diff -u -r1.142 libtool.m4 --- libtool.m4 2001/01/27 19:19:05 1.142 +++ libtool.m4 2001/01/29 15:54:52 @@ -1437,7 +1437,7 @@ old_archive_from_new_cmds='true' # FIXME: Should let the user specify the lib program. old_archive_cmds='lib /OUT:$oldlib$oldobjs$old_deplibs' -fix_srcfile_path='`cygpath -w "$srcfile"`' +fix_srcfile_path='`CYGWIN= cygpath -w "$srcfile"`' ;; darwin* | rhapsody*) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Fix for Arg list too long
On Wed, Jan 31, 2001 at 05:27:25PM -0200, Alexandre Oliva wrote: : On Jan 31, 2001, "Boehne, Robert" <[EMAIL PROTECTED]> wrote: : > SGI was one system that would not allow me to use $reload_cmds because : > $LD was set to CC. : : This is wrong. LD should be ld, not cc. That was a kludge we'd used : in the beginning of ltcf-cxx.sh to reduce the divergence from : ltcf-c.sh, but it no longer makes sense. We should go ahead and use : CC wherever we use LD, and keep LD with a sane value, which is the : name of the linker, not of the compiler. In C++ mode on IRIX, you need to link libraries with CC (the C++ compiler) and not with ld (which only handles C linking correctly). Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Problem with MPB installation
On Fri, Mar 23, 2001 at 03:37:22PM -0300, Alexandre Oliva wrote: : On Mar 23, 2001, Maria Chiara Ubaldi <[EMAIL PROTECTED]> wrote: : : > ERROR In procedure dynamic-link: : > ERROR File not found : : Not without a lot of additional information. For example, on which : platform is that? Where is the error coming from? Where does libtool : fit into this picture? It looks like a Guile error to me. I'd guess there's a guile script trying to open a shared library and fails, so check that it's reachable by $LD_LIBRARY_PATH, or that the packages are configured correctly, if the shared library is specified with a full path. Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ltconfig fails during 'configure'
On Tue, Apr 17, 2001 at 01:11:45PM -0500, Robert Boehne wrote: : It seems that every : time I try to configure, ltconfig fails because it doesn't : get $host set. Here's the message from configure: : : checking whether ln -s works... yes : ltconfig: you must specify a host type if you use `--no-verify' : Try `ltconfig --help' for more information. : configure: error: libtool configure failed This problem disappears if you invoke AC_CANONICAL_SYSTEM in configure.in before AC_PROG_LIBTOOL. Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Problem with autoconf 2.13
On Mon, Apr 30, 2001 at 03:22:55PM +0200, Alexander Mai wrote: : BTW, can anyone give estimated release dates for : autoconf/automake? Autoconf - in roughly a week or so? Automake - in the blue? Lars J -- Innovation is one percent inspiration and ninetynine percent perspiration, and in my case; twice that... -- Norville Barnes, `The Hudsucker Proxy' ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.4: "make uninstall" broken?
I installed libtool 1.4 in the wrong place and then tried "make uninstall" before doing a reconfigure. It complained about not finding "install-info" or something - I didn't care to investigate further. Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool´Ô ¾È³çÇϼ¼¿ä?
On Mon, May 14, 2001 at 01:19:20PM -0700, Howard Chu wrote: : ¿Â¶óÀÎÄÚ¸®¾Æ wrote: : : ¢Ä ¿À´ÃÀÇ À¯¸Ó ¢Å : : My thoughts exactly, that was most enlightening. Did you try rot13? :) Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]
On Thu, Jun 07, 2001 at 11:30:22PM +0200, Marcelo E. Magallon wrote: : needs a way to be able to set the soname. Yes, this is bad in general. : It defeats the whole purpose of libtool, but the problem is that Mesa : is providing another version of an existing library. I can imagine : things like Motif (lesstif), OpenInventor (Coin, mostly non issue now) : are in the same situation. Just to digress; for Coin we use the soname libCoin.so.#.#.# (normal libtool version-info) because Open Inventor is C++, and achieving ABI-compatibility with it is impossible. I don't even think either SGI or TGS Open Inventor is ABI-compatible with itself for many version-increments at a time. Of course, your point is still valid for the situation with Mesa and Lesstif. Another digression; I'd like to know what you meant with the "mostly non issue" comment. Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]
On Thu, Jun 07, 2001 at 11:50:44AM -0600, Brian Paul wrote: : I'm not going to put a lot of effort into explaining this but here's : the story. : : Mesa's used the convention libGL.so.1.2.xxyyzz for some years now. : The "1.2" indicates the library implements the OpenGL 1.2 API. : Anything else there would be VERY confusing for end users at this : point. You probably won't be able to use that scheme with libtool without changing libtool. libtool doesn't just pass the integers through the system for library naming reasons. Another thing is that how the numbers are set up depends on the system (e.g. on IRIX, the age part is dropped from the library filename, and the current part is incremented by one). Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.4.2 + darwin problem
On Tue, Sep 11, 2001 at 05:06:51AM +0100, Gary V. Vaughan wrote: : I am pleased to announce the release of GNU Libtool 1.4.2, which now I haven't investigated this problem that thorough, but on a "powerpc-apple-darwin1.3.7" system (an iBook) I had to change the $archive_cmds variable (in libtool.m4 for libtool 1.4.2 (serial 46)) from archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linker_flags -install_name $rpath/$soname $verstring' to archive_cmds='$nonopt $(test x$module = xyes && echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $linker_flags -install_name $rpath/$soname $verstring' to get around a problem with the final linker line having duplicated the list of convenience libraries. $libobjs contained both the .los and .las, and $deplibs contained all the .las, so the link stopped with duplicate symbol errors. I also had to remove the "s to get around a weird quoting problem. Is this a known issue? A local problem? libtool is used in combination with Autoconf 2.52 and Automake 1.5. Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: use of libtool for linking executables - rpath problem
On Mon, Nov 19, 2001 at 11:36:21PM -0800, Russ Allbery wrote:
: Bob Friesenhahn <[EMAIL PROTECTED]> writes:
: > How is the application developer to know which directories are searched
: > by default?
:
: One can safely assume that /usr/lib and /usr/include are always searched
: by default. Those are the only ones that I'd expect people to
: automatically leave out of the package configuration scripts.
There are always exceptions. A bunch of projects I am a developer on uses
the MS Visual C++ compiler when building on Cygwin platforms. Would you be
surprised to know that VC++ does *not* search Cygwins /usr/include for
headers by default? :) Of course, I agree we should avoid including
-[IL]/usr/{lib,include} flags in *-config output for platforms were that
path is searched by default...
Lars J
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
MKS Bourne Shell "case" weirdness...
Hi guys,
When porting our autoconf/automake/libtool setup for Coin
(www.coin3d.org) to work on MKS, I found that I had to apply the
following patch to Autoconf 2.57 to get the generated config.status
script to behave:
--
--- lib/autoconf/status.m4.orig Thu Jun 12 15:46:43 2003
+++ lib/autoconf/status.m4 Fri Jun 13 16:05:01 2003
@@ -502,6 +502,7 @@
for ac_file in : $CONFIG_HEADERS; do test "x$ac_file" = x: && continue
# Support "outfile[:infile[:infile...]]", defaulting infile="outfile.in".
+ true # MKS oddity
case $ac_file in
- | *:- | *:-:* ) # input from stdin
cat >$tmp/stdin
@@ -933,6 +934,7 @@
cat >>$CONFIG_STATUS <<\_ACEOF
for ac_file in : $CONFIG_FILES; do test "x$ac_file" = x: && continue
# Support "outfile[:infile[:infile...]]", defaulting infile="outfile.in".
+ true # MKS oddity
case $ac_file in
- | *:- | *:-:* ) # input from stdin
cat >$tmp/stdin
--
and the following patch to Libtool 1.5 to make the generated libtool
script work:
--
--- ltmain.in.orig Fri Jun 13 11:59:42 2003
+++ ltmain.in Wed Jun 18 12:19:39 2003
@@ -212,6 +212,7 @@
fi
# Have we seen a non-optional argument yet?
+ true # MKS weirdness
case $arg in
--help)
show_help=yes
@@ -389,6 +390,7 @@
;;
normal )
+ true # MKS weirdness
# Accept any command-line options.
case $arg in
-o)
@@ -531,6 +531,7 @@
if grep "^# ### BEGIN LIBTOOL TAG CONFIG: $z$" < "$0" > /dev/null; then
# Evaluate the configuration.
eval "`${SED} -n -e '/^# ### BEGIN LIBTOOL TAG CONFIG: '$z'$/,/^# ### END
LIBTOOL TAG CONFIG: '$z'$/p' < $0`"
+ true # MKS weirdness
case "$base_compile " in
"$CC "* | " $CC "* | "`$echo $CC` "* | " `$echo $CC` "*)
# The compiler in the base compile command matches
@@ -1635,6 +1636,7 @@
if grep "^# ### BEGIN LIBTOOL TAG CONFIG: $z$" < "$0" > /dev/null; then
# Evaluate the configuration.
eval "`${SED} -n -e '/^# ### BEGIN LIBTOOL TAG CONFIG: '$z'$/,/^# ### END
LIBTOOL TAG CONFIG: '$z'$/p' < $0`"
+ true # MKS weirdness
case $base_compile in
"$CC "* | " $CC "* | "`$echo $CC` "* | " `$echo $CC` "*)
# The compiler in $compile_command matches
--
Without inserting a dummy command above those "case" statements,
they would not run in certain cases, causing config.status/libtool
to mess up and break the build. I could have used "echo" instead of
true, but using the nop/true ":" does not work.
Does anyone know anything about this bug in MKS' sh implementation?
Autoconf supports MKS so I would find it weird if noone has run into
similar problems earlier? Is it possible that this is a local
problem for the given MKS user I am working with and that he may
have a somewhat faulty MKS installation or something? It's
apparently the same on top of both NT4 and XP.
All ideas are appreciated...
There were BTW more problems wrt MKS porting, but I'm attacking this
one separately first...
Lars J
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: MKS Bourne Shell "case" weirdness...
Hi Paul, Paul Eggert <[EMAIL PROTECTED]> wrote: : "Lars J. Aas" <[EMAIL PROTECTED]> writes: : > Is it possible that this is a local problem for the given MKS user I : > am working with and that he may have a somewhat faulty MKS : > installation or something? : : Possibly. It'd be nice if we could have another MKS user report what : happens. Or perhaps you or your user can consult the MKS bug database : (I can't; it's private). OK, I'll see what I can do in this regard. I don't have access to their bug database either. : > When porting our autoconf/automake/libtool setup for Coin : > (www.coin3d.org) to work on MKS, I found that I had to apply the : > following patch to Autoconf 2.57 to get the generated config.status : > script to behave: : : Hmm, that looks pretty ad-hoc. No doubt about that :) : Why did you need to change just these : case statements, and not all the case statements in Autoconf and : Libtool? What were the symptoms of the failure? The symptoms were that the case didn't trigger any of the cases so the switch-var just fell through and no code was executed. For the argument parsing loop, this happens to very specific arguments. We first thought the case dropped arguments with /-characters in them, but I now believe it is something in the setup-code in the previous iteration of that loop that causes the case to not trigger unless the shell state is changed by running the dummy true-command. Anyways, while debugging the loop, adding echo of the variable being parsed caused the bug to disappear, so that's how we ended up with the current patch. : Do you have a small shell script that illustrates the problem? No. I was going to check with you guys if it was a known problem first before digging deeper into the matter. : Unless we understand the bug I'm a little leery of trying to insert : "true"s seemingly at random. I totally agree. The bug must be figured out to make a proper fix. It's a hassle to debug from remote though :( and I probably won't get around to look into this further for another two weeks. Lars J -- Reality is that which, when you stop believing in it, does not go away. -- PKD ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MKS Bourne Shell "case" weirdness...
Regarding MKS sh and case/esac, I ran into another weird problem during the MKS port which caused us to have to reorder a couple of case switches in ltmain.in. At line 1229, you will find -L*) dir=`$echo "X$arg" | $Xsed -e 's/^-L//'` # We need an absolute path. [...] -l*) if test "X$arg" = "X-lc" || test "X$arg" = "X-lm"; then case $host in When this case switch gets to the argument -lXm, it enters the first -L*) case instead of the -l*) case. Reordering the two cased libtool to enter the -l*) case (don't know if -L arguments failed though). Anyways, we've now found out what that problem was caused by: | http://www.mkssoftware.com/support/kb/articles/kb20014.asp | | ** | Knowledge Base Article #20014 | | | How do I make a case statement case-sensitive? | | Product(s): Toolkit | Operating System(s): Windows NT, 9x, 2000, ME | Keyword(s): case, sensitive, DUALCASE | | Question: | How do I make a case statement case-sensitive? | | Answer: | Case statements use the file name generation feature of the shell which is | normally case-insensitive. It is documented in the sh(1) reference. If you | want to make file name generation case-sensitive then set the variable | DUALCASE to a non-zero value. | Example: | |DUALCASE=1 |case "$1" in | -r*) echo r;; | -R) echo R;; | *) echo other |esac |unset DUALCASE | | | Note that as of version 7.5 a new vaiable has been added. Setting | TK_DUALCASE_IN_CASE_STATEMENTS to any value will make pattern-matching in | case statements case-sensitive. When TK_DUALCASE_IN_CASE_STATEMENTS is not | set, the DUALCASE environment variable determines whether or not | pattern-matching is case-sensitive in the same way it does for file name | generation. | | *** Setting up DUALCASE near the top of libtool solved the problem. I've grepped through all the Libtool and Autoconf files for any mention of the variable DUALCASE, but I found none. I would probably go for setting both DUALCASE and TK_DUALCASE_IN_CASE_STATEMENTS to try to get sh to be as sane as possible, but I'm not completely sure I understand the implications of the differences between the two yet (caffeine-level is too low yet). Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MKS Bourne Shell "case" weirdness...
Paul Eggert <[EMAIL PROTECTED]> wrote: : "Lars J. Aas" <[EMAIL PROTECTED]> writes: : : > Is it possible that this is a local problem for the given MKS user I : > am working with and that he may have a somewhat faulty MKS : > installation or something? : : Possibly. It'd be nice if we could have another MKS user report what : happens. Or perhaps you or your user can consult the MKS bug database : (I can't; it's private). The MKS user made a small example of the bug and set to MKS and got in reply that this bug was fixed in MKS v8.5 (which he hasn't upgraded to because they dropped support for Motif 1.2 in that version). He hasn't been able to get them to spill the actual details of the bug yet though, but he's working on it. Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
