question on libtool usage/limitation

[Marco atzeri-3]

Hi All,
the development of octave is moving to automake + libtool
but we have some problem to convince libtool to correctly link
all the libs on cygwin.

Octave is built in C++, C and Fortran and during
the link phase we are specifing
both C++, C and Fortran installed libs, in same case static.
Suitesparse for example it is only static, also on other
platforms.

/usr/lib/libamd.a
/usr/lib/libbtf.a
/usr/lib/libcamd.a
/usr/lib/libccolamd.a
/usr/lib/libcholmod.a
/usr/lib/libcolamd.a
/usr/lib/libcsparse.a
/usr/lib/libcxsparse.a
/usr/lib/libklu.a
/usr/lib/libspqr.a
/usr/lib/libumfpack.a


In the past the link command was:

g++-4 -shared -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--enable-auto-image-base -Wl,--out-implib=liboctave.dll.a -o cygoctave.dll [huge list of x.o] -L../libcruft -L.  -lcruft -lcholmod -lumfpack  -lamd -lcamd -lcolamd -lccolamd -lcxsparse -larpack -lqrupdate -llapack -lblas -lfftw3 -lfftw3f -lreadline  -L/usr/lib -lpcre -lreadline  -lncurses -ldl -lwsock32 -lhdf5 -lz -lm  -lwsock32 -L/bin/../lib/gcc/i686-pc-cygwin/4.3.2 -L/bin/../lib/gcc -L/usr/lib/gcc/i686-pc-cygwin/4.3.2 -L/bin/../lib/gcc/i686-pc-cygwin/4.3.2/../../.. -lhdf5 -lz -lm -lgfortranbegin -lgfortran -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32

and the outcome was fine:
Creating library file: liboctave.dll.a

The current link command is
/bin/sh ../libtool --tag=CXX   --mode=link g++-4 -g -O2   -DHAVE_CONFIG_H -mieee-fp   -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2  -g -O2 -release 3.3.50+ -no-undefined -o liboctave.la -rpath /usr/local/lib/octave-3.3.50+  [huge list of x.lo]  ../libcruft/libcruft.la  -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -larpack -lqrupdate  -lfftw3 -lfftw3f -llapack -lblas -lreadline -lncurses  -L/usr/lib -lpcre -ldl -L/bin/../lib/gcc/i686-pc-cygwin/4.3.4 -L/bin/../lib/gcc -L/usr/lib/gcc/i686-pc-cygwin/4.3.4 -L/bin/../lib/gcc/i686-pc-cygwin/4.3.4/../../.. -lm -lgfortranbegin -lgfortran -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32  -lwsock32 -lm  -lwsock32 -lwsock32 -lm  -lwsock32

but the disappointing outcome is
-------------------------------------------------------
*** 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

[repeated for all the static libs]
-------------------------------------------------------

Does libtool on cygwin require special setting to overcome such
problem ? On linux platform the build seems to be fine.

Moreover for Fortran libgfortranbegin.la
is currently a static lib so I not easily overcome
the issue changing it to a dll.

Thanks in advance for any hint on where to look for

Marco





--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Dave Korn-6]

Marco Atzeri wrote:

> The current link command is
> /bin/sh ../libtool --tag=CXX   --mode=link g++-4 -g -O2   -DHAVE_CONFIG_H -mieee-fp   -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2  -g -O2 -release 3.3.50+ -no-undefined -o liboctave.la -rpath /usr/local/lib/octave-3.3.50+  [huge list of x.lo]  ../libcruft/libcruft.la  -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -larpack -lqrupdate  -lfftw3 -lfftw3f -llapack -lblas -lreadline -lncurses  -L/usr/lib -lpcre -ldl -L/bin/../lib/gcc/i686-pc-cygwin/4.3.4 -L/bin/../lib/gcc -L/usr/lib/gcc/i686-pc-cygwin/4.3.4 -L/bin/../lib/gcc/i686-pc-cygwin/4.3.4/../../.. -lm -lgfortranbegin -lgfortran -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32  -lwsock32 -lm  -lwsock32 -lwsock32 -lm  -lwsock32
>
> but the disappointing outcome is
> -------------------------------------------------------
> *** 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
>
> [repeated for all the static libs]
> -------------------------------------------------------
>
> Does libtool on cygwin require special setting to overcome such
> problem ? On linux platform the build seems to be fine.

  On Linux probably it's all shared libs and it doesn't matter if symbols
