Re: dll names on windows

2007-04-14 Thread Max Bowsher
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?

2006-07-17 Thread Max Bowsher
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?

2006-06-14 Thread Max Bowsher
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

2005-03-15 Thread Max Bowsher
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?

2004-09-05 Thread Max Bowsher
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

2003-09-09 Thread Max Bowsher
[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

2003-09-09 Thread Max Bowsher
[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.

2003-09-05 Thread Max Bowsher
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?

2003-06-29 Thread Max Bowsher
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

2003-03-29 Thread Max Bowsher
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)

2002-12-04 Thread Max Bowsher
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

2002-10-15 Thread Max Bowsher

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

2002-10-15 Thread Max Bowsher

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

2002-10-15 Thread Max Bowsher

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

2002-10-15 Thread Max Bowsher

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

2002-10-15 Thread Max Bowsher

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

2002-10-15 Thread Max Bowsher

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

2002-10-15 Thread Max Bowsher

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

2002-10-15 Thread Max Bowsher

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

2002-10-14 Thread Max Bowsher

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

2002-10-11 Thread Max Bowsher
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

2002-09-18 Thread Max Bowsher

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...

2002-09-17 Thread Max Bowsher

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...

2002-09-17 Thread Max Bowsher

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

2002-09-17 Thread Max Bowsher

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

2002-09-17 Thread Max Bowsher

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 '\''.