Re: MinGW libtool DLL failure

[Soren A]

Earnie Boyd [EMAIL PROTECTED] wrote in 
news:3DAC41A9.3070503;yahoo.com:

 Bob Friesenhahn wrote:
 
 If libtool was intended to be an extension of Autoconf/Automake, then
 it should certainly have been absorbed into Automake, and not exist as
 a stand-alone utility at all.
 
 
 Do you have examples of libtool use without autoconf and/or automake? 
 Why does libtool.m4 get installed into share/aclocal/?  AFAIK, libtool 
 without autoconf/automake doesn't exist.
 
 Earnie.

Echo. I don't dispute that Bob might be correct but TTBOMK this is not
_common_ knowledge. After extensively messing around with building a
libtool from GNU cvs within the last 3 weeks, I can say that I see no
means by which libtool can readily be used anymore without Autoconf and
Automake being involved. Because they've nuked ltconfig, libtool seems
much less a stand-alone tool now. It seems as if the intention of the
PTB is that libtool shall become a de-facto extension of Automake. I'd
really like to know about examples of current libtool usage that
exercize libtool independently (in the absense of) Automake. 

It should be noted that I emphasize the amount of time I spent getting a
libtool built from cvs source because I approached the whole thing in
order to try to learn as much as I possibly could about libtool all in
one deliberate, thorough effort (something I've avoided doing for a long
time). In the course of this I found myself *VERY* annoyed by the fact
that the libtool manual at GNU.org is completely out of date WRT the
present structure of libtool. Also, the Autobook which readers should
probably be familiar with, that is hosted at RedHat.com, is also out of
date WRT the use of libtool as part of the Autotools. Both documents
talk about 'ltconfig' which no longer exists. 

So it's about as clear as mud that libtool can even be used at all
anymore without Automake being involved. It seems like the original
intention of libtool's author has been subverted in fact? 

If somebody reading this experiences a reactive impulse to the words
annoyance and documentation and the reflex action of posting a well
its Free software you aren't paying for it why don't you write better
documentation and contribute it instead of griping kind of response,
you can go take a flying leap AFAIAC. To be able to write
documentation for something you have to first UNDERSTAND the thing and
it seems impossible or nearly impossible to come to understand how
'libtool' now works (if you haven't been developing it all along)
anymore. The manual for libtool actually made good reading and seemed
splendidly clear, made me want to use the software. Then I discovered
that the manual has nothing much to do with reality anymore, it
describes software that no longer exists (that is no longer currently
being used / developed).  

Somebody who has been developing libtool all along has GOT TO take on
the job of updating the user documentation for that mess. It's gotten
far too complex for some new person to wade in and try to explain it
clearly. There's moaning needs, crying needs and then there's SCREAMING
needs. Updated documentation for libtool is of the lattermost variety. 

  All IMHO.
 Soren A

-- 
What do Internet Mailing Lists and crowded neighborhoods have in
common? Both will either drive you out or teach you how to ignore
barking dogs.




___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Russ Allbery]

Soren A [EMAIL PROTECTED] writes:

 Echo. I don't dispute that Bob might be correct but TTBOMK this is not
 _common_ knowledge. After extensively messing around with building a
 libtool from GNU cvs within the last 3 weeks, I can say that I see no
 means by which libtool can readily be used anymore without Autoconf and
 Automake being involved.

I can't comment on using it without Autoconf, but INN uses libtool and
doesn't use Automake.  That's not particularly difficult to do, at least
for the simple cases.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Bob Friesenhahn]

On Mon, 21 Oct 2002, Soren A wrote:
 
  Do you have examples of libtool use without autoconf and/or automake?
  Why does libtool.m4 get installed into share/aclocal/?  AFAIK, libtool
  without autoconf/automake doesn't exist.

 Echo. I don't dispute that Bob might be correct but TTBOMK this is not
 _common_ knowledge. After extensively messing around with building a
 libtool from GNU cvs within the last 3 weeks, I can say that I see no
 means by which libtool can readily be used anymore without Autoconf and
 Automake being involved. Because they've nuked ltconfig, libtool seems

This means that you are missing a major point about libtool, and one
that was considered to be vital by the original libtool author (Gordon
Matzigkeit).  The user can download the libtool package, do a
'configure', 'make', and 'make install', and then use libtool just as
described in the libtool user manual.  Sure, the libtool package
itself uses Autoconf/Automake, but once it is installed, libtool is
just a utility like any other utility.

 PTB is that libtool shall become a de-facto extension of Automake. I'd
 really like to know about examples of current libtool usage that
 exercize libtool independently (in the absense of) Automake.

