Re: gnulib and automake

[Benjamin Lindner]

John W. Eaton wrote:
> On 31-Oct-2009, Benjamin Lindner wrote:
>
> | then did a ./autoconf.sh followed by a call to configure, without any 
> | "--enable" options.
> | I then replaced all libtool flags "--silent" by "--verbose".
>
> You can achieve the same by setting AM_LIBTOOLFLAGS in the
> configure.ac file.  I set it to --silent because it was producing so
> much output that it was hard to see when there were compiler warnings
> or errors.  But for now, maybe it is best to not use the --silent
> option by default, so I've commented out the line in configure.ac.

Oh, I understand why you set it to --silent, and I agree.
I just changed it for debugging purposes, because I hoped to get some 
additional informatiln from libtool.

> | Then "make" runs until libcruft is built, and again, no shared library 
> | is created.
> | The output is:
> | 
> | /bin/sh ../libtool --tag=CXX --verbose  --mode=link 
> | mingw32-g++-4.4.0-dw2 -shared-libgcc -march=i686 -mtune=generic -O3 
> | -Wall   -DHAVE_CONFIG_H -mieee-fp    -Wall -W -Wshadow -Wold-style-cast 
> | -Wformat -march=i686 -mtune=generic -O3 -Wall  -march=i686 
> | -mtune=generic -O3 -Wall -release 3.3.50+ -shared-libgcc 
> | -Wl,--allow-multiple-definition -o libcruft.la -rpath 
> | /usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4/lib/octave-3.3.50+ 
> | [...]
> | libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 
> | shared libraries
>
> So this is preventing libtool from running any commands to generate
> the shared library?
>
> | libtool: link: ar cru .libs/libcruft.a  amos/.libs/cacai.o 
> | [...]
> | libtool: link: ranlib .libs/libcruft.a
> | libtool: link: creating libcruft.la
> | libtool: link: ( cd ".libs" && rm -f "libcruft.la" && ln -s 
> | "../libcruft.la" "libcruft.la" )
> | make[2]: Leaving directory 
> | `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft'
>
> So it is creating static libraries even though the disable-static
> option is supplied ott LT_INIT?  Do you see why that is happening?

It appears to be so.

> | I tried again and added "-no-undefined" to libtool link command.
> | Doesn't help.
>
> | Making all in libcruft
> | make[2]: Entering directory 
> | `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft'
> | /bin/sh ../libtool --tag=CXX --verbose  --mode=link 
> | mingw32-g++-4.4.0-dw2 -shared-libgcc -no-undefined -march=i686 
> | -mtune=generic -O3 -Wall   -DHAVE_CONFIG_H -mieee-fp    -Wall -W 
> | -Wshadow -Wold-style-cast -Wformat -march=i686 -mtune=generic -O3 -Wall 
> |   -march=i686 -mtune=generic -O3 -Wall -release 3.3.50+ -shared-libgcc 
> | -Wl,--allow-multiple-definition -o libcruft.la -rpath 
> | /usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4/lib/octave-3.3.50+ 
> | [...]
> | villad/intrp.lo villad/jcobi.lo villad/radau.lo villad/vilerr.lo 
> | -llapack -lblas -lgfortran -liberty -lm  -lgdi32 -lws2_32 -luser32 
> | -lkernel32
> | libtool: link: rm -fr  .libs/libcruft.a .libs/libcruft.lai
> | 
> | *** 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.
> | libtool: link: ar cru .libs/libcruft.a amos/.libs/cacai.o 
>
> If you remove -liberty from this call to libtool, what link command
> does libtool eventually execute?  Does it work?  What happens if you
> add the -liberty option to this command?
>
> I'm willing to do some work to find solutions to these problems.  It
> might go faster if you or someone else could tell me what I need to
> install so that I can try to build Octave on a Windows system.

I did some googleing (how do spell this anyway? :) and found:

http://lists.cairographics.org/archives/cairo/2009-July/017683.html

and the answer at

http://lists.cairographics.org/archives/cairo/2009-July/017684.html

Now this is getting me somewhere.

If I patch msys' libtool as

--- /share/aclocal/libtool.m4   2009-10-31 17:24:28 +0100
+++ octave-tip-automake/m4/libtool.m4   2009-10-31 17:57:23 +0100
@@ -2954,13 +2954,7 @@
   # Base MSYS/MinGW do not provide the 'file' command needed by
   # func_win32_libid shell function, so use a weaker test based on 
'objdump',
   # unless we find 'file', for example because we are cross-compiling.
-  if ( file / ) >/dev/null 2>&1; then
-    lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
-    lt_cv_file_magic_cmd='func_win32_libid'
-  else
-    lt_cv_deplibs_check_method='file_magic file format 
pei*-i386(.*architecture: i386)?'
-    lt_cv_file_magic_cmd='$OBJDUMP -f'
-  fi
+  lt_cv_deplibs_check_method=pass_all
   ;;

 cegcc*)

and add "-no-undefined" to libtool link command in makefile.in of 
libcruft, liboctave and liboctinterp as


libcruft_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \
        $(LIBTOOLFLAGS) --mode=link $(CXXLD) -no-undefined $(AM_CXXFLAGS) \
        $(CXXFLAGS) $(libcruft_la_LDFLAGS) $(LDFLAGS) -o $@


liboctave_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \
        $(LIBTOOLFLAGS) --mode=link $(CXXLD) -no-undefined $(AM_CXXFLAGS) \
        $(CXXFLAGS) $(liboctave_la_LDFLAGS) $(LDFLAGS) -o $@


liboctinterp_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \
        $(LIBTOOLFLAGS) --mode=link $(CXXLD) -no-undefined $(AM_CXXFLAGS) \
        $(CXXFLAGS) $(liboctinterp_la_LDFLAGS) $(LDFLAGS) -o $@
CXXLINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
	--mode=link $(CXXLD) -no-undefined $(AM_CXXFLAGS) $(CXXFLAGS) 
$(AM_LDFLAGS) \
        $(LDFLAGS) -o $@


Then I get a shared libcruft, shared liboctave and shared liboctinterp. 
Ha! Victory at last.

Building .oct files not fails with undefined reference errors.
I think I can guess what is missing here.

I'll start with your new patch and put the bits and pieces together.

benjamin