Hi, I'm not entirely sure how to avoid 64bit vs 32bit mingw-w64 clashing if both use the same DLL naming scheme. Anyway, enough talk, attached is a very crude but working conceptual patch that makes
Well, my take is that except for people working on the *tools themselves* (meaning gcc, binutils etc), this is not really a problem. Sure, libtool is a tool used by developers, but the end result, D
* JonY wrote on Tue, Jan 26, 2010 at 04:26:32PM CET: MinGW and MinGW64 should cooperate on issues like this. Libtool has little to no bearing here, except to follow. Libtool cannot decide what the ru
Wow, this is interesting. I remember that one guy asked about the dll prefix and he has been advised to strip the prefix from the library name and add the '-module' flag to libtool in order to silenc
AFAIK if you use automake, you have to have something like the following line in Makefile.am: lib_LTLIBRARIES = libfoo.la This means that the 'lib' prefix doesn't actually come from mingw, but from y
Hi, 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 es
i'm not familiar with "GraphicsMagick" at all, and maybe i fail at searching, but i dont see it in the Gentoo portage tree. i do see imagemagick, but i'm guessing that's a different package ? my desk
I agree with this. I started out using the default redhat method of lib64 and lib. After a while, and adding more platforms, compilers, versions, etc. I found it useful to almost always use different
I've been using libtool quite happily for some time but have just started looking at packaging libraries for x86_64 systems. I'm trying to find out what the recommended method is for installation of
The Libtool Team is pleased to announce alpha release 2.1b of GNU Libtool. GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with G
The Libtool Team is pleased to announce the release of GNU Libtool 1.5.24. GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with G
Hello Tim, Should a single libtool handle both 32bit & 64bit builds on Solaris with Sun Studio 11? No. I tried using it to build libiconv-1.10 and got ..... cd src && gmake all gmake[1]: Entering dir
Hi Pierre, * Pierre Ossman wrote on Mon, Feb 27, 2006 at 09:15:34AM CET: http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=multilib&submit=Search%21&idxname=libtool&max=20&result=normal&sort=scor
* Gary V. Vaughan wrote on Mon, Aug 22, 2005 at 10:00:50PM CEST: The following is not very well ordered, not very well cross-referenced, has nonempty overlap with the in-tree TODO file (sorry), is no
* Graham Leggett wrote on Fri, Aug 05, 2005 at 03:26:30PM CEST: So, one workaround would be: Don't put libstdc++ in a directory full of shared libs when you want to use more than one libstdc++. One s
Hallo Ralf! The implementation looks fine to me, and works on Good work! Tested with: ash-0.3.8, bash-2.05b, pdksh-5.2.14 and zsh-4.1.1, all using GNU sed 4.0.9. Here are some more ideas: 1. We could
One step toward integrating Linux multilib support, but a Libtool requirement independent of that goal, is comparison of normalized paths. In a nutshell, I'd like to be able to decide that ../foo/../