Re: libtool and mkoctfile

[Marco Atzeri]

--- Mer 4/11/09, Benjamin Lindner <address@hidden> ha scritto:

> Da: Benjamin Lindner <address@hidden>
> Oggetto: Re: libtool and mkoctfile
> A: "Marco Atzeri" <address@hidden>
> Cc: "John W. Eaton" <address@hidden>, address@hidden
> Data: Mercoledì 4 novembre 2009, 23:17
> Marco Atzeri wrote:
> > --- Mer 4/11/09, Benjamin Lindner <address@hidden>
> ha scritto:
> > 
> >> Da: Benjamin Lindner <address@hidden>
> >> Oggetto: Re: libtool and mkoctfile
> >> A: "John W. Eaton" <address@hidden>
> >> Cc: address@hidden
> >> Data: Mercoledì 4 novembre 2009, 22:44
> >>> | One problem I see with gnulib is that it is
> >> C-centric rather than
> >>> | C++-centric.
> >>> 
> >>> What I'm looking for is something that will
> handle
> >> replacing the core
> >>> POSIX functions on systems that don't have
> them, or
> >> that have broken
> >>> versions.  Most often these days, that
> is
> >> Windows, isn't it?  And
> >>> these are relatively low-level functions
> defined with
> >> C language
> >>> interfaces.  So I don't see this as a
> problem.
> >> If you aim octave to rely on a posix base, then I
> guess at
> >> the end of the day, the only reasonable choice for
> windows
> >> platform is cygwin.
> >> 
> >> benjamin
> >> 
> > 
> > I start to be worried...to much stress on the windows
> horizon.
> > 
> > Just for your info I have not yet succeded to build
> octave
> > with the new libtool stuff. I am currently
> investigating on:
> >
> -------------------------------------------------------
> > *** Warning: This system can not link to static lib
> archive
> /bin/../lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.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.
> > libtool: link: rm -fr 
> .libs/liboctave.la.lnkscript
> > 
> > *** Warning: linker path does not have real file for
> library -lcholmod.
> > *** 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 libcholmod and none of the candidates passed
> a file format test
> > *** using a file magic. Last file checked:
> /usr/lib/libcholmod.a
> >
> ----------------------------------------------------------
> > 
> > Any other platform with similar issue ? It looks that
> libtool is wrongly guessing what to do.
> 
> :)
> 
> (sorry for me grinning - it's just I see that I am not the
> only one having problems with libtool)
> 
> Yes I see the same issue. Only for me libtool is mocking
> about gcc's -liberty.
> 
> I found the following ml thread
> http://lists.cairographics.org/archives/cairo/2009-July/017683.html
> and I also find, that patching (hacking?) libtool according
> to the answer here
> http://lists.cairographics.org/archives/cairo/2009-July/017684.html
> helps around this issue.
> 
> benjamin

Hi Benjamin,
I think I catched the issue, at least on cygwin but
probably it is similar on mingw.

When linking with real static libs as for me suitsparse,
I need to replace

AMD_LIBS = -lamd

with

AMD_LIBS = -Wc,-lamd

to advise libtool to forward the lib directly to the compiler for the linking.

As there is a precedence issue I need also to
add something more at the last of the Suitesparse libs.

CXSPARSE_LIBS = -Wc,-lcxsparse -Wc,-llapack -Wc,-lblas -Wc,-lcygwin

otherwise I have some undefined reference.

I am still in the process to build the things, but at least
the first roadblock seems gone.


Marco