The FreeType library and libjpeg both use libtool without Automake.
The FreeType folks even go to the extent of using something besides
`make' (JAM).

 its Free software you aren't paying for it why don't you write better
 documentation and contribute it instead of griping kind of response,
 you can go take a flying leap AFAIAC. To be able to write
 documentation for something you have to first UNDERSTAND the thing and
 it seems impossible or nearly impossible to come to understand how
 'libtool' now works (if you haven't been developing it all along)
 anymore. The manual for libtool actually made good reading and seemed
 splendidly clear, made me want to use the software. Then I discovered
 that the manual has nothing much to do with reality anymore, it
 describes software that no longer exists (that is no longer currently
 being used / developed).

If there is a deficiency, then please submit a patch to correct it, or
at least report the *specific* deficiency so it can be fixed.

 Somebody who has been developing libtool all along has GOT TO take on
 the job of updating the user documentation for that mess. It's gotten
 far too complex for some new person to wade in and try to explain it
 clearly. There's moaning needs, crying needs and then there's SCREAMING
 needs. Updated documentation for libtool is of the lattermost variety.

I refer to the libtool documentation often, and it has rarely led me
astray.

By the way, CVS libtool now works under MinGW, so you should be much
happier about it.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Albert Chin]

On Tue, Oct 15, 2002 at 10:43:08AM -0500, Bob Friesenhahn wrote:
 On Tue, 15 Oct 2002, Max Bowsher wrote:
 
   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.
 
 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. :-)
 
 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.

Doesn't this conflict with the libtool option -no-undefined:
 - Macro: AC_LIBTOOL_WIN32_DLL
 This macro should be used if the package has been ported to build
 clean dlls on win32 platforms.  Usually this means that any
 library data items are exported with `__declspec(dllexport)' and
 imported with `__declspec(dllimport)'.  If this macro is not used,
 libtool will assume that the package libraries are not dll clean
 and will build only static libraries on win32 hosts.

 This macro must be called *before* `AC_PROG_LIBTOOL', and
 provision must be made to pass `-no-undefined' to `libtool' in
 link mode from the package `Makefile'.  Naturally, if you pass
 `-no-undefined', you must ensure that all the library symbols
 *really are* defined at link time!

It seems that CYGWIN needs -no-undefined but this might be problematic
on other unices.

-- 
albert chin ([EMAIL PROTECTED])


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Bob Friesenhahn]

On Fri, 18 Oct 2002, Albert Chin wrote:

 On Tue, Oct 15, 2002 at 10:43:08AM -0500, Bob Friesenhahn wrote:
  On Tue, 15 Oct 2002, Max Bowsher wrote:
  
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.
 
  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. :-)
 
  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.

 Doesn't this conflict with the libtool option -no-undefined:
  - Macro: AC_LIBTOOL_WIN32_DLL
  This macro should be used if the package has been ported to build
  clean dlls on win32 platforms.  Usually this means that any

