Sun Studio 11 request ...
I am using 1.5.22 of libtool and noticed that libtool hard codes -lCstd and -lCrun. It would be better for libtool to use -library=Cstd by default and allow the user to over write if they pass -library on the command line. This is an issue for me as I need the stlport4 library's definition of the std C++ library. I have had to had patch libtool for several packages (including my own) because of this limitation. Thanks, Ed smime.p7s Description: S/MIME Cryptographic Signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
I believe the problem being described here is one that I have encountered also since I use stow for package management. A long time ago, it use to be the case you could say: ./configure --prefix=/dest make make prefix=/dest/stow/package-package version install even if the package installed shared objects. With more recent versions of libtool, I have had to add the --with-libdir=/dest/stow/package-package version/lib to allow proper installation. Ed Ralf Wildenhues wrote: Hello Jeff, * Jeff Blaine wrote on Fri, Sep 22, 2006 at 04:17:07PM CEST: Okay, I've run into this enough that it's taken its toll on me and I must know the proper modern way to handle this. Hmm. This sounds like it used to work before and we broke something. Is it what you are implying? For years and years, the following worked fine for any GNU app using autoconf: ./configure --prefix=/my/final/destination make make install prefix=/my/to-be-released/destination Not with Libtool-using packages, at least not bug-free, as far as I remember. make install DESTDIR=/my/staging/directory works to install your stuff temporarily into /my/staging/directory/my/final/destination from where it can be moved to /my/final/destination and, after a libtool --mode=finish /my/final/destination/lib libraries should be useable. There are issues in current libtool that prevent this from working properly in _some_ cases when you try to link against third-party libraries that currently are visible below /my/staging/directory/my/final/destination but are to finally appear at /my/final/destination/ See some other discussion on this list just this week. It has often not worked when involving libtool over the last year or two and it's driving me nuts. Can someone PUHLZE tell me the right way to do this? Well, I'm really sorry you've had so much trouble, and I can only ask to report issues earlier. If you think there is a regression involved then please point me to a package where this should have worked. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool smime.p7s Description: S/MIME Cryptographic Signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Spaces in path names
Roger While wrote: Actually on Cygwin (and MingW) this whole thing is caused by the following lines in ltmain.sh : -L*) dir=`$echo X$arg | $Xsed -e 's/^-L//'` # We need an absolute path. case $dir in [\\/]* | [A-Za-z]:[\\/]*) ;; *) absdir=`cd $dir pwd` Have you tried: absdir=`cd $dir pwd` As this would be truer to the original intent. And there is the probem. Replacing that last line with a simple absdir=$dir and, what do you know, everything works as it should. Of course, leaving as original, it is a heck of a problem trying to trace further usage of absdir and dir. THe question is, of course, what is the downside of this change (locally for our product). Roger On Thu, 12 Jan 2006, Roger While wrote: Hi Ralf, Well, how ARE you supposed to get around this ? Here's an excerpt : HOME is /cygdrive/c/Dokumente und Einstellungen/Roger While build directory is $HOME/open-cobol-0.33 Due to the many layers of shell scripting in libtool, supporting spaces in filenames is complicated and must be proven for every case. It is a huge job. Since you are using Cygwin, you should be able to use Cygwin's 'mount' facility to map the problem path so that it appears as a path without spaces in the name. Of course, this approach is not as user friendly as it could be and requires extra effort on the part of the person who builds the package. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool Ed smime.p7s Description: S/MIME Cryptographic Signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Help: 64 Bit Solaris 10
Ralf Wildenhues wrote: * Tim Rice wrote on Tue, Dec 06, 2005 at 02:25:32AM CET: On Mon, 5 Dec 2005, Edward Maros wrote: This may be a frequent question, but I have not been able to find a solution yet. I am trying to port out application to 64bit using a sparc4u running Solaris 10. The application uses autoconf/automake/libtool/gcc for configuration and building of targets. With my first attempt at going 64 bit, I hit a problem since libtool seems to configure only 32bit (at least for creating shared objects). Am I missing something that I could do to make the leap to 64 bit? Try CC=gcc -m64 ./configure Yes. 1.5.22 will also allow configure CC=gcc CFLAGS=-m64 or, FWIW, configure CC=cc CFLAGS=-xarch=... to function correctly. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool Thanks to everyone's suggestions. It has been very insightful on how libtool works. I am now able to compile my applications for 64bit Solaris. With the insight that I received from this exercise, I was wondering if any thought had been given to dynamicly creating the libtool shell script as part of the configuration of a package. With GCC being able to support 32bit and 64bit compilations, it would be nice if libtool would have the same or similar flexibility. I do recognize that libtool has the additional complication that it has to make decisions based on the compiler being used to compile the application. Thanks, Ed smime.p7s Description: S/MIME Cryptographic Signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Help: 64 Bit Solaris 10
This may be a frequent question, but I have not been able to find a solution yet. I am trying to port out application to 64bit using a sparc4u running Solaris 10. The application uses autoconf/automake/libtool/gcc for configuration and building of targets. With my first attempt at going 64 bit, I hit a problem since libtool seems to configure only 32bit (at least for creating shared objects). Am I missing something that I could do to make the leap to 64 bit? Thanks, Ed smime.p7s Description: S/MIME Cryptographic Signature ___ http://lists.gnu.org/mailman/listinfo/libtool
