Re: Building GUB3

[Jan Nieuwenhuizen]

On wo, 2009-02-11 at 20:48 -0800, Patrick McCarty wrote:

Hi Patrick,

> Okay, now it halts at mingw::guile.  Everything is fine up until then.
> Here is the tail end of build.log.

Okay.  So seems that guile >= 1.8.4 has some import/export problems with
static libraries

    /bin/sh ../libtool --tag=CC   --mode=link i686-mingw32-gcc -mms-bitfields  
-g -O2 -Wall -Wmissing-prototypes  -Wl,-rpath -Wl,\$ORIGIN/../lib -o guile.exe 
guile-guile.o libguile.la -lregex -lgmp -lws2_32 -lm -lltdl 
    libtool: link: i686-mingw32-gcc -mms-bitfields -g -O2 -Wall 
-Wmissing-prototypes -Wl,-rpath -Wl,\$ORIGIN/../lib -o .libs/guile.exe 
guile-guile.o  ./.libs/libguile.a -lintl -lregex -lgmp -lws2_32 -lltdl
    guile-guile.o: In function `main':
    /home/pnorcks/git/gub/target/mingw/src/guile-1.8.6/libguile/guile.c:70: 
undefined reference to `__imp__scm_c_argv0_relocation'
    /home/pnorcks/git/gub/target/mingw/src/guile-1.8.6/libguile/guile.c:72: 
undefined reference to `__imp__scm_boot_guile'
    guile-guile.o: In function `inner_main':
    /home/pnorcks/git/gub/target/mingw/src/guile-1.8.6/libguile/guile.c:55: 
undefined reference to `__imp__gdb_options'

and has been reported with suggested fix

    http://lists.gnu.org/archive/html/bug-guile/2008-05/msg00016.html

but it hasn't made it into the stable branch so it seems.

Anyway, we're not interested in that, because we want to build shared
libraries; and that's what happens on my box.  In your logs, I see

    /bin/sh ../libtool --tag=CC   --mode=link i686-mingw32-gcc -mms-bitfields  
-g -O2 -Wall -Wmissing-prototypes -lintl -version-info 20:0:3 -export-dynamic 
-no-undefined -Wl,-rpath -Wl,\$ORIGIN/../lib -o libguile.la -rpath /usr/lib 
libguile_la
    [..]

    *** Warning: linker path does not have real file for library -lintl.
    *** 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 libintl but no candidates were found. (...for file magic test)

    *** Warning: linker path does not have real file for library -lregex.
    *** 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 libregex but no candidates were found. (...for file magic test)

    *** Warning: linker path does not have real file for library -lgmp.
    *** 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 libgmp and none of the candidates passed a file format test
    *** using a file magic. Last file checked: /usr/lib//libgmp.so.3.4.4

which causes the shared library to fail.

In my log I have the very same libtool link command, but it results in

    Creating library file: .libs/libguile.dll.a
    libtool: link: ( cd ".libs" && rm -f "libguile.la" && ln -s 
"../libguile.la" "libguile.la" )

so the question is: why is your libintl (and other libs) not found
by libtool.  Do you have

    target/mingw/root/usr/lib/libintl.la
    target/mingw/root/usr/bin/libintl-8.dll

and does the libintl.la make sense?  It is annoying that libtool mentions
checking /usr/lib/libgmp.so; it should not be looking there.

You could look if you can make any sense of running the libtool link 
command with -x

   /bin/sh -x ../libtool ....

IWBN if GUB were to disallow libtool to read from /usr.  
[..]
I finally cooked-up a patch for that, it took a bit more work than
I imagined.  With latest GUB3 you can do

   LIBRESTRICT=open:stat bin/gub mingw::guile  # or mingw::lilypond

This will disallow libtool to read from or stat in /, so this should
(from target/mingw/log/build.log) give us a clue why libtool reads
from /usr/lib on your machine.

Oh, this will trigger a full rebuild ;-)

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org