don't get resolved in the final link because they'll still be resolved at
load-time; on Windows of course everything must be resolved in the final link,
which limits libtool's options if it can't find the expected sorts of
libraries to link against.

> Moreover for Fortran libgfortranbegin.la
> is currently a static lib so I not easily overcome
> the issue changing it to a dll.

  Perhaps you'd better show us how you've defined the libtool primaries,
liboctave_la_LINK/LIBS/LDADD/xFLAGS/whatever in particular.  IIUC, depending
which one you use (and whether it's a full path to the .a file or a -lXXX
option), libtool interprets what you mean as either 1) please add the contents
of this library to the link, or 2) make the output library dependent on this
input library.  You're getting 2) when you want 1), and it's certainly to be
expected that attempting 2) with plain static archives that don't even have
libtool .la control scripts wouldn't work right on PE.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Marco atzeri-3]

--- Gio 5/11/09, Dave Korn  ha scritto:

>
> > The current link command is
> > /bin/sh ../libtool
> --tag=CXX   --mode=link g++-4 -g
> -O2   -DHAVE_CONFIG_H
> -mieee-fp   -Wall -W -Wshadow
> -Wold-style-cast -Wformat -g -O2  -g -O2 -release
> 3.3.50+ -no-undefined -o liboctave.la -rpath
> /usr/local/lib/octave-3.3.50+  [huge list of
> x.lo]  ../libcruft/libcruft.la  -lcholmod
> -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse
> -larpack -lqrupdate  -lfftw3 -lfftw3f -llapack -lblas
> -lreadline -lncurses  -L/usr/lib -lpcre -ldl
> -L/bin/../lib/gcc/i686-pc-cygwin/4.3.4 -L/bin/../lib/gcc
> -L/usr/lib/gcc/i686-pc-cygwin/4.3.4
> -L/bin/../lib/gcc/i686-pc-cygwin/4.3.4/../../.. -lm
> -lgfortranbegin -lgfortran -lcygwin -luser32 -lkernel32
> -ladvapi32 -lshell32  -lwsock32 -lm  -lwsock32
> -lwsock32 -lm  -lwsock32
> >
> > but the disappointing outcome is
> >
> -------------------------------------------------------
> > *** 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
> >
> > [repeated for all the static libs]
> >
> -------------------------------------------------------
> >
> > Does libtool on cygwin require special setting to
> overcome such
> > problem ? On linux platform the build seems to be
> fine.
>
>   On Linux probably it's all shared libs and it
> doesn't matter if symbols
> don't get resolved in the final link because they'll still
> be resolved at
> load-time; on Windows of course everything must be resolved
> in the final link,
> which limits libtool's options if it can't find the
> expected sorts of
> libraries to link against.
>
> > Moreover for Fortran libgfortranbegin.la
> > is currently a static lib so I not easily overcome
> > the issue changing it to a dll.
>
>   Perhaps you'd better show us how you've defined the
> libtool primaries,
> liboctave_la_LINK/LIBS/LDADD/xFLAGS/whatever in
> particular.  IIUC, depending
> which one you use (and whether it's a full path to the .a
> file or a -lXXX
> option), libtool interprets what you mean as either 1)
> please add the contents
> of this library to the link, or 2) make the output library
> dependent on this
> input library.  You're getting 2) when you want 1),
> and it's certainly to be
> expected that attempting 2) with plain static archives that
> don't even have
> libtool .la control scripts wouldn't work right on PE.
>
>     cheers,
>       DaveK
>

Hi Dave,
Thank for the clarification, I was suspecting something
like that.

I tried to "convince" libtool to use the static libraries,
building and ad hoc .la script, but I didn't fooled it.

I suppose that I should replace the simple "-llibcholmod"
with one of the methods mentioned in the libtool documentation:


`-Wc,FLAG'
`-Xcompiler FLAG'
     Pass a linker-specific flag directly to the compiler.

`-Wl,FLAG'
`-Xlinker FLAG'
     Pass a linker-specific flag directly to the linker.

