[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Got shared libraries to build with libtool on MinGW, but it was a st

From: Alan W. Irwin
Subject: Re: Got shared libraries to build with libtool on MinGW, but it was a struggle
Date: Fri, 16 Sep 2005 10:21:43 -0700 (PDT)

On 2005-09-16 16:24+0200 Ralf Wildenhues wrote:

Hi Alan,

First, let me thank you for a very nice and detailed bug report!
Second, let me state beforehand that I sent it to some cygwin/mingw
people; to avoid duplicated effort, another discussion about this can be
read here:

* Alan W. Irwin wrote on Fri, Sep 16, 2005 at 02:58:38AM CEST:

Early on, we found that shared libraries could not be built on MinGW using
the libtool approach.  However a recent concentrated effort found two issues
whose solution solved the shared library problem on MinGW.

(1) The sed s/^/import/ command (found in the function func_win32_libid
within does not work properly on MinGW so that shared libraries
are never recognized.  The message returned is

"*** Warning: linker path does not have real file for library "

That specific message has some 700 hits on google by a lot of frustrated
libtool users, and I think the following change may satisfy most of their

I wonder now why not more people wrote bug reports to Libtool (the bug
reports I found which were connected with this error message had
different causes and have been fixed, AFAICS)..

The solution was to replace

s/^/import/ ==> s/^.*/import/

in func_win32_libid within  Our command-line tests show that the
first command works to insert "import" at the front of even empty lines on
Linux.  This is consistent with the regular expression documentation in
Linux (see info grep ==> regular expressions where it is stated that "^"
specifically matches the empty string at the start of the line).  However,
the result is different for MinGW sed and no match apparently can be made
for the empty anchor "/^/".

This strikes me too as very odd.  We should find out why this is the
case.  And fix that, too.

Perhaps the flags on the sed command affect the outcome for MinGW?  Here is
the full command in func_win32_libid that is failing on MinGW.

win32_nmres=`eval $NM -f posix -A $1 | \
sed -n -e '1,100{/ I /{x;/import/!{s/^/import/;h;p;};x;};}'`

Let's take a specific example. (Note, I am working from detailed notes that
our PLplot MinGW developer gave me, but he is shy about making bug reports,
and I don't have access to a MinGW system myself.)

He reported for a specific case the following bad result from the command line:

nm -f posix -A zlib.dll.a | \
sed -n -e '1,100{/ I /{x;/import/!{s/^/import/;h;p;};x;};}'

The expected "import" output did not appear.

However, if he tries instead

nm -f posix -A zlib.dll.a | \
sed -n -e '1,100{/ I /{x;/import/!{s/^.*/import/;h;p;};x;};}'

Note the expected "import" output does appear with this change to the sed
logic.  To complete this here is the result of nm -f posix -A zlib.dll.a
without the sed filtering:

zlib.dll.a[dt.o]: .bss b 00000000
zlib.dll.a[dt.o]: .data d 00000000
zlib.dll.a[dt.o]: .idata$4 i 00000000
zlib.dll.a[dt.o]: .idata$5 i 00000000
zlib.dll.a[dt.o]: .idata$7 i 00000000
zlib.dll.a[dt.o]: .text t 00000000
zlib.dll.a[dt.o]: __zlib_dll_a_iname I 00000000
zlib.dll.a[dh.o]: .bss b 00000000
zlib.dll.a[dh.o]: .data d 00000000
zlib.dll.a[dh.o]: .idata$2 i 00000000
zlib.dll.a[dh.o]: .idata$4 i 00000000
zlib.dll.a[dh.o]: .idata$5 i 00000000
zlib.dll.a[dh.o]: .text t 00000000
zlib.dll.a[dh.o]: __head_zlib_dll_a I 00000000
zlib.dll.a[dh.o]: __zlib_dll_a_iname U        
zlib.dll.a[dh.o]: fthunk i 00000004
zlib.dll.a[dh.o]: hname i 00000004

The strings with " I " in them trigger the rest of the sed script which
is why at least the second form produces the "import" response.

Ralf, I cannot find how to post to the thread at so I would
appreciate it if you would forward this specific full test to that
discussion thread for verification of the problem (or not).  (I assume that
any *.dll.a file will do for the test so long as it's output has the " I "
string in it that triggers the rest of the sed script.)

If they cannot easily verify the problem using the above full example, they
should state the version numbers of both MinGW and MSYS that they are using.
I will ask the PLplot developer with the MinGW/MSYS platform to do the same
(although knowing him as I do, he probably has the latest stable versions of
both MinGW and MSYS installed).

(2) Like Cygwin (a platform where we can build a shared version of PLplot
without difficulty), MinGW has no shared version of the math library.  It
does have a dummy static version of the math library to work around libtools
needs for static builds on MinGW, but that is a different story.  Since
there is no shared math library even with the above sed change you still get
the same
message for -lm, and shared libraries crash and burn again on MinGW because
of this.

One (bad) way out of this shared library dilemma is to ask the MinGW
developers to also build a dummy shared math library, but that solution
seems overly-complicated to me, and it is much easier IMO to put MinGW on
the libtool list of platforms without a math library.

For this I'd probably go with the judgement of the mingw/cygwin people.

I appreciate that separate decisions should be made on each issue.  Issue 1
will take a lot further investigation to get to the bottom of why the full
command above did not work on the MinGW/MSYS system the PLplot developer had
installed. However, I think issue 2 is a lot more straightforward to decide
assuming the mingw/cygwin libtool people confirm the PLplot developer's
report that no dummy _shared_ version of the math library is available on

Alan W. Irwin
email: address@hidden
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (; PLplot scientific plotting software
package (; the Yorick front-end to PLplot (; the
Loads of Linux Links project (; and the Linux Brochure Project

Linux-powered Science

reply via email to

[Prev in Thread] Current Thread [Next in Thread]