Re: dll names on windows
Bob Rossi wrote: I've recently converted pcre's (http://www.pcre.org/) build system to use the autotools. The previous stable version of libtool, pcre-7.0, used to create dll's on mingw. It would create $ ls .libs/*.dll .libs/pcre.dll .libs/pcreposix.dll Now, the new autotools version creates, $ ls ../../pcre-7.1-RC4/prefix-shared/bin libpcre-0.dll libpcrecpp-0.dll libpcreposix-0.dll pcre-config ... A user has complained that the new filename change, on windows, will effect the way they have to load pcre as a plugin. They said that on windows it's common to always name the dll simply pcre.dll and then provide a coff file, which is metadata describing the version number and characteristics of the dll. My question is, what's the correct way to name these dll's on windows? What would be an appropriate response to this user? AFAIK, the coff file is purely informational, and not involved in any way with the actual linking/loading - unlike the filename, which is clearly important here. The reason for placing the number into the name is to make it possible for multiple incompatible versions of a DLL to be present on a system without colliding - the aptly named DLL Hell. I'd tend to assume that the only way that this will affect your user is that they will have to specify the new name - which ought to be pretty trivial. Perhaps you'd like to nudge them for clarification on why they think this is a difficulty? Numbering of DLLs in this way is perhaps a bit rare on Windows in general, but hardly unknown. A prime example is: msxml.dll msxml2.dll msxml3.dll msxml4.dll Finally, here is the version numbering in configure.ac, m4_define(libpcre_version, [0:1:0]) m4_define(libpcreposix_version, [0:0:0]) m4_define(libpcrecpp_version, [0:0:0]) not sure if that's good or not. Those numbers mean: libpcreposix and libpcrecpp: this is the first release since versioning began. libpcre: this is the second release since versioning began, but the ABI is unchanged since the first release. Max. signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Bug in documentation about how to update -version-info?
I sent the below to [EMAIL PROTECTED], but it's been a month with no response, so now I'm trying [EMAIL PROTECTED] instead: Max Bowsher wrote: Looking at the documentation about how to update -version-info: 1. Start with version information of `0:0:0' for each libtool library. 2. Update the version information only immediately before a public release of your software. More frequent updates are unnecessary, and only guarantee that the current interface number gets larger faster. 3. If the library source code has changed at all since the last update, then increment REVISION (`C:R:A' becomes `C:r+1:A'). 4. If any interfaces have been added, removed, or changed since the last update, increment CURRENT, and set REVISION to 0. 5. If any interfaces have been added since the last public release, then increment AGE. 6. If any interfaces have been removed since the last public release, then set AGE to 0. I think there is a potentially misleading issue with the above: If an interface is *changed* that is essentially the same as removing the old interface and adding a new one which just happens to have the same name - therefore, I think point 6 should say removed or changed, not just removed. Whilst this documentation is being looked at, a secondary point: The terms last update and last public release are used interchangeably - I think it would be clearer to use last public release exclusively (i.e. in points 3 and 4, change last update to last public release). Max. signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Bug in documentation about how to update -version-info?
Looking at the documentation about how to update -version-info: 1. Start with version information of `0:0:0' for each libtool library. 2. Update the version information only immediately before a public release of your software. More frequent updates are unnecessary, and only guarantee that the current interface number gets larger faster. 3. If the library source code has changed at all since the last update, then increment REVISION (`C:R:A' becomes `C:r+1:A'). 4. If any interfaces have been added, removed, or changed since the last update, increment CURRENT, and set REVISION to 0. 5. If any interfaces have been added since the last public release, then increment AGE. 6. If any interfaces have been removed since the last public release, then set AGE to 0. I think there is a potentially misleading issue with the above: If an interface is *changed* that is essentially the same as removing the old interface and adding a new one which just happens to have the same name - therefore, I think point 6 should say removed or changed, not just removed. Whilst this documentation is being looked at, a secondary point: The terms last update and last public release are used interchangeably - I think it would be clearer to use last public release exclusively (i.e. in points 3 and 4, change last update to last public release). Max. signature.asc Description: OpenPGP digital signature ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Speeding up libtool
Ralf Wildenhues wrote: for your projects. For best results on Cygwin, you should probably configure (with libtool HEAD) like CONFIG_SHELL=/bin/ash lt_ECHO='printf %s' /bin/ash configure [...] (replace /bin/ash with the path to Cygwin's Almquist shell clone). That path would be /bin/sh, so it's possible libtool is using it already. Max. ___ http://lists.gnu.org/mailman/listinfo/libtool
What is the estimated timeline towards 2.0?
What is the estimated timeline towards 2.0? Max. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Réf. : Re: ltmain.sh and configure
[EMAIL PROTECTED] wrote:
Hi Max,
Sorry for the mistake but in fact I invoke libtoolize -f -c' and
'automake-1.7 -a -c '!
Anyway, I get a new ltmain.sh, the one is stored in my libtool (1.4.3)
directory.
So, either ltmain.sh is bad in libtool-1.4.3 (I don't think so) or the
source
file which creates the following line (I don't which one) is bad:
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
I think the problem is here but where that libray_names_spec comes from?
The AC_PROG_LIBTOOL m4 macro.
After running aclocal, run this:
egrep 'serial.*AC_PROG_LIBTOOL' aclocal.m4
You should see 'serial 46 AC_PROG_LIBTOOL', but I suspect you will actually
see 'serial 47 AC_PROG_LIBTOOL', indicating that you have picked up the
definition of AC_PROG_LIBTOOL (from the file libtool.m4) from libtool-1.5.
ltmain.sh from 1.4.3 + libtool.m4 from 1.5 = broken
Max.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Réf. : Re: Réf. : Re: ltmain.sh and configure
[EMAIL PROTECTED] wrote: Ok, Ok Max. Now I remember also that I had to do 'aclocal-1.7 -I ./m4 ...' and according to the libiconv developper, he use slightly modified libtool1.5 files. That's the reason why I get a serial 47. So, I suppose I have to update aclocal and automake to maybe 1.8 no? Why do you suppose that? Max. After running aclocal, run this: egrep 'serial.*AC_PROG_LIBTOOL' aclocal.m4 You should see 'serial 46 AC_PROG_LIBTOOL', but I suspect you will actually see 'serial 47 AC_PROG_LIBTOOL', indicating that you have picked up the definition of AC_PROG_LIBTOOL (from the file libtool.m4) from libtool-1.5. ltmain.sh from 1.4.3 + libtool.m4 from 1.5 = broken ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: linking dynamic lib with static one.
J. Ali Harlow wrote: On 2003.09.04 09:45 Alexander Kogan wrote: Hi! I build DLL with mingw/automake/autoconf/libtool. But this dll depends on external static lib, and libtool doesn't produce dll, but say that it will be built when I compile program with this library. But I use this dll in native windows app, coimpiled with VC without libtool... What should I do to link static lib into dll? I have the same problem (with Gtk+ and libuuid.a). I'm afraid I resorted to cheating, by disabling the libtool checks as follows: mv libtool libtool.orig sed -e 's/^\(deplibs_check_method\)=.*$/\1=\ file_magic ^x86 archive|^x86 DLL \ # [ALI] Treat static libs as shared/' libtool.orig libtool chmod 755 libtool An alternate way to cheat is: lt_cv_deplibs_check_method='file_magic ^x86 archive|^x86 DLL' \ lt_cv_file_magic_cmd=win32_libid ./configure This works in my case because it doesn't matter if libuuid is included twice in the final application (once in the Gtk+ dll and once in the main application). This may not be true of all libraries and could cause some seriously odd behaviour under the right conditions but may be a solution if you can assertain that the static library won't mind having more than one instance. Yes, this is awkward - so much so, that I patch the file_magic regexp as a matter of routine. Possibility: Libtool could contain a list of libraries known to be suitable for this form of linking. Opinions? Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How to disable relink on install?
Gerrit P. Haase wrote: Hallo Alex, I'm using libtool 1.4.2 on a redhat 8.0 machine and when do a make install in my project libtool relinks all my libs and binaries. How can I disable this? I never run my binaries from the build area, only from the installed prefix. Linking a large C++ binary takes a long time, so I'd like to avoid doing it twice I use libtool on Cygwin. Usually no relinking is needed on Cygwin/Windows. So I open and edit every .la file in question and remove the relink command at the bottom before I run `make install`. AFAIK, relinking is only done (on any system) to fix up library run paths? If so, relinking is definitely never required on Windows, because *no* path information is recorded in executables. Is there any any combination of libtool configuration variables that will tell it never relink? Last time I looked, I couldn't find such a setting, so I resorted to disabling that section of code in ltmain.sh with a case statement. I've been meaning to have a closer look and maybe send in a patch, but I haven't got around to it yet. Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and cl
Bob Friesenhahn wrote: On Fri, 28 Mar 2003, Robert Boehne wrote: Braden, For libltdl to work, you'd have to have Windows declspec(__dllimport) and declspec(__dllexport) applied properly, which isn't currently done. As far as libname.lib It used to be supported by libltdl, but when GCC implemented the auto-import capability, Gary removed the support. I think it was a bad idea to remove the support. There are plenty of reasons to use the Microsoft compiler rather than GCC under Windows since GCC has limited functionality under Windows. Limited how? Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[Bug] CC=gcc -someoption loses the -someoption in untagged configuration (Works for tagged configuration)
Hi - Subject says it all, really. The -someoption isn't present in the untagged CC= in the generated libtool. (In is in LTCC=, incidentally.) All works ok with a tagged (e.g. CXX) configuration. I've been working around this with this adhoc patch - mostly created by educated guessing than a true understanding of the libtool code. Max. --- /usr/autotool/devel/share/aclocal/libtool.m4.orig 2002-12-04 22:12:47.0 + +++ /usr/autotool/devel/share/aclocal/libtool.m4 2002-12-04 22:15:10.0 + @@ -2295,6 +2295,9 @@ _LT_AC_SYS_COMPILER +# Allow CC to be a program name with arguments. +_LT_AC_TAGVAR(compiler, $1)=$CC + # # Check for any special shared library compilation flags. # ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Earnie Boyd wrote: Bob Friesenhahn wrote: On Mon, 14 Oct 2002, Max Bowsher wrote: I floated an idea on how to get around that: Adjust the libtool invocation command (as determined in libtool.m4) to be libtool --bindir=$(bindir) (or perhaps with appropriate quoting). The idea being that when used from an autoconf-based makefile (is it even possible to do otherwise, now there is no ltconfig?), the make variable bindir is passed on to libtool. Kludgy, yes, but better than ../bin. Of course, libtool would need to detect an invalid bindir and fall back on ../bin. I haven't fully worked this through yet, though, as I've just started university, so am a bit busy, and to top it off, my hard drive is making loud clicking noises and bluescreening my laptop from time to time. Be very careful about your assumptions! Libtool is certainly usable all by itself and may be used to install packages into a different directory from the one it is installed in. Libtool only needs autoconf in order to be installed, and is delivered from the FSF as a configurable stand-alone package. In a perfect world, every system would come with a perfectly working libtool, and packages wouldn't need to worry about including it, or configuring it. So what! The FSF standard is to use $(bindir) for binary installation. It even states this in the make documentation. So we use bindir, and arrange to fall back to ../bin The idea of supporting a --bindir option is tempting, but then 'libtool --mode=install' stops looking like a simple install program, and in fact, the --bindir option would need to be passed for several different phases of libtool operation since it would influence the content of the library.la file. Since Windows may be the only OS benefiting from this, we could have a case of the tail wagging the dog. So we conditionalize all this so it only activates on Windows. Would bindir be an environment variable if libtool is being executed from make? Unfortunately not. If not, setting a variable in the libtool.m4 that configure sets works. Unfortunately not - make install bindir=/alternatelocation. I prefer that over a switch, with a default value for the variable of ../bin. I think that a switch is the only way, if we are to deal with the case I cite above. Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Guido Draheim wrote:
Would bindir be an environment variable if libtool is being executed
from make? If not, setting a variable in the libtool.m4 that
configure sets works. I prefer that over a switch, with a default
value for the variable of ../bin. If bindir is passed to libtool
through the environment then use ../bin if bindir isn't present.
yes.
Just reiterating the link to the macro that I add regularly to
configure.ac
http://ac-archive.sourceforge.net/guidod/ac_set_default_paths_system.html
The main trick is to modify only the default-path (!!) of the
libdirpath and therefore let the user be free to override it on the
commandline. When a user has overridden the bindirpath then ../bin
might simply be the wrong choice as it would not end up near the
binary nor in the $PATH.
libdir=`echo $libdir |sed -e 's:^..exec_prefix./lib$:${bindir}:'`
perhaps add a similar thing to the libtool m4 macro, no?
I don't think this is the same issue at all. The problem is that libtool
needs to install _2_ files, and is (at the moment) only given the
destination of one of them.
Max.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Bob Friesenhahn wrote: On Tue, 15 Oct 2002, Max Bowsher wrote: So we conditionalize all this so it only activates on Windows. There is a fundamental flaw with this logic. Sorry to dissapoint you, but most open source software using libtool does not originate from the Windows environment. :-) Of course not. If you rely on a feature which only takes effect under Windows, then packages will neglect to enable or test that feature, resulting in packages which do not build properly (or misbehave) under Windows. Sorry, how is this different from the current situation? This is just another Win32 oddness that needs to be worked around. You can make the assumption that all libtool users will use it from packages using Autoconf and Automake so you can rely on a libtool command line passed via those tools, but this is not necessarily the case. I am aware of a number of significant packages which use libtool but don't use Automake at all. I could be wrong, but I think my solution would work just fine with autoconf+libtool (without automake). Does anyone use libtool without autoconf? Even if they do, then libtool can just fall back to ../bin (or even put the DLLs alongside the implibs). Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Earnie Boyd wrote: The Makefile sets LIBTOOL := bindir=$(bindir) $(SHELL) $(top_builddir)/libtool Then: Test for the existance of bindir in the libtool script, if it doesn't exist set it to ../bin if it does exist the Makefile has passed it to libtool via an environment variable. This works for `make install bindir=/alternatelocation. Good point. Less impact on ltmain.sh options parsing code as well. Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Bob Friesenhahn wrote: On Tue, 15 Oct 2002, Max Bowsher wrote: Earnie Boyd wrote: The Makefile sets LIBTOOL := bindir=$(bindir) $(SHELL) $(top_builddir)/libtool Then: Test for the existance of bindir in the libtool script, if it doesn't exist set it to ../bin if it does exist the Makefile has passed it to libtool via an environment variable. This works for `make install bindir=/alternatelocation. Good point. Less impact on ltmain.sh options parsing code as well. Would this part from Automake-generated Makefiles have any impact on the proposal? # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. .NOEXPORT: It won't hinder it, if that it the question. Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Proposed libtool patch for MinGW
Bob Friesenhahn wrote: The attached patch to FSF CVS libtool is intended to make libtool (mostly) behave as it does for Cygwin when executed with MinGW. It consists of contributions from Elizabeth Barham, and my own efforts. The DLLs are installed to $(libdir)/../bin as they currently are under Cygwin. Any change to this scheme should be common to both Cygwin MinGW unless there is a reason for behaving differently. This patch allows a shared library build of ImageMagick (using both C C++) to successfully build and install under MinGW using the MSYS shell environment. I have not tried to build libtool modules with it yet (should be interesting). I am posting this patch with the expectation that concerned parties will inspect it, test it, and send any fixes so that it can be incorporated in libtool 1.5. Please note that Cygwin's patched libtool contains a modification to postinstall_cmds, which I suspect is related to ../bin, as it involves calling basename. Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Bob Friesenhahn wrote: On Tue, 15 Oct 2002, Bob Friesenhahn wrote: Would this part from Automake-generated Makefiles have any impact on the proposal? # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. .NOEXPORT: Here is some text from the GNU make manual. Except by explicit request, make exports a variable only if it is either defined in the environment initially or set on the command line, and if its name consists only of letters, numbers, and underscores. Some shells cannot cope with environment variable names consisting of characters other than letters, numbers, and underscores. The special variables SHELL and MAKEFLAGS are always exported (unless you unexport them). MAKEFILES is exported if you set it to anything. make automatically passes down variable values that were defined on the command line, by putting them in the MAKEFLAGS variable. I don't see evidence that srcdir will normally be available in libtool's environment. I assume you mean bindir, not srcdir? In which case, my answer is: Yes, thats why special attention of required to _make_ it available. Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: Proposed libtool patch for MinGW
Bob Friesenhahn wrote: The MinGW patch uses libbase-number.dll for DLL naming, I thought the consensus was base-number.dll (no lib)? Or am I remembering wrongly? Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Bob Friesenhahn wrote: On Mon, 14 Oct 2002, Earnie Boyd wrote: Well, shouldn't both use $(bindir) to install the dll into? What would be nice except that I don't believe libtool is provided with this information at run-time. It acts like a traditional install program. The Cygwin folks are using the ../bin trick to get around that. I floated an idea on how to get around that: Adjust the libtool invocation command (as determined in libtool.m4) to be libtool --bindir=$(bindir) (or perhaps with appropriate quoting). The idea being that when used from an autoconf-based makefile (is it even possible to do otherwise, now there is no ltconfig?), the make variable bindir is passed on to libtool. Kludgy, yes, but better than ../bin. Of course, libtool would need to detect an invalid bindir and fall back on ../bin. I haven't fully worked this through yet, though, as I've just started university, so am a bit busy, and to top it off, my hard drive is making loud clicking noises and bluescreening my laptop from time to time. Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Elizabeth Barham wrote:
This patch allowed libMagick++ to compile on my machine.
The one thing that concerns me is the name of the import library is
hard-coded ${lib}.a, which is okay in that the import library looks
like qqq.dll.a but Max has something going about putting DLLs with
the executables and the libraries in the library directory during
install. Is this going to help or hinder Max's work?
Don't worry about me! I think we are working towards broadly similar goals -
it shouldn't be much effort for me to merge the changes you are making into
my stuff.
I've just started University this week, so free time is not abundant, but
when I get some more, I will try and complete some of this half done stuff
I've got on my hard drive.
Max.
+ mingw*)
+# On msys 1.0 and win98, the maximum length was something like
+# 200,000 and took around 45 minutes to get there... ouch!
+lt_cv_sys_max_cmd_len=32768;
+;;
One of my patches merges a change from Cygwin for this. Caution though. I
read there that the max length for NT systems is only 8192 - so this patch
needs adjusting to not break libtool on NT.
- mingw* | pw32*)
-# FIXME: insert proper C++ library support
-_LT_AC_TAGVAR(ld_shlibs, $1)=no
- ;;
I never got near this - I stayed within the bounds of plain C.
Max.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
libtool/MinGW DLLs patch - tidied up section 2
I am tidying and explaining my patch bit by bit. Here is the second chunk.
A libtool expert needs to check Hunk 2. See my comments below
Once section 1 and 2 have been pronounced OK, they can be commited, as they are
just groundwork for the main chunk of the patch, and can stand alone.
Max.
-- from here is the text of the attatchment, for ease of viewing /
discussion --
Explanation: These are the remaining changes which do not require policy
discussion on the MinGW mailing list. That's not to say they don't
need code discussion.
Hunk 1: Move a line from a Cygwin-only section to its parent all-Win32 section.
This is accurate because there is no runpath on Win32. Unless there is a
'there_is_no_runpath' flag for libtool that I have missed? :-)
Hunk 2: Without this, if CC is a program name with arguments, those arguments
were being lost in the plain C case only. I noted that a line of this
form was missing in the plain C case as compared to other language tags.
However, I just guessed that it might be the problem, and it worked! So,
could someone more experienced with libtool internals check this?
--- libtool.m4.cvs+01 2002-09-18 08:45:58.0 +0100
+++ libtool.m4.cvs+01+02 2002-09-18 08:52:39.0 +0100
-1124,6 +1124,7
version_type=windows
need_version=no
need_lib_prefix=no
+ shlibpath_overrides_runpath=yes
case $GCC,$host_os in
yes,cygwin*)
library_names_spec='$libname.dll.a'
-1137,7 +1138,6
postuninstall_cmds='dldll=`bash 21 -c '\''. $file; echo \$dlname'\''`~
dlpath=$dir/\$dldll~
$rm \$dlpath'
-shlibpath_overrides_runpath=yes
;;
yes,mingw*)
library_names_spec='${libname}`echo ${release} | sed -e
's/[[.]]/-/g'`${versuffix}.dll'
-2298,6 +2298,8
_LT_AC_SYS_COMPILER
+_LT_AC_TAGVAR(compiler, $1)=$CC
+
#
# Check for any special shared library compilation flags.
#
END_OF_PATCH
Explanation: These are the remaining changes which do not require policy
discussion on the MinGW mailing list. That's not to say they don't
need code discussion.
Hunk 1: Move a line from a Cygwin-only section to its parent all-Win32 section.
This is accurate because there is no runpath on Win32. Unless there is a
'there_is_no_runpath' flag for libtool that I have missed? :-)
Hunk 2: Without this, if CC is a program name with arguments, those arguments
were being lost in the plain C case only. I noted that a line of this
form was missing in the plain C case as compared to other language tags.
However, I just guessed that it might be the problem, and it worked! So,
could someone more experienced with libtool internals check this?
--- libtool.m4.cvs+01 2002-09-18 08:45:58.0 +0100
+++ libtool.m4.cvs+01+022002-09-18 08:52:39.0 +0100
-1124,6 +1124,7
version_type=windows
need_version=no
need_lib_prefix=no
+ shlibpath_overrides_runpath=yes
case $GCC,$host_os in
yes,cygwin*)
library_names_spec='$libname.dll.a'
-1137,7 +1138,6
postuninstall_cmds='dldll=`bash 21 -c '\''. $file; echo \$dlname'\''`~
dlpath=$dir/\$dldll~
$rm \$dlpath'
-shlibpath_overrides_runpath=yes
;;
yes,mingw*)
library_names_spec='${libname}`echo ${release} | sed -e
's/[[.]]/-/g'`${versuffix}.dll'
-2298,6 +2298,8
_LT_AC_SYS_COMPILER
+_LT_AC_TAGVAR(compiler, $1)=$CC
+
#
# Check for any special shared library compilation flags.
#
END_OF_PATCH
Re: [Mingw-users] Re: Re: libbfd, libtool Win32 and Re: Building a MinGW GLibetc...
Guido Draheim wrote: (A) the sys_lib_search_path spec gets hardcoded to the cygwin path. no go on mingw cross. $CC -print-search-dirs rules. I wish I knew why this hack is required on Cygwin (B) final $dlname to ../bin/$dlname - interesting way to do about this but probably interfering with autoconfed installpath specs (I for one use an ac-macro to make the default of $libdir the same as $bindir which has the effect of what's needed - to bring the dlls into $PATH). I agree that this is inelegant. Ideally, we would calculate the relative path to bindir from libdir, but I don't know how to do that. Anyone? (C) what's that install-number-increment-sedscript about? The give-dlls-execute-permissions-sedscript? Because on Cygwin with ntsec, the dll is installed without execute permission, so cannot be used. (D) is that a shellscript to make a .def file and compile it? cute... but let's see if it works cross. No idea - I just copied and pasted from the existing code in libtool.m4. Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Re: libbfd, libtool Win32 and Re: Building a MinGW GLib etc...
Guido Draheim wrote:
How old may a gcc/binutils pair be? My oldest crosscompilers
are gcc 2.95.3 and ld --version reports 2.11.90.8. And for
all I know, these are in fact the oldest versions around,
no one want to go back beyond, I guess.
Is that enough, Max?
Test:
$ echo '__declspec(dllexport) void foo () {}' foo.c
$ gcc -shared foo.c -o foo.dll
$ objdump -p foo.dll | fgrep -A 5 Characteristics
The first chunk of the fgrepped objdump output should contain something like:
| Characteristics 0x2006
| executable
| line numbers stripped
| DLL
The gcc completing without errors is probably enough, though. The objdump is
just confirmation.
Max.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool Win32
Guido Draheim wrote: I am not that knowing about the actual backgrounds, but to me it did look as if one can not be sure about the dll.a format, so that one does not trust it. Unlike cygwin, it is much more likely that mingw binds with dlls *not* compiled by mingw gcc but from another compiler. Since mingw is on the same augenhoehe (eye height, here: being-level) other than cygwin's posixisch environment which is another layer atop the basic operating system services. And damn, we want to bind with other dlls for which we have no dll.a available. About all the other win32 compilers come with some kind of implib.exe that one can use to make an importlib from any dll that was not shipped along with that compiler. That is, in another step, before linking. That's not the gcc/unix way I say, where we are even used that LD link lines look always somewhat like -L. -lz, other than the plethora of w32 compilers, IIRC. Personally, I do not have a problem with having libtool to do some automatics, to call some implib.exe if the importlib is not availabe - or when one does not trust that the imp.lib is up to date with the lib in parallel that (the dll versioning scheme is not quite like that one unix systems, and dlls get often replaced, while unix sharedlibs are not and get a cousin in parallel). Anyway, for having libtool to do some automatics successfully... there has to be an implib.exe-like step that can be done and trusted. I think the correct approach is to use a libfoo.dll.a if it is present, and do funny impgen stuff if it is not. Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool/MinGW DLLs patch - tidied up section 1
I am tidying and explaining my patch bit by bit. Here is the first chunk,
including the merge of the Cygwin-local changes to libtool (not done by me).
Hunks 1 2 should be fine. Hunk 3 is purely the addition of a comment, which
you may prefer to leave out on the grounds of unnecessary bloat.
Either way, the functional change in that section goes hand-in-hand with a
change to archive_expsym_cmds
Max.
-- from here is the text of the attatchment, for ease of viewing /
discussion --
Explanation: This section is a merge of the current Cygwin patches to
libtool.m4,
plus a couple of changes with respect to MinGW
Hunk 1: The comment says it all
Hunk 2: Apparently a bugfix to Cygwin's postinstall_cmds. I want to borrow those
postinstall_cmds later, so we should have the latest version.
Hunk 3: Up to the '-' came from Cygwin. The next bit of the comment is mine. I'm
not even sure if $ltdll_cmds work any more. I've bee using the $NM
incantation, since I do have a sort and a uniq.
--- libtool.m4.cvs 2002-09-11 08:35:40.0 +0100
+++ libtool.m4.cvs+cyg 2002-09-17 12:52:47.0 +0100
-610,6 +610,17
lt_cv_sys_max_cmd_len=12288;# 12K is about right
;;
+ cygwin* | mingw*)
+# On Win9x/ME, this test blows up -- it succeeds, but takes
+# about 5 minutes as the teststring grows exponentially.
+# Worse, since 9x/ME are not pre-emptively multitasking,
+# you end up with a frozen computer, even though with patience
+# the test eventually succeeds (with a max line length of 256k).
+# Instead, let's just punt: use the minimum linelength reported by
+# all of the supported platforms: 8192 (on NT/2K/XP).
+lt_cv_sys_max_cmd_len=8192;
+;;
+
gnu*)
# Under GNU Hurd, this test is not required because there is
# no limit to the length of command line arguments.
-1118,10 +1129,11
library_names_spec='$libname.dll.a'
sys_lib_search_path_spec=/lib /lib/w32api /usr/lib /usr/local/lib
soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} |
sed -e 's/[[.]]/-/g'`${versuffix}.dll'
-postinstall_cmds='dlpath=`bash 21 -c '\''. $dir/${file}i;echo
\$dlname'\''`~
+postinstall_cmds='base_file=`basename \${file}`~
+ dlpath=`bash 21 -c '\''. $dir/'\''\${base_file}'\''i;echo
\$dlname'\''`~
dldir=$destdir/`dirname \$dlpath`~
test -d \$dldir || mkdir -p \$dldir~
- $install_prog .libs/$dlname \$dldir/$dlname'
+ $install_prog $dir/$dlname \$dldir/$dlname'
postuninstall_cmds='dldll=`bash 21 -c '\''. $file; echo \$dlname'\''`~
dlpath=$dir/\$dldll~
$rm \$dlpath'
-4514,7 +4526,7
_LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM -BCpg $libobjs $convenience |
awk '\''{ if (((\[$]2 == T) || (\[$]2 == D) || (\[$]2 == B))
([substr](\[$]3,1,1) != .)) { print \[$]3 } }'\'' | sort -u $export_symbols'
fi
;;
- mingw* | pw32*)
+ mingw* | pw32*) # and not cygwin. Cygwin uses the $NM incantation, below -
and so, probably, should mingw if sort and uniq can be guaranteed. The $NM is
_much_ quicker than $ltdll_cmds
_LT_AC_TAGVAR(export_symbols_cmds, $1)=$ltdll_cmds
;;
*)
END_OF_PATCH
Explanation: This section is a merge of the current Cygwin patches to libtool.m4,
plus a couple of changes with respect to MinGW
Hunk 1: The comment says it all
Hunk 2: Apparently a bugfix to Cygwin's postinstall_cmds. I want to borrow those
postinstall_cmds later, so we should have the latest version.
Hunk 3: Up to the '-' came from Cygwin. The next bit of the comment is mine. I'm
not even sure if $ltdll_cmds work any more. I've bee using the $NM
incantation, since I do have a sort and a uniq.
--- libtool.m4.cvs 2002-09-11 08:35:40.0 +0100
+++ libtool.m4.cvs+cyg 2002-09-17 12:52:47.0 +0100
-610,6 +610,17
lt_cv_sys_max_cmd_len=12288;# 12K is about right
;;
+ cygwin* | mingw*)
+# On Win9x/ME, this test blows up -- it succeeds, but takes
+# about 5 minutes as the teststring grows exponentially.
+# Worse, since 9x/ME are not pre-emptively multitasking,
+# you end up with a frozen computer, even though with patience
+# the test eventually succeeds (with a max line length of 256k).
+# Instead, let's just punt: use the minimum linelength reported by
+# all of the supported platforms: 8192 (on NT/2K/XP).
+lt_cv_sys_max_cmd_len=8192;
+;;
+
gnu*)
# Under GNU Hurd, this test is not required because there is
# no limit to the length of command line arguments.
-1118,10 +1129,11
library_names_spec='$libname.dll.a'
sys_lib_search_path_spec=/lib /lib/w32api /usr/lib /usr/local/lib
soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} | sed -e
's/[[.]]/-/g'`${versuffix}.dll'
-postinstall_cmds='dlpath=`bash 21 -c '\''. $dir/${file}i;echo \$dlname'\''`~
+postinstall_cmds='base_file=`basename \${file}`~
+ dlpath=`bash 21 -c '\''.