`-XCClinker FLAG'
     Pass a link-specific flag to the compiler driver (CC) during
     linking.

but I need to understand, which and how to specify the static lib
/usr/lib/libcholmod.a (and the others)

Regards
Marco





--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Dave Korn-6]

Marco Atzeri wrote:
>
> --- Gio 5/11/09, Dave Korn  ha scritto:

>> Perhaps you'd better show us how you've defined the libtool primaries,
>> liboctave_la_LINK/LIBS/LDADD/xFLAGS/whatever in particular.

> I suppose that I should replace the simple "-llibcholmod"
> with one of the methods mentioned in the libtool documentation:

> but I need to understand, which and how to specify the static lib
> /usr/lib/libcholmod.a (and the others)

  Perhaps you'd better show us how you've defined the libtool primaries,
liboctave_la_LINK/LIBS/LDADD/xFLAGS/whatever in particular.  I *think* (but
need to do some digging through my inbox to check up) that the solution is
going to be something like adding the explicit path to the .a file into the
correct one of them so that the objects from the archive are available to the
link but libtool doesn't try to interpret it as a library dependency.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Marco atzeri-3]

--- Gio 5/11/09, Dave Korn  ha scritto:

> Data: Giovedì 5 novembre 2009, 14:21
> Marco Atzeri wrote:
> >
> > --- Gio 5/11/09, Dave Korn  ha scritto:
>
> >> Perhaps you'd better show us how you've defined
> the libtool primaries,
> >> liboctave_la_LINK/LIBS/LDADD/xFLAGS/whatever in
> particular.
>
> > I suppose that I should replace the simple
> "-llibcholmod"
> > with one of the methods mentioned in the libtool
> documentation:
>
> > but I need to understand, which and how to specify the
> static lib
> > /usr/lib/libcholmod.a (and the others)
>
>   Perhaps you'd better show us how you've defined the
> libtool primaries,
> liboctave_la_LINK/LIBS/LDADD/xFLAGS/whatever in
> particular.  I *think* (but
> need to do some digging through my inbox to check up) that
> the solution is
> going to be something like adding the explicit path to the
> .a file into the
> correct one of them so that the objects from the archive
> are available to the
> link but libtool doesn't try to interpret it as a library
> dependency.
>
>     cheers,
>       DaveK
>

Hi Dave,
I just found that if I replace that Suitesparse
libs requirement from (as example)

AMD_LIBS = -lamd

to

AMD_LIBS = -Wc,-lamd

the build seems to work. But this is just a workaround.

About your question on liboctave_la_LINK/LIBS/LDADD/xFLAGS/

we currently have :

octlib_LTLIBRARIES = liboctave.la

LINK_DEPS = \
  $(RLD_FLAG) \
  ../libcruft/libcruft.la \
  $(SPARSE_LDFLAGS) $(SPARSE_XLIBS) \
  $(ARPACK_LIBS) \
  $(QRUPDATE_LIBS) \
  $(FFTW_LDFLAGS) $(FFTW_XLIBS) \
  $(LAPACK_LIBS) $(BLAS_LIBS) \
  $(READLINE_LIBS) $(TERM_LIBS) \
  $(LIBGLOB) $(REGEX_LIBS) $(DL_LIBS) \
  $(FLIBS) \
  $(PTHREAD_LIBS) $(LIBS)

liboctave_la_SOURCES = \
  $(LIBOCTAVE_SOURCES) \
  $(LIBOCT_READLINE_SOURCES) \
  $(LIBOCT_PATHSEARCH_SOURCES)

liboctave_la_LIBADD = $(LINK_DEPS)

liboctave_la_LDFLAGS = -release $(version)

But I see no liboctave_la_LIBS

The SPARSE libs are real static libs.

$ cygcheck -l libSuiteSparse-devel |grep lib
/usr/lib/libamd.a
/usr/lib/libbtf.a
/usr/lib/libcamd.a
/usr/lib/libccolamd.a
/usr/lib/libcholmod.a
/usr/lib/libcolamd.a
/usr/lib/libcsparse.a
/usr/lib/libcxsparse.a
/usr/lib/libklu.a
/usr/lib/libspqr.a
/usr/lib/libumfpack.a

while all the other libs are dinamic ones as :

$ cygcheck -l libarpack-devel |grep lib
/usr/lib/libarpack.a
/usr/lib/libarpack.dll.a
/usr/lib/libarpack.la

Regards
Marco




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple