The GCC-specific code operates (and must operate) per libtool invocation, not at configure time. GCC is used to find the files if a) GCC is in use (as determined by configure) and b) the GCC in use s
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=li
Hi Bob, Joe, libtoolers: Bob Friesenhahn wrote: It seems that the only valid test to determine the default output architecture is to compile code and then use 'file' or some other utility to determi
Well, the difference, in my little mind at least, is that the commercial unixes can all be identified in libtool using $host, Right, you can identify $host and in case of Solaris even the OS version
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 rej
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 reje
(Hiya. I have recently become Red Hat's libtool package maintainer.) Hi Daniel, On 2004-08-11T00:32+0900, Peter O'Gorman wrote: ) Joe Orton wrote: ) > It always disappoints me to do so too, that's w
(Hiya. I have recently become Red Hat's libtool package maintainer.) On 2004-08-11T00:32+0900, Peter O'Gorman wrote: ) Joe Orton wrote: ) > It always disappoints me to do so too, that's why I'm makin
Peter I am not setting these myself and they don't seem to be coming from any library dependencies. The section of the Makefile.am that deals with the library is essentially: INCLUDES = -I$(top_build
On 2/1/2010 01:18, Roumen Petrov wrote: JonY wrote: On 1/31/2010 02:14, Roumen Petrov wrote: I don't understand request as the usually final result is .../libfool.la .../libfool.dll.a .../libfool.dll
* JonY wrote on Sat, Jan 30, 2010 at 05:29:31PM CET: No, you're getting it wrong again. If all systems you're interested in do skip incompatible DLLs properly, then there is *absolutely* no reason an
This works fine, until mingw-w64 showed up with 64bit dlls. This problem is especially apparent with trying to build mingw-w64 cross compilers. For example, both mingw and mingw-w64 builds libstdc++-
libtool should also check if GCC "-m32" or "-m64" is used, and select the proper namespace accordingly (mingw-w64 GCC can do multilib). Comments? This is highly none standard naming convention... Han
Currently, on Win32 platforms, Cygwin uses the "cyg" prefix for dlls, and MinGW based systems uses the "lib" prefix. This works fine, until mingw-w64 showed up with 64bit dlls. This problem is especi
HI , I have tested 1.5.23b in mingw in Windows XP, but I still find the bug of libtool. The bug is : If I build my project in directory same as source code directory, the built file can't be run. for
The Libtool Team would like to announce alpha release 1.5.23b of GNU Libtool. GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships wit
AFAIU, all'd you do here, is to invent a convention to be able to apply a similar hack to libtool addressing sparc-sun-solaris as the RH patch does. This does not solve the troubles libtool is facing
In the scheme we use, $host would be sparc64-sun-solaris2.8 . -- Daniel Reed <address@hidden> http://people.redhat.com/djr/ http://naim.n.ml.org/ The reasonable man adapts himself to the world; the u
Actually, it wouldn't. :) The actual problem is that software packaged with stock Libtool does not build properly in our multilib build roots. Right now, we have to manually re-bootstrap several of o