Re: libiberty problem : mingw build on latest development source

[Benjamin Lindner]

Tatsuro MATSUOKA wrote:
> Hello
>
> I have been trying to build current development trees.
>
> *********************
> description     GNU Octave (development branch)
> owner   John W. Eaton
> last change     Sat, 21 Nov 2009 21:44:51 -0500
> project home    http://savannah.gnu.org/projects/octave
> *****
>
> In linking libcruft, I have get the following.
>
> *** Warning: This system can not link to static lib archive
> c:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/libgfortranbe
> gin.la.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have.
>
> *** Warning: linker path does not have real file for library -liberty.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libiberty and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /mingw/lib/libiberty.a
> *** The inter-library dependencies that have been dropped here will be
> *** automatically added whenever a program is linked with this library
> *** or is declared to -dlopen it.
>
> *** Since this library must not contain undefined symbols,
> *** because either the platform does not support them or
> *** it was explicitly requested with -no-undefined,
> *** libtool will only create a static version of it.
>
> /mingw/lib/libiberty.a seemed to be a problem.
>
> I have googled and find one of the MinGW ML threads.

:) the next one to fall into the trap libtool lays.
I don't know why this fails the way it fails.

There is a quite lengthy thread on the maintainer's list
titled "gnulib and automake". Take a look.

For me, it boiled down to
http://lists.cairographics.org/archives/cairo/2009-July/017683.html

(Besides, libiberty is part of gcc)

Maybe (that's speculation on my part) it would also solve the
problem if one created a libiberty.la file for libiberty.a
(is this a gcc packaging bug?).

But again, for libstdc++.a there is a .la file, and it *breaks*
building in this case.

I didn't dig much deeper here.

benjamin