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

[Alan W. Irwin]

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: http://thread.gmane.org/gmane.comp.gnu.mingw.user/17380
>
> * 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 ltmain.sh) 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
> > needs.
>
> 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 ltmain.sh.  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;};}'
import

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
http://thread.gmane.org/gmane.comp.gnu.mingw.user/17380 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
> *snip*
> > 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
MinGW.

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

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________