Re: libtool versioning
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. (It should be clear in what way I mean, I hope...) Hopefully that will make the text even clearer. --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
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 packages. I agree fully with Ralf on all points. --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
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 the end result, DLLs, are intended to be used by end-users running applications. I see two cases. 1) On 32-bit Windows, no end-user should in a normal scenario be having 64-bit binaries anyway. (End-users use installers, which surely should check whether the OS is a 64-bit one before installing 64-bit binaries. If somebody is unzipping some random archive containing 64-bit DLLs onto his 32-bit system and setting up PATH to include them, they aren't really end-users but wannabe hackers doing stuff they really don't understand. One can't protect against people like that.) Case 2) On 64-bit Windows, it's fine to have in PATH two instances of a DLL with the same name, one being 32-bit and the other 64-bit. The runtime loader will load the correct one when some other module (exe or dll, 32- or 64-bit) requires it. This has nothing to do with Windows naming schemes, DLLs can be named anything, including with a .so extension. This has to do with libtool DLL naming schemes. I'm working to prevent DLLs from overwriting each other, especially on install for multilib gcc. That is then something gcc's configury should be fixed to handle. It may skip paths when encountering DLLs of the wrong bitness on Win64, That is indeed my impression too. (Please, let's try to avoid using the convenient, but wrong, term Win64. The Win32 API can be either 32- or 64-bit. Using 64-bit Windows is not that much more verbose.) not so on Win32, where it fails automatically when encountering 64bit versions of 32bit DLLs with the same name. Yeah, but as I said above, my opinion is that such a situation with 64-bit DLLs present on a 32-bit Windows is an anomaly that in reality occurs only on machines of *developers* working on cross-builds of the MinGW toolchain itself, or cross-builds of other software. Such people should just know what they are doing. And if the build mechanism of some software incorrectly makes it so that the OS tries to use cross-built binaries not intended for the build system, that is the problem of the build mechanisms of the software in question. Not a libtool problem. === I guess my main point is: === This is in no way unique to cross-building from 32-bit Windows to 64-bit Windows. You can't say from the name of an ELF shared object as produced by libtool what architecture it is for either. Or do you suggest that libtool should start using a platform triplet specific prefix in *all* instances instead of just lib? --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
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 that is to be installed in the Windows system32 folder using
libtool?
--tml
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: different flags for static and shared
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 various Open Source libraries as Windows binaries do. --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Multipurpose binaries with different names
#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 Asian double-byte code pages have two-byte characters where the second byte is backslash or slash. Alternatively, use the Unicode (wide character) APIs and wchar_t variables and pointers. That makes it harder to share the same code snippets between Unix and Windows, though. --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: printing library version
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 version resource, and you want to link the resource object into the DLL, but you won't know the name libtool will use for the DLL before it has been built. Except if you cheat and just know how libtool will generate the name based on the current:revision:age triple passed to it... Maybe running libtool with the --dry-run option and pass its output through some suitable sed script to pick up the output file name would be a usable way to avoid having to duplicate the knowledge of libtool's naming strategy? --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: printing library version
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 version
number for most libraries.
Isn't it simplest to just pass a -DMYLIB_VERSION=a.b.c.d when
compiling and then have a function
const char *
mylib_get_version(void)
{
return MYLIB_VERSION;
}
or something like that?
--tml
___
http://lists.gnu.org/mailman/listinfo/libtool
Distributing .la files in devel packages for Windows?
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 addition to static and import libraries. The .la files contain pathnames totally local to his build machine. Surely this doesn't make sense? It causes trouble at least for me when I then build some other software that uses the library in question, and if I just remove the .la files from his package, the trouble goes away. The library in question also comes with a .pc file, which should take care of the dependencies, so there is no need for a .la file to tell the depencencies (when using the static archive of the library). (pkg-config on Windows takes care of making .pc files freely installable in any location without having to edit the prefix in the .pc file.) --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half
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 known beforehand. I have been using libtool-cache with good success for several years. It speeds up builds on Win32 very nicely. http://libtool-cache.sourceforge.net/ Maybe some libtool-cache-like functionality could even be integrated into libtool itself in the future? --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw install directory for shared lib
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 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling with MinGW
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 less confusion. I use a recent cygwin as the development environment, and mingw only as the deployment environment. How can mingw be a *deployment* environment (with which I assume you mean what end-users have), why would end-users of some native Win32 application need a compiler and linker? --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling with MinGW
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 reason why MSYS was developed (as a fork of Cygwin), to get automatic translation of Unix type paths passed on the command line or as environment variables to non-Cygwin/MSYS programs? --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Slow shell script execution on Cygwin
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 instead of running them as separate forked processes, as threads? I did once build busybox on Cygwin, but it didn't work well enough, and I didn't spend any more time on it. Hmm, but I guess the fork/exec separation makes this harder, Cygwin can't know when it is emulating fork() whether the child process will immediately exec() one of the above. Or does the Cygwin shell(s) already have some special code instead of plain fork()/exec()? Yeah, I know, I should have a look and try some hacks myself. (Un)fortunately, I'm quite busy with other stuff. --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Speeding up libtool
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 now if using libtool HEAD it is again necessary ? --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
dirent functions under MinGW
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 configure shell script and the tools it invokes. When you develop software with mingw and MSYS, the produced binaries in no way use MSYS. The dirent implementation bundled with mingw is in the public domain: /* * dirent.c * This file has no copyright assigned and is placed in the Public Domain. * This file is a part of the mingw-runtime package. * No warranty is given; refer to the file DISCLAIMER within the package. * * Derived from DIRLIB.C by Matt J. Weinstein * This note appears in the DIRLIB.H * DIRLIB.H by M. J. Weinstein Released to public domain 1-Jan-89 * * Updated by Jeremy Bettis [EMAIL PROTECTED] * Significantly revised and rewinddir, seekdir and telldir added by Colin * Peters [EMAIL PROTECTED] * */ /* * DIRENT.H (formerly DIRLIB.H) * This file has no copyright assigned and is placed in the Public Domain. * This file is a part of the mingw-runtime package. * No warranty is given; refer to the file DISCLAIMER within the package. * */ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dirent functions under MinGW
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 (configure-time and later) only, isn't it? Which means that unsuspecting programs built under MSYS (e.g. libltdl) may end up being GPLed by accident when it was assumed that only GPL-free MINGW headers/libraries were used. That is then a very wrong assumption. To build *for* MSYS, I assume you have downloaded the MSYS sources and use the headers from there? There certainy is no dirent.h in the MSYS package that people who just *use* MSYS install. The dirent.h provided with mingw, on the other hand, is the public-domain one, and the dirent implementation that programs built using mingw (and MSYS) use is the public-domain one. (Unless you have seriously mixed up things yourself and copied stuff here and there.) --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Speeding up libtool
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 my PATH, before any make check. And I always comment out the need_relink=yes in any ltmain.sh that I come across ;-) This means shell wrappers won't be produced. Or am I completely confused? How much is the actual speedup in numbers? Very significant. I don't have my old machine (450 MHz PIII running Win2k) around any longer, but libtool-cache made it feel like a totally new machine. A rough guess would five times faster builds of stuff like GLib or GTK. --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
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 the IDE), with no libtool or Unix-like functionality (shell scripts, Perl scripts) in sight at all. Not that I know if any MSVC users who use for instance GTK actually use pkg-config in their build process... it might be that pkg-config is too Unixish for them. They probably prefer to hardcode paths into makefiles. --tml ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
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 Cygwin-based tools (for instance shell scripts that run under a Cygwin shell, or Cygwin Perl scripts) and native (mingw) tools interoperate reliably one needs to make sure that the same paths are valid (and point to the same files) in both. This isn't that hard. If you have sources in for instance e:\some\place, and do your builds there, make sure that e:\some is mounted in Cygwin as /some. And if you do make installs, and/or use installed libraries and headers for some package, make sure that the same holds for the installation location, and that it is on the same drive. (For instance if you install to, or use stuff installed in, e:\another\place, mount e:\another as /another.) --tml ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How to disable relink on install?
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 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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 to use some workaround, which then failed in a mysterious way. Manually changing the limit to 2 (for instance) helped. This was on Win2k. If I remember correctly, CVS HEAD libtool earlier used to arrive at a pretty high limit, over 2, but then at some point started to use the lower limit. --tml ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Converting a project to libtool
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 future (or even a new basename), and put in a postinstall hook in the Makefile (.am) to add a symbolic link. --tml ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Re: libbfd, libtool Win32 and Re: Building a MinGW GLibetc...
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 paths, or full paths to shared libraries, stored in executables (and shared libraries) on some platforms. And, as Win32 exes and dlls only have DLL basenames in them, thus irrelevant. (Even if the relink step was done to set a hopefully unique image base, why couldn't that be done when linking the first time?) --tml ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Libtool patch for mode=install on Cygwin
This fixes a problem on Cygwin (with the Mingw gcc, even if I doubt it matters here) where invoking libtool --mode=install fails to install exes. The libtool command line refers to progname.exe, while the wrapper script that libtool produced is named without the .exe. (Line number are a bit off, as my ltmain.in also contains some other changes.) Index: ltmain.in === RCS file: /cvs/libtool/ltmain.in,v retrieving revision 1.275 diff -u -2 -r1.275 ltmain.in --- ltmain.in 2001/09/10 23:33:26 1.275 +++ ltmain.in 2001/09/16 22:51:55 @@ -4771,5 +4772,13 @@ # Do a test to see if this is really a libtool program. - if (sed -e '4q' $file | egrep ^# Generated by .*$PACKAGE) /dev/null 21; then + case $host in + *cygwin*|*mingw*) + wrapper=`echo $file | sed -e 's,.exe$,,'` + ;; + *) + wrapper=$file + ;; + esac + if (sed -e '4q' $wrapper | egrep ^# Generated by .*$PACKAGE) /dev/null +21; then notinst_deplibs= relink_command= @@ -4777,11 +4786,11 @@ # If there is no directory component, then add one. case $file in - */* | *\\*) . $file ;; - *) . ./$file ;; + */* | *\\*) . $wrapper ;; + *) . ./$wrapper ;; esac # Check the variables that should have been set. if test -z $notinst_deplibs; then - $echo $modename: invalid libtool wrapper script \`$file' 12 + $echo $modename: invalid libtool wrapper script \`$wrapper' 12 exit 1 fi @@ -4808,6 +4817,6 @@ # If there is no directory component, then add one. case $file in - */* | *\\*) . $file ;; - *) . ./$file ;; + */* | *\\*) . $wrapper ;; + *) . ./$wrapper ;; esac Cheers, Tor Lillqvist ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Problem with finding included ltdll.c and impgen.c on Cygwin
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 those marker lines with sed, it expects the # to be at the start of the line... --tml ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Suggested pathes to CVC libtool: Mingw improvement, .rc support
Hi,
Here is a patch to libtool with:
-- Small improvement for mingw-hosted tool support (while still
running libtool on cygwin). In that case PATH_SEPARATOR is ':', but
gcc -print-search-dirs still prints its search path with ';' as
separator.
-- Add support for .rc files (Windows resource 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]
* libtool.m4: Improve handling of mingw gcc. Improve handling of
$PATH with entries containing spaces. Add support for .rc files.
* ltmain.in: Check for .rc files. Add a space to $base_compile in
the case statement, as the case labels checks for trailing
spaces, but there aren't necessarily in $base_compile (?).
Index: configure.ac
===
RCS file: /cvs/libtool/configure.ac,v
retrieving revision 1.4
diff -u -2 -r1.4 configure.ac
--- configure.ac2001/07/09 22:41:58 1.4
+++ configure.ac2001/09/15 02:17:38
@@ -49,4 +49,7 @@
AM_CONDITIONAL(HAVE_GCJ, [test x$GCJ != xno])
+LT_AC_PROG_RC
+AM_CONDITIONAL(HAVE_RC, [test x$RC != xno])
+
# Declare win32 dll support
AC_LIBTOOL_WIN32_DLL
Index: libtool.m4
===
RCS file: /cvs/libtool/libtool.m4,v
retrieving revision 1.231
diff -u -2 -r1.231 libtool.m4
--- libtool.m4 2001/09/11 00:22:48 1.231
+++ libtool.m4 2001/09/15 02:17:41
@@ -1086,5 +1086,16 @@
yes,mingw*)
library_names_spec='${libname}`echo ${release} | sed -e
's/[[.]]/-/g'`${versuffix}.dll'
-sys_lib_search_path_spec=`$CC -print-search-dirs | grep ^libraries: | sed -e
s/^libraries:// -e s/$PATH_SEPARATOR/ /g`
+sys_lib_search_path_spec=`$CC -print-search-dirs | grep ^libraries: | sed -e
+s/^libraries://`
+if echo $sys_lib_search_path_spec | [egrep ';[C-Z]:/' /dev/null]; then
+ # It is most probably a Windows format PATH printed by
+ # mingw gcc, but we are running on Cygwin. Gcc prints its search
+ # path with ; separators, and with drive letters. We can handle the
+ # drive letters (cygwin fileutils understands them), so leave them,
+ # especially as we might pass files found there to a mingw objdump,
+ # which wouldn't understand a cygwinified path. Ahh.
+ sys_lib_search_path_spec=`echo $sys_lib_search_path_spec | sed -e 's/;/ /g'`
+else
+ sys_lib_search_path_spec=`echo $sys_lib_search_path_spec | sed -e
+s/$PATH_SEPARATOR/ /g`
+fi
;;
yes,pw32*)
@@ -1408,5 +1419,5 @@
[include additional configurations @:@CXX,GCJ@:@])],
[tagnames=$withval],
-[tagnames=CXX,GCJ])
+[tagnames=CXX,GCJ,RC])
if test -f $ltmain test -n $tagnames; then
@@ -1456,4 +1467,8 @@
;;
+ RC)
+AC_LIBTOOL_LANG_RC_CONFIG
+;;
+
*)
AC_MSG_ERROR([Unsupported tag name: $tagname])
@@ -2018,14 +2033,14 @@
IFS=$lt_save_ifs
test -z $ac_dir ac_dir=.
-tmp_nm=$ac_dir/${ac_tool_prefix}nm
-if test -f $tmp_nm || test -f $tmp_nm$ac_exeext ; then
+tmp_nm=$ac_dir/${ac_tool_prefix}nm
+if test -f $tmp_nm || test -f $tmp_nm$ac_exeext ; then
# Check to see if the nm accepts a BSD-compat flag.
# Adding the `sed 1q' prevents false positives on HP-UX, which says:
# nm: unknown option B ignored
# Tru64's nm complains that /dev/null is an invalid object file
- if ($tmp_nm -B /dev/null 21 | sed '1q'; exit 0) | egrep '(/dev/null|Invalid
file or object type)' /dev/null; then
+ if ($tmp_nm -B /dev/null 21 | sed '1q'; exit 0) | egrep '(/dev/null|Invalid
+file or object type)' /dev/null; then
lt_cv_path_NM=$tmp_nm -B
break
- elif ($tmp_nm -p /dev/null 21 | sed '1q'; exit 0) | egrep /dev/null
/dev/null; then
+ elif ($tmp_nm -p /dev/null 21 | sed '1q'; exit 0) | egrep /dev/null
+/dev/null; then
lt_cv_path_NM=$tmp_nm -p
break
@@ -2165,4 +2180,19 @@
+# AC_LIBTOOL_RC
+# --
+# enable support for Windows resource files
+AC_DEFUN([AC_LIBTOOL_RC],
+[AC_REQUIRE([_LT_AC_LANG_RC])
+])# AC_LIBTOOL_RC
+
+
+# _LT_AC_LANG_RC
+# ---
+AC_DEFUN([_LT_AC_LANG_RC],
+[AC_REQUIRE([AC_PROG_RC])
+])# _LT_AC_LANG_GCJ
+
+
# AC_LIBTOOL_LANG_C_CONFIG
#
@@ -3158,4 +3188,48 @@
+# AC_LIBTOOL_LANG_RC_CONFIG
+# --
+# Ensure that the configuration vars for the Windows resource compiler are
+# suitably defined. Those variables are subsequently used by
+# AC_LIBTOOL_CONFIG to write the compiler configuration to `libtool'.
+AC_DEFUN([AC_LIBTOOL_LANG_RC_CONFIG], [_LT_AC_LANG_RC_CONFIG(RC)])
+AC_DEFUN([_LT_AC_LANG_RC_CONFIG],
+[AC_LANG_SAVE
+
+# Source file extension for RC test sources
Re: new libtool.m4 patch for cygwin mingw
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*)
+ library_names_spec='${libname}`echo ${release} | [sed -e
's/[.]/-/g']`${versuffix}.dll'
+sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | sed -e
"s/^libraries://" -e "s/;/ /g"`
+ ;;
+ yes,pw32*)
+ library_names_spec='`echo ${libname} | sed -e 's/^lib/pw/'``echo ${release} |
sed -e 's/[.]/-/g'`${versuffix}.dll'
+;;
Some of what looks like spaces at the start of those added lines are
actually Latin-1 NBSP characters (\240)... Ouch! I spent half an hour
wondering why bash had suddenly started acting like crazy, the case
statement didn't match the yes,mingw*) case even though I had GCC=yes
and host_os=mingw32... I wonder where those \240 chars came from?
--tml
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
new libtool.m4 patch for cygwin 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
diff -u -2 -r1.142 libtool.m4
--- libtool.m4 2001/01/27 19:19:05 1.142
+++ libtool.m4 2001/02/21 16:29:46
@@ -1272,15 +1272,21 @@
[sed -e "1,/EXPORTS/d" -e "s/ @ [0-9]*//" -e "s/ *;.*$//"]
$output_objdir/$soname-def $export_symbols'
+# If the export-symbols file already is a .def file (1st line
+# is EXPORTS), use it as is.
# If DATA tags from a recent dlltool are present, honour them!
-archive_expsym_cmds='echo EXPORTS $output_objdir/$soname-def~
- _lt_hint=1;
- cat $export_symbols | while read symbol; do
- set dummy \$symbol;
- case \[$]# in
- 2) echo " \[$]2 @ \$_lt_hint ; " $output_objdir/$soname-def;;
- *) echo " \[$]2 @ \$_lt_hint \[$]3 ; " $output_objdir/$soname-def;;
- esac;
- _lt_hint=`expr 1 + \$_lt_hint`;
- done~
+archive_expsym_cmds='if test "x`head -1 $export_symbols`" = xEXPORTS; then
+cp $export_symbols $output_objdir/$soname-def;
+ else
+echo EXPORTS $output_objdir/$soname-def;
+_lt_hint=1;
+ cat $export_symbols | while read symbol; do
+ set dummy \$symbol;
+ case \[$]# in
+ 2) echo " \[$]2 @ \$_lt_hint ; " $output_objdir/$soname-def;;
+ *) echo " \[$]2 @ \$_lt_hint \[$]3 ; " $output_objdir/$soname-def;;
+ esac;
+ _lt_hint=`expr 1 + \$_lt_hint`;
+ done;
+ fi~
'"$ltdll_cmds"'
$CC -Wl,--base-file,$output_objdir/$soname-base '$lt_cv_cc_dll_switch'
-Wl,-e,'$dll_entry' -o $lib '$ltdll_obj'$libobjs $deplibs $compiler_flags~
@@ -1803,5 +1809,13 @@
need_lib_prefix=no
if test "$GCC" = yes; then
-library_names_spec='${libname}`echo ${release} | [sed -e
's/[.]/-/g']`${versuffix}.dll'
+case "$host_os" in
+ cygwin*)
+library_names_spec='`echo ${libname} | [sed -e 's/^lib/cyg/']``echo
+${release} | [sed -e 's/[.]/-/g']`${versuffix}.dll'
+ ;;
+ mingw*)
+library_names_spec='${libname}`echo ${release} | [sed -e
+'s/[.]/-/g']`${versuffix}.dll'
+ sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | sed -e
+"s/^libraries://" -e "s/;/ /g"`
+ ;;
+esac
else
library_names_spec='${libname}`echo ${release} | [sed -e
's/[.]/-/g']`${versuffix}.dll $libname.lib'
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: revised patch for glib compilation on cygwin with POSIX runtime
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). It might not be quite straightforward, as the places and names to look for depends much on your version of binutils etc. I think ld looks for various perumutations of libxxx.a, libxxx.dll.a, libxxx.lib, xxx.lib, xxx.dll depending on version in some order. But anyway, I will have a look at it. 3) libtool should be able to use a pre-existing .def file (hand-written or otherwise generated), in case one doesn't want to export everything. OTOH, if some library can export everything on Unix, doing it on Win32 probably won't cause any harm, either. Seems fair enough to me. Actually it already handles this, I just didn't notice at first. The -export-symbols flag accepts a file listing symbols to be exported, which can be produced from typical simple .def files by simply dropping the first (EXPORTS) line. OTOH, libtool then proceeds to prepend an EXPORTS line, followed by the contents of the symbols file, so it might be better to change libtool to check if the supplied -export-symbols file already is a .def file and in that case use it as is? Then it would also be possible to use the more esoteric .def file stuff, if necessary (I don't even know what all there can be in .def files, but presumably in some cases it might even be useful to use some of the more esoteric features.) 4) libtool should be taught to generate MS import libs, too, if lib.exe (or actually link.exe) is available. Not so sure about this one. But if you can come up with a clean patch that doesn't perturb any of the other ports, I'd certainly be happy to evaluate it. This wouldn't be hard at all, basically libtool needs to invoke: lib.exe -name:xxx.dll -def:xxx.def -out:xxx.lib ignoring failure if lib.exe isn't found. Great! There are some submission guidelines on the libtool homepage, and we might need a copyright assignment if your changes are moderately large. The like to "copyright assignment form" seems to be broken. I can't find it on the www.gnu.org site now, either. --tml ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