Due to `auto-import' enhancements in the version of binutils used by
Cygwin and MinGW, I believe that using this macro is no longer
necessary.  Packages which have been enhanced (or compromised,
depending on point of view) by being decorated with
dllexport/dllimport annotations may still benefit from use of the
macro.

Unix-derived packages which do not use AC_LIBTOOL_WIN32_DLL and do not
incorporate dllexport/dllimport annotations are capable of building
DLLs by incorporating recent libtool.

 It seems that CYGWIN needs -no-undefined but this might be problematic
 on other unices.

It is true that Cygwin/MinGW need -no-undefined in order to build
DLLs.  I have not encountered a problem with specifying -no-undefined
under various unixes.  Indeed, I believe that this issue isn't Windows
specific because IBM's AIX also requires -no-undefined.

In order to ensure that the maximum number of packages will compile
under Windows, the auto* tools should automatically incorporate any
tests/features required for packages to build under Windows without
their authors taking specific action to make this possible.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Earnie Boyd]

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.

 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.
 

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.

Earnie.



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[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

[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

[Bob Friesenhahn]

On Tue, 15 Oct 2002, Max Bowsher wrote:

  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.

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

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.

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.

If libtool was intended to be an extension of Autoconf/Automake, then
it should certainly have been absorbed into Automake, and not exist as
a stand-alone utility at all.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Guido Draheim]

Earnie Boyd wrote:
 Max Bowsher wrote:
 
 Earnie Boyd wrote:


 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.

 
 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.
 

Don't forget DESTDIR !




___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[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

[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

[Bob Friesenhahn]

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:

==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[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: [Mingw-msys] Re: MinGW libtool DLL failure

[Bob Friesenhahn]

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.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[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: MinGW libtool DLL failure

[Robert Boehne]

All,

The max_cmd_len variable is used to determine how long a command
can be executed.  When Libtool generates a link command that is
longer than this, it breaks the command into successive ld -r
invocations that are just short enough to be executed.  There are
other parts of the commands that aren't included when testing, so
the max_cmd_len variable can't be set to the actual limit, but
must be smaller.  Also, finding the actual limit would take much
longer so we set max_cmd_len to something safe.
  It is true that the checking takes some time, ~three seconds on
a newer Sun workstation (with large limit), but it isn't clear
to me why it would take even longer under MinGW.
  It is reasonable to set this to a hard limit if the test takes
a very long time, but the value to use is the same one that
Libtool's configury will calculate.  The problem with GTK+ is
that they archive two (or more) object files with the same name,
so successive ar commands replace the previous one with the
new one.  If a package needs the command line broken up, setting
this value to the maximum possible will speed up compilation
drastically, IMHO an important issue.

my $0.02

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Bob Friesenhahn]

On Mon, 14 Oct 2002, Robert Boehne wrote:

   It is true that the checking takes some time, ~three seconds on
 a newer Sun workstation (with large limit), but it isn't clear
 to me why it would take even longer under MinGW.

Unfortunately MinGW must run under an inferior OS, particularly
Windows '98 which has terrible performance with executing
subprocesses.

Libtool estimates a command line length of 8192 under Windows XP.  Is
there a version of Windows under which libtool estimates a smaller
lt_cv_sys_max_cmd_len?

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Earnie Boyd]

Well, shouldn't both use $(bindir) to install the dll into?

Earnie.

Bob Friesenhahn wrote:
 What directory should MinGW DLLs be installed in?  Cygwin installs
 using the offset ../bin from the directory where the .dll.a file is
 installed.  Should libtool behave the same way under MinGW?
 
 This seems to make sense as long as Unixish behavior is what is
 expected by MinGW users.  However, the intended purpose of MinGW is
 somewhat different than Cygwin.
 
 Bob
 ==
 Bob Friesenhahn
 [EMAIL PROTECTED]
 http://www.simplesystems.org/users/bfriesen
 
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 Mingw-msys mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/mingw-msys
 



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Bob Friesenhahn]

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.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[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-msys] Re: MinGW libtool DLL failure

[Bob Friesenhahn]

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.

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.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Tor Lillqvist]

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: [Mingw-msys] Re: MinGW libtool DLL failure

[Kevin Ryde]

Tor Lillqvist [EMAIL PROTECTED] writes:

 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.

In GMP we had a problem with the ar cru used for piecewise linking
since we've got multiple object files of the same name (coming from
different directories).  Using AR_FLAGS=cq got around it.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Bob Friesenhahn]

Your patch works.  Please submit a formal version of this patch (with
changelog) and I will apply it.

Bob

On 11 Oct 2002, Elizabeth Barham wrote:

 Bob, all,

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?

 Elizabeth

 Index: libtool.m4
 ===
 RCS file: /cvsroot/libtool/libtool/libtool.m4,v
 retrieving revision 1.266
 diff -u -p -3 -r1.266 libtool.m4
 --- libtool.m411 Oct 2002 15:52:08 -  1.266
 +++ libtool.m411 Oct 2002 20:46:18 -
 @@ -620,7 +620,14 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [d
  lt_cv_sys_max_cmd_len=-1;
  ;;

 -  *)
 +
 +  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;
 +;;
 +
 + *)
  # If test is not a shell built-in, we'll probably end up computing a
  # maximum length that is only half of the actual maximum length, but
  # we can't tell.
 @@ -2624,12 +2631,25 @@ case $host_os in
  else
_LT_AC_TAGVAR(ld_shlibs, $1)=no
  fi
 -  ;;
 + ;;

 -  mingw* | pw32*)
 -# FIXME: insert proper C++ library support
 -   _LT_AC_TAGVAR(ld_shlibs, $1)=no
 -  ;;
 +  mingw* )
 +_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
 +_LT_AC_TAGVAR(always_export_symbols, $1)=no
 +
 +if $LD --help 21 | egrep 'auto-import'  /dev/null; then
 +  _LT_AC_TAGVAR(archive_cmds, $1)='$CC '$lt_cv_cc_dll_switch' $libobjs $deplibs 
$compiler_flags -o $output_objdir/$soname ${wl}--out-implib,${lib}.a'
 +  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC '$lt_cv_cc_dll_switch' $libobjs 
$deplibs $compiler_flags -o $output_objdir/$soname ${wl}-retain-symbols-file 
$wl$export_symbols ${wl}--out-implib,${lib}.a'
 +else
 +  _LT_AC_TAGVAR(ld_shlibs, $1)=no
 +fi
 + ;;
 +
 +
 +  pw32* )
 + # FIXME: insert proper C++ library support
 +_LT_AC_TAGVAR(ld_shlibs, $1)=no
 + ;;

dgux*)
  case $cc_basename in


==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Elizabeth Barham]

Earnie Boyd [EMAIL PROTECTED] writes:

 I'm fine with it and will support the change [of the maximum command
 line length] to a constant.  Should that constant be adjusted based
 on w9x vs NT?

I would not think so; rather, it seems to me that a 8192 character
command line maximum will work for most anyone.

Do we have the option of switching between NT and w9x?

Elizabeth


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Earnie Boyd]

Elizabeth Barham wrote:

Earnie Boyd [EMAIL PROTECTED] writes:



I'm fine with it and will support the change [of the maximum command
line length] to a constant.  Should that constant be adjusted based
on w9x vs NT?



I would not think so; rather, it seems to me that a 8192 character
command line maximum will work for most anyone.



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.  Is there 
a mehtod to use that doesn't check the command line length or is the 
point of the limit to break the command line into parts?

Do we have the option of switching between NT and w9x?


With Cygwin and MSYS, unmae tacks it on the system name.

Earnie.



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Bob Friesenhahn]

On Sat, 12 Oct 2002, Earnie Boyd wrote:
 the characters.  The 8192 may not be enough for some packages.  Is there
 a mehtod to use that doesn't check the command line length or is the
 point of the limit to break the command line into parts?

I believe that the limit is there to break the command line into
parts.  For the sake of efficiency, choose the largest length that
works.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Elizabeth Barham]

Earnie Boyd [EMAIL PROTECTED] 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.
 Is there a mehtod to use that doesn't check the command line length
 or is the point of the limit to break the command line into parts?

I do not know why it is used. It sets the variable `max_cmd_len' is
all I can tell that it does in libtool.m4.

 with Cygwin and MSYS, unmae tacks it on the system name.

