http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=7890173078d185548f1f058322d8ddc3b18cfc81
I am not a native English speaker, but I find the use of may use a
bit confusing in the added text. I would suggest changing some
instances of may use to are able to use and some to might be
using.
That is just not sane engineering practice.
I'd even consider
installing 64bit packages in a separate --prefix from 32bit ones to be
good packaging practice,
GCC is a *special* case, to be fixed in the GCC package. Don't confuse
the compiler+tools special cases with the rest of normal
The issue is that libtool
uses the lib prefix for both 64bit and 32bit DLLs, and for both mingw
and mingw-w64.
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
I'm not sure that idea for lib{64|32} is so good.
Me neither, but,
As I know for 32 bit process 64 bit microsoft windows os will return
%WINDOWS%\SysWOW64 as system folder. For 64 bit process it is
%WINDOWS%\System32
I fail to see what *that* has to do with it. Surely nobody builds any
DLL
Working on this now. Curious what people think of this, and if there's a
better way that I'm missing (other than ditching MS which unfortunately
isn't an option at the moment).
Just offer your libraries only as DLLs... that bypasses this whole
mess. That is what many people who distribute
#ifdef _WIN32
executable_name = strrchr (argv[0], '\\');
Bzzt. You have to use the multi-byte character set aware _mbschr() and
_mbsrchr() functions from mbchar.h to search for backlashes (or
slashes) in narrow (char *) system code page strings (for instance,
file names) on Windows. The East
Well I've always needed to get the filename (somewhat related to the library
version) when building Windows DLLs that I can prepare a resource.in file,
grep '^dlname' libfoo.la | sed -e s/dlname=// -e s/'//g ?
But yeah, this is a chicken-and-egg problem, you want the full DLL
name in the
if I want to print the library version from a program
is it correct to print 2:0:1 or 1.1.0?
What exactly do you mean with library version ? Note that neither
the libtool triple current:revision:age nor the Linux-style suffix it
causes to be appended after the .so correspond to the actual
What is the recommendation on distributing .la files in the Windows
devel package of some library? Personally I never do it in the
software I build and distribute for Win32 (and nobody has complained),
but now I have come across one devel package by another guy that does
include .la files in
Let me just point out another, old but apparently not well known, more
portable imrovement on libtool, libtool-cache. libtool-cache doesn't
replace libtool, but as can be guessed from its name, it just avoids
running libtool if the actual shell commands that would be executed by
libtool can be
Shouldn't plug-in -type shared libraries be built with the -module
-avoid-version libtool flags? I think with those flags, such
libtool-built DLLs get installed in the libdir of the Makefile in
question, not libdir/../bin like normal DLLs.
--tml
___
Bruno Haible writes:
You appear to be using mingw as a development environment. I don't know
whether libtool supports that.
If with mingw one combines MSYS, it certainly does. Using MSYS with
auto* and libtool is IMHO much more reliable than using Cygwin, MSYS
gets less in the way and causes
Bob Friesenhahn writes:
Libtool does support using the MinGW compiler via Cygwin or
MSYS (I have only tried MSYS). Both of these support Unix type paths
and automatically convert to Windows paths for MinGW.
I don't think Cygwin does that to the same extent as MSYS. Isn't that
the exact
Just throwing out (or throwing up ;-) some ideas...:
Has anybody investigated using busybox on Cygwin? Or something
similar? I.e. binding the code for the most common GNU utitilies (sed,
m4, gawk, expr, cp, cat, ls, rm, ln, echo) more tightly to the shell,
perhaps building them as DLLs, and
Robert Ögren writes:
2. configure.in did not have AC_LIBTOOL_WIN32_DLL which now is required
for OBJDUMP to be set.
Hmm. Wasn't AC_LIBTOOL_WIN32_DLL supposed to be deprecated and
unnecessary? Or was it just that at some point it was de facto
unnecessary but never officially deprecated, and
Bob Friesenhahn writes:
It turns out that the dirent related functionality provided with
MinGW is hoisted from Cygwin. As such, it has GPL restrictions.
Errr, certainly not. Maybe you are thinking of the dirent
implementation in MSYS? MSYS *is* a fork of Cygwin. MSYS is an
environment for a
Bob Friesenhahn writes:
Yes, I am talking about building using MSYS.
Not just *using* MSYS (i.e. using MSYS's shell, sed, m4, awk etc), but
*for* MSYS, right? Targetting MSYS is not something one would commonly
do, is it? The whole point of MSYS is that it is a runtime used by
development tools
Ralf Wildenhues writes:
Linking is a problem, though: shell wrappers break,
I have never liked (or understood...) libtool's shell wrappers or its
relinking on Win32. I always use --disable-static, I always run a
make install, and make sure the bin directory of the installation
location is in
At first I thought that would be to absorb pkg-config's
functionality into libtool (to avoid duplication of code and
maintenance),
Just in case somebody still ponders this, please take into account
that pkg-config works even for people on Windows who use MSVC (the
command-line tools, not
Bob Friesenhahn writes:
While Cygwin does provide a compiler mode in which it may compile
programs which use the MinGW library, there may be some problems with
crossing over between the two environments.
This might be obvious to many, but anyway:
I have found that to ensure a mixture of
Max Bowsher writes:
If so, relinking is definitely never required on Windows, because *no* path
information is recorded in executables.
Hear, hear!
I resorted to disabling that section of code in ltmain.sh with a case
statement.
Ditto.
--tml
Earnie Boyd writes:
I've seen some looong command lines, not that I've stopped to count
the characters. The 8192 may not be enough for some packages.
I have experienced that the 8192 (umm, don't remember exactly, some
pretty low limit anyhow) wasn't enough for GTK+, and libtool started
Steve M. Robbins writes:
then you can just reverse-engineer
the computation that libtool does. Then choose values for Current,
Revision, and Age that give you the answer you want.
Or choose fresh current, revision, age values that won't cause a clash
with your current name now or in the
Guido writes:
Aren't these two interrelated? I thought that the relink step was
done to try to ensure the libs have a different image-base, even
though it might never been implemented that way...
Umm, never thought of that. I thought that the relink was done because
of some issues with search
;;
- *) . ./$file ;;
+ */* | *\\*) . $wrapper ;;
+ *) . ./$wrapper ;;
esac
Cheers,
Tor Lillqvist
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
In current CVS libtool.m4, the code that outputs the included ltdll.c
and impgen.c is indented four spaces. Including the lines with
_LT_AC_FILE_LTDLL_C and _LT_AC_FILE_IMPGEN_C. Thus the start marker
lines also get indented in the resulting libtool script. However, when
libtool goes looking for
files), compiled by the
resource compiler (windres in mingw) to .o files.
-- Minor bug fix for $PATH elements with spaces in them when looking
for nm.
-- I think there was some confusion with trailing spaces in
$base_compile in ltmain.in?
ChangeLog entry:
2001-09-15 Tor Lillqvist [EMAIL PROTECTED
Gary V. Vaughan writes:
The attached files are FYI, and represent the commits I made to HEAD.
+ yes,cygwin*)
+ library_names_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} |
[sed -e 's/[.]/-/g']`${versuffix}.dll'
+;;
+ yes,mingw*)
+
New try... I changed "lib" to "cyg" in the wrong place. Sorry. Now it
should affect only the name of the dll (and related files), I hope.
--tml
Index: libtool.m4
===
RCS file: /cvs/libtool/libtool.m4,v
retrieving revision 1.142
Gary V. Vaughan writes:
If libtool doesn't already find non-libtool libraries on mingw, then that is
a bug. libtool works with non-libtool libraries on the other architectures
to which it has been ported. Patches gratefully accepted (I think this
should be quite straight forward).
30 matches
Mail list logo
