[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: Ralf Wildenhues
Subject: Re: Got shared libraries to build with libtool on MinGW, but it was a struggle
Date: Fri, 16 Sep 2005 16:24:35 +0200
User-agent: Mutt/1.4.1i

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

> The second sed command above actually means
> something different; replace the whole pattern buffer with "import".
> However, that variation also works with the rest of the sed logic in
> func_win32_libid and most importantly works with MinGW;

Well, to work around it you could also use 's/^.*/import&/', I guess.

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


reply via email to

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