Ok.

Elizabeth


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Guido Draheim]

Elizabeth Barham wrote:
yes,mingw*)
 -library_names_spec='${libname}`echo ${release} | sed -e 
's/[[.]]/-/g'`${versuffix}.dll'
 +soname_spec='$libname.dll'
 +library_names_spec='$libname.dll.a'

don't cut away the release spec.

libtool link --release 10.56 -o libfoo.la
   creates
libfoo-10-56.dll

Currently the release marker is the only way to get
at variant libraries - kinda misuse, I know, but
better than nothing.

I don't think that library_names_spec is the correct
place to specify the importlib - but where to place
it else, hmm... the problem is more that it must
be created somehow while in the making and placed
additionally (!!) in the la spec to be installed
later.




___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Elizabeth Barham]

Bob Friesenhahn [EMAIL PROTECTED] writes:

 The exact same error message is reported without -shared.

From what I can tell, during configure, there is a check for any
object files that are included in a C++ link. This object file is then
later used to build the shared archive.

If you look at libtool.m4, wherever this is (reading it off the web):

 cygwin*)
# _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
# as there is no search path for DLLs.
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
_LT_AC_TAGVAR(always_export_symbols, $1)=no

if $LD --help 21 | egrep 'auto-import'  /dev/null; then
  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs 
$deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname 
${wl}--image-base=0x1000 ${wl}--out-implib,$lib'
  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared -nostdlib $predep_objects 
$libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname 
${wl}-retain-symbols-file $wl$export_symbols ${wl}--out-implib,$lib'
else
  _LT_AC_TAGVAR(ld_shlibs, $1)=no
fi
 ;;

  mingw* | pw32*)
# FIXME: insert proper C++ library support
  _LT_AC_TAGVAR(ld_shlibs, $1)=no
 ;;

You see that, for mingw, it needs to be fixed and I propose that
someone *TEST* taking the cygwin implementation and moving down to
where mingw is, *and* removing the $predep_objects, like this:

  mingw* )
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
_LT_AC_TAGVAR(always_export_symbols, $1)=no

if $LD --help 21 | egrep 'auto-import'  /dev/null; then
  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $libobjs $deplibs 
$postdep_objects $compiler_flags -o $output_objdir/$soname 
${wl}--image-base=0x1000 ${wl}--out-implib,$lib'
  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared -nostdlib $libobjs $deplibs 
$postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}-retain-symbols-file 
$wl$export_symbols ${wl}--out-implib,$lib'
else
  _LT_AC_TAGVAR(ld_shlibs, $1)=no
fi
;;

  pw32* )
   # FIXME: insert proper C++ library support
 _LT_AC_TAGVAR(ld_shlibs, $1)=no
 ;;

What is the conventional wisdom on this?

Elizabeth


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Elizabeth Barham]

Bob, all,

   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?

Elizabeth

Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.266
diff -u -p -3 -r1.266 libtool.m4
--- libtool.m4  11 Oct 2002 15:52:08 -  1.266
+++ libtool.m4  11 Oct 2002 20:46:18 -
@@ -620,7 +620,14 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [d
 lt_cv_sys_max_cmd_len=-1;
 ;;
 
-  *)
+  
+  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;
+;;
+
+ *)
 # If test is not a shell built-in, we'll probably end up computing a
 # maximum length that is only half of the actual maximum length, but
 # we can't tell.
@@ -2624,12 +2631,25 @@ case $host_os in
 else
   _LT_AC_TAGVAR(ld_shlibs, $1)=no
 fi
-;;
+   ;;
 
-  mingw* | pw32*)
-# FIXME: insert proper C++ library support
- _LT_AC_TAGVAR(ld_shlibs, $1)=no
-;;
+  mingw* )
+_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+_LT_AC_TAGVAR(always_export_symbols, $1)=no
+
+if $LD --help 21 | egrep 'auto-import'  /dev/null; then
+  _LT_AC_TAGVAR(archive_cmds, $1)='$CC '$lt_cv_cc_dll_switch' $libobjs $deplibs 
+$compiler_flags -o $output_objdir/$soname ${wl}--out-implib,${lib}.a'
+  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC '$lt_cv_cc_dll_switch' $libobjs 
+$deplibs $compiler_flags -o $output_objdir/$soname ${wl}-retain-symbols-file 
+$wl$export_symbols ${wl}--out-implib,${lib}.a'
+else
+  _LT_AC_TAGVAR(ld_shlibs, $1)=no
+fi
+   ;;
+
+
+  pw32* )
+ # FIXME: insert proper C++ library support
+_LT_AC_TAGVAR(ld_shlibs, $1)=no
+   ;;
 
   dgux*)
 case $cc_basename in



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Bob Friesenhahn]

On 11 Oct 2002, Elizabeth Barham wrote:

This patch allowed libMagick++ to compile on my machine.

Great.  I'll give it a try tomorrow.

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?

I assume that it won't impact his work since his activities would be
taking place during the install step, rather than the compile/link
step.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[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

Re: MinGW libtool DLL failure

[Elizabeth Barham]

Max Bowsher [EMAIL PROTECTED] writes:

 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.

What I'm wondering is of there is a better variable to use with the
import library, as opposed to ${lib}.a ?

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

I'd very much like to add this or something similar (8192) to the
distribution because, on my machine at least, it took about 45
minutes.

What is the MSYS-team's view on this?

Thanks Max,

Elizabeth


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Mingw-msys] Re: MinGW libtool DLL failure

[Earnie Boyd]

Elizabeth Barham wrote:


What is the MSYS-team's view on this?



I'm fine with it and will support the change to a constant.  Should that 
constant be adjusted based on w9x vs NT?

Earnie.



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Norman Vine]

Bob Friesenhahn [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
 Earnie,

 Using libtool from the head of libtool CVS, and test building
 ImageMagick under MinGW (MSYS environment), I get multiple-defined
 errors when linking the DLL as shown below.

 Ideas?

 g++ -shared
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o

try the latest binutils
http://sourceforge.net/project/shownotes.php?release_id=104238


also FYI there is a newer gcc release
$ g++-2 -v
Reading specs from D:/usr/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-8/specs
gcc version 2.95.3-8 (mingw special)

Norman






___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Earnie Boyd]

Elizabeth Barham wrote:
 Bob Friesenhahn [EMAIL PROTECTED] writes:
 
 
g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o  
.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o 
.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o 
.libs/Montage.o .libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o 
.libs/TypeMetric.o  -L/usr/local/lib ../../magick/.libs/libMagick-5.dll 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../.. -lstdc++ -luser32 -lkernel32 
-ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt   -o .libs/libMagick++-5.dll
 
 
 What about removing the first object file, the:
 
 c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
 
 part?
 
 The reason is that the multiple definitions were coming from within
 that particular object file - what happens without it?
 

With the link line fully qualified with all of the system libraries and 
objects you could just use ld directly.  It would be better, IMO, though 
to remove the system libraries from the link command and allow g[cc|++] 
to add the appropriate system libraries so that if some new system 
library is added, the package won't need to worry about it.

Earnie.



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Bob Friesenhahn]

On 9 Oct 2002, Elizabeth Barham wrote:

 What about removing the first object file, the:

 c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o

 part?

 The reason is that the multiple definitions were coming from within
 that particular object file - what happens without it?

What happens is that the problem goes away.  What changes do we need
to make to libtool to keep the extra crt object from being applied?

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Boehne, Robert]

 
 With the link line fully qualified with all of the system libraries and
 objects you could just use ld directly.  It would be better, IMO, though
 to remove the system libraries from the link command and allow g[cc|++]
 to add the appropriate system libraries so that if some new system
 library is added, the package won't need to worry about it.
 
 Earnie.
 

AAACK!  Oh no, that is definitely the compiler's job, I'm not going
to jump on a bandwagon of tracking every additional link flag tacked
on by every C++ compiler on the planet, Libtool is hard enough
to maintain as it is.  Clearly the compiler should be able to link
a shared library, if not, it is broken.
  The only thing that troubles me about the link line Bob posted is
that a .dll is specified in the link, not the corresponding .lib.
I'm not a Windows guru, but I thought that you never link to a
dll directly, but to the .lib that is created when the dll is.

HTH,

Robert


-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Bob Friesenhahn]

On Thu, 10 Oct 2002, Boehne, Robert wrote:

   The only thing that troubles me about the link line Bob posted is
 that a .dll is specified in the link, not the corresponding .lib.
 I'm not a Windows guru, but I thought that you never link to a
 dll directly, but to the .lib that is created when the dll is.

This, of course, is possible via the wonders of libtool.  Libtool
should hide the fact that a .lib or .a (or whatever) is actually used
under the covers.  In fact, Microsoft compilers, Cygwin, and MinGW
appear to use different naming schemes for these link libraries.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Earnie Boyd]

Bob Friesenhahn wrote:
 
 Cygwin does not have these problems so we have a working example.
 

As I've stated before, the workings parts are the same between MinGW and 
Cygwin with regard to producing the end result.  AFA libtool is 
concerned the two are equal.

Earnie.



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Earnie Boyd]

Bob Friesenhahn wrote:
 On Thu, 10 Oct 2002, Boehne, Robert wrote:
 
 
  The only thing that troubles me about the link line Bob posted is
that a .dll is specified in the link, not the corresponding .lib.
I'm not a Windows guru, but I thought that you never link to a
dll directly, but to the .lib that is created when the dll is.
 
 
 This, of course, is possible via the wonders of libtool.  Libtool
 should hide the fact that a .lib or .a (or whatever) is actually used
 under the covers.  In fact, Microsoft compilers, Cygwin, and MinGW
 appear to use different naming schemes for these link libraries.
 

Both Cygwin and MinGW should use .dll.a for shared import library and 
should use .a for static library.  Both Cygwin and MinGW will find 
foo.lib for -lfoo as a last resort if it exists in the library search 
path.  Both Cygwin and MinGW will find foo.dll to satisfy -lfoo if 
nothing libfoo.dll.a, libfoo.a or foo.lib doesn't exist and foo.dll is 
in the library search path.

Earnie.



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Earnie Boyd]

Earnie Boyd wrote:
 Bob Friesenhahn wrote:
 
 On Thu, 10 Oct 2002, Boehne, Robert wrote:


  The only thing that troubles me about the link line Bob posted is
 that a .dll is specified in the link, not the corresponding .lib.
 I'm not a Windows guru, but I thought that you never link to a
 dll directly, but to the .lib that is created when the dll is.



 This, of course, is possible via the wonders of libtool.  Libtool
 should hide the fact that a .lib or .a (or whatever) is actually used
 under the covers.  In fact, Microsoft compilers, Cygwin, and MinGW
 appear to use different naming schemes for these link libraries.

 
 Both Cygwin and MinGW should use .dll.a for shared import library and 
 should use .a for static library.  Both Cygwin and MinGW will find 
 foo.lib for -lfoo as a last resort if it exists in the library search 
 path.  Both Cygwin and MinGW will find foo.dll to satisfy -lfoo if 
 nothing libfoo.dll.a, libfoo.a or foo.lib doesn't exist and foo.dll is 
 in the library search path.
 

I should also mention that a static library can be used to resolve 
symbols for the .dll file.

Earnie.



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Earnie Boyd]

Earnie Boyd wrote:
 Earnie Boyd wrote:
 
 Bob Friesenhahn wrote:

 On Thu, 10 Oct 2002, Boehne, Robert wrote:


  The only thing that troubles me about the link line Bob posted is
 that a .dll is specified in the link, not the corresponding .lib.
 I'm not a Windows guru, but I thought that you never link to a
 dll directly, but to the .lib that is created when the dll is.




 This, of course, is possible via the wonders of libtool.  Libtool
 should hide the fact that a .lib or .a (or whatever) is actually used
 under the covers.  In fact, Microsoft compilers, Cygwin, and MinGW
 appear to use different naming schemes for these link libraries.


 Both Cygwin and MinGW should use .dll.a for shared import library and 
 should use .a for static library.  Both Cygwin and MinGW will find 
 foo.lib for -lfoo as a last resort if it exists in the library search 
 path.  Both Cygwin and MinGW will find foo.dll to satisfy -lfoo if 
 nothing libfoo.dll.a, libfoo.a or foo.lib doesn't exist and foo.dll is 
 in the library search path.

 
 I should also mention that a static library can be used to resolve 
 symbols for the .dll file.
 

And to complicate it more, static objects (i.e.: objects that aren't 
exported from the dll) can be stored in the same library as the import 
objects for the dll.  The libcygwin1.a library contains such objects for 
an example.  In this case the name should be reflective toward the 
static members, in other words libfoo.a.

Earnie.



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Bob Friesenhahn]

On Thu, 10 Oct 2002, Earnie Boyd wrote:

 Bob Friesenhahn wrote:
 
  Cygwin does not have these problems so we have a working example.

 As I've stated before, the workings parts are the same between MinGW and
 Cygwin with regard to producing the end result.  AFA libtool is
 concerned the two are equal.

CVS libtool fails to link C++ DLLs under MinGW, but succeeds under
Cygwin.  I have looked at the .la files, and everything appears to be
in order there, so the problem seems to be during the C++ DLL link
phase.  The MinGW environment is the base MinGW release, with Windows
API updates applied.

The behavior of libtool when linking under Cygwin and MinGW is shown
below (lines wrapped for clarity).  Please let me know if you spot a
reason for the failure.

Cygwin:

/bin/bash ../../libtool --mode=link g++ -O0 -march=i686
-L/usr/local/lib -L/usr/X11R6/lib -L/usr/X11R6/lib -L/usr/lib
-L/usr/local/lib -L/usr/X11R6/lib -L/usr/X11R6/lib -L/usr/lib -o
libMagick++.la -rpath /usr/local/lib -version-info 5:51:0 Blob.lo
BlobRef.lo CoderInfo.lo Color.lo Drawable.lo Exception.lo Functions.lo
Geometry.lo Image.lo ImageRef.lo Montage.lo Options.lo Pixels.lo
STL.lo Thread.lo TypeMetric.lo ../../magick/libMagick.la
g++ -shared -nostdlib .libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o
.libs/Color.o .libs/Drawable.o .libs/Exception.o .libs/Functions.o
.libs/Geometry.o .libs/Image.o .libs/ImageRef.o .libs/Montage.o
.libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o
.libs/TypeMetric.o -L/usr/local/lib -L/usr/X11R6/lib -L/usr/lib
../../magick/.libs/libMagick.dll.a -L/usr/lib/w32api
-L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5 -lstdc++ -lgcc -lcygwin
-luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -o
.libs/cygMagick++-5.dll -Wl,--image-base=0x1000
-Wl,--out-implib,.libs/libMagick++.dll.a
Creating library file: .libs/libMagick++.dll.a
creating libMagick++.la
(cd .libs  rm -f libMagick++.la  ln -s ../libMagick++.la libMagick++.la)

MinGW:

/bin/sh ../../libtool --mode=link g++ -O0 -march=i686 -L/usr/local/lib
-L/usr/local/lib -o libMagick++.la -rpath /usr/local/lib -version-info
5:51:0 Blob.lo BlobRef.lo CoderInfo.lo Color.lo Drawable.lo
Exception.lo Functions.lo Geometry.lo Image.lo ImageRef.lo Montage.lo
Options.lo Pixels.lo STL.lo Thread.lo TypeMetric.lo
../../magick/libMagick.la
g++ -shared
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o
.libs/Drawable.o .libs/Exception.o .libs/Functions.o .libs/Geometry.o
.libs/Image.o .libs/ImageRef.o .libs/Montage.o .libs/Options.o
.libs/Pixels.o .libs/STL.o .libs/Thread.o .libs/TypeMetric.o
-L/usr/local/lib ../../magick/.libs/libMagick-5.dll
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6
-Lc:/mingw/bin/../lib/gcc-lib -L/mingw/lib/gcc-lib/mingw32/2.95.3-6
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../..
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../.. -lstdc++ -luser32
-lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt -o
.libs/libMagick++-5.dll
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o: In
function `DllMainCRTStartup':
//c/cygmnt/samo/mingw/msys/dllcrt1.c(.text+0x0): multiple definition
of `DllMainCRTStartup@12'
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o(.text+0x0)://c/cygmnt/samo/mingw/msys/dllcrt1.c:
first defined here
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o: In
function `atexit':
//c/cygmnt/samo/mingw/msys/dllcrt1.c(.text+0xe8): multiple definition
of `atexit'
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o(.text+0xe8)://c/cygmnt/samo/mingw/msys/dllcrt1.c:
first defined here
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o: In
function `onexit':
//c/cygmnt/samo/mingw/msys/dllcrt1.c(.text+0x114): multiple definition
of `_onexit'
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o(.text+0x114)://c/cygmnt/samo/mingw/msys/dllcrt1.c:
first defined here
make[3]: *** [libMagick++.la] Error 1

==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Elizabeth Barham]

Bob Friesenhahn [EMAIL PROTECTED] writes:

 CVS libtool fails to link C++ DLLs under MinGW, but succeeds under
 Cygwin.  I have looked at the .la files, and everything appears to be
 in order there, so the problem seems to be during the C++ DLL link
 phase.  The MinGW environment is the base MinGW release, with Windows
 API updates applied.
 
 The behavior of libtool when linking under Cygwin and MinGW is shown
 below (lines wrapped for clarity).  Please let me know if you spot a
 reason for the failure.

Hi Bob,

For some reason I am temporarily unable to pull down a copy of the
current libtool via CVS (the latest change in the ChangeLog is from
09/2001).

May I have a copy of your config.log?

Thank you, Elizabeth


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Elizabeth Barham]

Bob Friesenhahn [EMAIL PROTECTED] writes:

 Ideas?
 
 g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o  
.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o 
.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o 
.libs/Montage.o .libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o 
.libs/TypeMetric.o  -L/usr/local/lib ../../magick/.libs/libMagick-5.dll 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../.. -lstdc++ -luser32 -lkernel32 
-ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt   -o .libs/libMagick++-5.dll

What happens if you run the above line by itself without the -shared
switch?

Elizabeth


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Bob Friesenhahn]

By the way, notice that this is a C++ DLL which is being linked
against a C DLL also built by libtool.  The C DLL did successfully
link using libtool.  The C DLL is based in part on a libtool
convenience library.

To be honest, I believe that there are still some run-time issues with
C++ DLLs under MinGW, but it should still be possible to create the
DLL.

Bob

On 9 Oct 2002, Elizabeth Barham wrote:

 Bob Friesenhahn [EMAIL PROTECTED] writes:

  Ideas?
 
  g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o  
.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o 
.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o 
.libs/Montage.o .libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o 
.libs/TypeMetric.o  -L/usr/local/lib ../../magick/.libs/libMagick-5.dll 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../.. -lstdc++ -luser32 -lkernel32 
-ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt   -o .libs/libMagick++-5.dll

 What happens if you run the above line by itself without the -shared
 switch?

 Elizabeth


==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Elizabeth Barham]

Bob Friesenhahn [EMAIL PROTECTED] writes:

 g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o  
.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o 
.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o 
.libs/Montage.o .libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o 
.libs/TypeMetric.o  -L/usr/local/lib ../../magick/.libs/libMagick-5.dll 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../.. -lstdc++ -luser32 -lkernel32 
-ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt   -o .libs/libMagick++-5.dll

What about removing the first object file, the:

c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o

part?

The reason is that the multiple definitions were coming from within
that particular object file - what happens without it?

Elizabeth


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool