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 <jann...@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
