[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
Re: Got shared libraries to build with libtool on MinGW, but it was a struggle
Fri, 16 Sep 2005 16:24:35 +0200
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
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.
> 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.