Re: Building LilyPond with GUB on a 64bit machine with 32bit OS
Op woensdag 17-12-2008 om 18:58 uur [tijdzone +0100], schreef Reinhold
Kainhofer:
it would be nice to have documented why we [think we] need this.
Actually, this IS what is breaking the configure check. By setting
LD_LIBRARY_PATH to the tools dir, you are telling the linker to use the
libraries from there (which are linked to glib 2.3). This fails in the guile
check, since some libraries are used from the system and some from the tools
dir.
If I uncomment all three
LD_LIBRARY_PATH': '%(tools_prefix)s/lib'
+ misc.append_path (os.environ.get ('LD_LIBRARY_PATH', '')),
settings in the gub/*.py files, then the configure check works fine and
lilypond
builds also fine.
Hmm. It's good if we can junk it, but I wonder why we had this in
the first place. Han-Wen?
I'm testing this now. I still don't understand how LD_LIBRARY_PATH has
an effect on the linker, and why it works for me and not for you...
It then only fails on the TODO file:
file from VC not distributed: lilypond-2.11.66/lily/TODO
rm -rf /tmp/tmpMdXowy
Traceback (most recent call last):
File test-lily/dist-check.py, line 136, in module
main ()
File test-lily/dist-check.py, line 131, in main
check_files (tarball, repo)
File test-lily/dist-check.py, line 116, in check_files
raise Exception ('dist error found')
Exception: dist error found
That must be a bug in lilypond HEAD. :-)
--
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
Re: Building LilyPond with GUB on a 64bit machine with 32bit OS
Am Dienstag, 16. Dezember 2008 schrieb Jan Nieuwenhuizen:
Should the LD_LIBRARY_PATH really be set during the execution of
lilypond's configure script???
Good question, but is this what breaks your configure run?
Every binary in tools should either have a wrapper, or
be using rpath. It is being set in gub/target.py:
'LD_LIBRARY_PATH': '%(tools_prefix)s/lib'
+ misc.append_path (os.environ.get ('LD_LIBRARY_PATH', '')),
it would be nice to have documented why we [think we] need this.
Actually, this IS what is breaking the configure check. By setting
LD_LIBRARY_PATH to the tools dir, you are telling the linker to use the
libraries from there (which are linked to glib 2.3). This fails in the guile
check, since some libraries are used from the system and some from the tools
dir.
If I uncomment all three
LD_LIBRARY_PATH': '%(tools_prefix)s/lib'
+ misc.append_path (os.environ.get ('LD_LIBRARY_PATH', '')),
settings in the gub/*.py files, then the configure check works fine and
lilypond
builds also fine.
It then only fails on the TODO file:
file from VC not distributed: lilypond-2.11.66/lily/TODO
rm -rf /tmp/tmpMdXowy
Traceback (most recent call last):
File test-lily/dist-check.py, line 136, in module
main ()
File test-lily/dist-check.py, line 131, in main
check_files (tarball, repo)
File test-lily/dist-check.py, line 116, in check_files
raise Exception ('dist error found')
Exception: dist error found
make[3]: *** [unlocked-dist-check] Fehler 1
make[3]: Verlasse Verzeichnis '/home/reinhold/lilypond/gub'
make[2]: *** [cached-dist-check] Fehler 2
make[2]: Verlasse Verzeichnis '/home/reinhold/lilypond/gub'
make[1]: *** [dist-check] Fehler 2
make[1]: Verlasse Verzeichnis '/home/reinhold/lilypond/gub'
Cheers,
Reinhold
--
--
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
* K Desktop Environment, http://www.kde.org, KOrganizer maintainer
* Chorvereinigung Jung-Wien, http://www.jung-wien.at/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building LilyPond with GUB on a 64bit machine with 32bit OS
Op dinsdag 16-12-2008 om 18:05 uur [tijdzone +0100], schreef Reinhold Kainhofer: [oops, back onto lily-devel] This is odd, we should not be linking to anything in tools/. Can you figure out why that happens? In the lilypond config.log: configure:8037: checking guile compile flags configure:8040: result: -I/home/reinhold/lilypond/gub/target/linux- x86/root/usr/include configure:8042: checking guile link flags configure:8045: result: -L/home/reinhold/lilypond/gub/target/linux- x86/root/usr/lib -lguile -lgmp configure:8070: checking libguile.h usability [...] GUILE='/home/reinhold/lilypond/gub/target/tools/root/usr/bin/guile' GUILE_CFLAGS='-I/home/reinhold/lilypond/gub/target/linux-x86/root/usr/include' GUILE_CONFIG='i686-linux-guile-config' GUILE_LDFLAGS='-L/home/reinhold/lilypond/gub/target/linux-x86/root/usr/lib - lguile -lgmp' This is OK. So, apparently, it is already using the guile in tools, which is linked too all the custom libraries rather than the system-wide libraries... Yes, we can use tools from target/tools/, that's the whole idea of tools. We just must not link to anything there, we can only link to target/linux-x86. It seems from this snippet conftest.c:2:1: warning: this is the location of the previous definition /home/lilypond/gub/target/tools/root/usr/lib/libexpat.so.0: undefined reference to `__stack_chk_f...@glibc_2.4' that something links to tools. You can try running the failed gcc command, possibly using --verbose or -Wl,--verbose to see how we pick-up tools. The reason is that the check for guile-config is: Yes, that's fine. I suppose the configure check should rather first check for guile-config (or it should not have the target_alias and host_alias set, since I'm not cross- compiling?) technically we're not cross compiling, but GUB just pretends that we are. I don't even think building/using a contained toolchain will work otherwise. 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
Re: Building LilyPond with GUB on a 64bit machine with 32bit OS
Op dinsdag 16-12-2008 om 18:33 uur [tijdzone +0100], schreef Reinhold
Kainhofer:
[back onto lily-devel]
Actually, even that does not work, since during the execution of the
configure
checks, there is
LD_LIBRARY_PATH=/home/reinhold/lilypond/gub/target/tools/root/usr/lib
Why is this a problem? We are not running guile-config, this is part of
why we have TARGET-guile-config.
Should the LD_LIBRARY_PATH really be set during the execution of lilypond's
configure script???
Good question, but is this what breaks your configure run?
Every binary in tools should either have a wrapper, or
be using rpath. It is being set in gub/target.py:
'LD_LIBRARY_PATH': '%(tools_prefix)s/lib'
+ misc.append_path (os.environ.get ('LD_LIBRARY_PATH', '')),
it would be nice to have documented why we [think we] need this.
Of course, you're building on a somewhat tricky system, while I would
not be suprised to see build problems on a plain x64_64 system
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
Re: Building LilyPond with GUB on a 64bit machine with 32bit OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Dienstag, 16. Dezember 2008 20:49:56 schrieb Jan Nieuwenhuizen: Op dinsdag 16-12-2008 om 18:33 uur [tijdzone +0100], schreef Reinhold Kainhofer: [back onto lily-devel] Actually, even that does not work, since during the execution of the configure checks, there is LD_LIBRARY_PATH=/home/reinhold/lilypond/gub/target/tools/root/usr/lib Why is this a problem? We are not running guile-config, this is part of why we have TARGET-guile-config. Should the LD_LIBRARY_PATH really be set during the execution of lilypond's configure script??? Good question, but is this what breaks your configure run? No, I just misunderstood your comment that lilypond should not link to **tools** (I thought it should not link to anything in the gub hierachy, which of course doesn't make sense...) Of course, you're building on a somewhat tricky system, while I would not be suprised to see build problems on a plain x64_64 system Actually, all my attempts today were made on my office machine (/proc/cpuinfo gives Intel(R) Core(TM)2 Duo CPU T5550 @ 1.83GHz) running standard Kubuntu intrepid. The server (where I get the exact same problem) is an AMD Athlon(tm) 64 Processor 3700+. Ah, I just saw that both processors are actually 64-bit processors, while the OS is 32-bit. But that can't be a problem here, since that shouldn't influence what lilypond links to. Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJSCTMTqjEwhXvPN0RAuG2AJ0ZW/jSwjGJxWr9wC+4V9og+btpvwCgmwaF iY6bFd70sq4QQrJo4zUT/cc= =bLvy -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building LilyPond with GUB on a 64bit machine with 32bit OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 15. Dezember 2008 schrieb Reinhold Kainhofer: However, I'm now running into the next problem: Lilypond's configure claims it is missing guile! - From the log file: configure:8270: checking for scm_boot_guile configure:8326: i686-linux-gcc -I/home/lilypond/gub/target/linux- x86/build/lilypond-git.sv.gnu.org--lilypond.git-master -o conftest -O2 - finline-functions -g -pipe -I/home/lily pond/gub/target/linux-x86/root/usr/include -Wl,--as-needed conftest.c - L/home/lilypond/gub/target/linux-x86/root/usr/lib -lguile -lgmp -ldl 5 conftest.c:8:1: warning: PACKAGE_NAME redefined conftest.c:2:1: warning: this is the location of the previous definition /home/lilypond/gub/target/tools/root/usr/lib/libltdl.so.3: undefined reference to `__stack_chk_f...@glibc_2.4' collect2: ld returned 1 exit status configure:8332: $? = 1 [...] configure:10752: checking for pango_ft2_font_map_create_context configure:10808: i686-linux-gcc -I/home/lilypond/gub/target/linux- x86/build/lilypond-git.sv.gnu.org--lilypond.git-master -o conftest -O2 - finline-functions -g -pipe -I/home/lil ypond/gub/target/linux-x86/root/usr/include/python2.4 - I/home/lilypond/gub/target/linux-x86/root/usr/include/pango-1.0 - I/home/lilypond/gub/target/linux-x86/root/usr/include/free type2 -I/home/lilypond/gub/target/linux-x86/root/usr/include - I/home/lilypond/gub/target/linux-x86/root/usr/include/glib-2.0 - I/home/lilypond/gub/target/linux-x86/root/usr/lib/gli b-2.0/include-Wl,--as-needed -Wl,-rpath -Wl,\$$ORIGIN/../lib conftest.c - L/home/lilypond/gub/target/linux-x86/root/usr/lib -lpangoft2-1.0 -lpango-1.0 - lfreetype -lz -lfontcon fig -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -ldl 5 conftest.c:8:1: warning: PACKAGE_NAME redefined conftest.c:2:1: warning: this is the location of the previous definition /home/lilypond/gub/target/tools/root/usr/lib/libexpat.so.0: undefined reference to `__stack_chk_f...@glibc_2.4' collect2: ld returned 1 exit status Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJRlyXTqjEwhXvPN0RAuqvAJ9q4WcwBo5rdIOefwE/QGE8Q37q+wCfXi5q Iav13eE6fRLaCRV+QGuUkbk= =xmTM -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building LilyPond with GUB on a 64bit machine with 32bit OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 15. Dezember 2008 schrieb Jan Nieuwenhuizen: Op zaterdag 13-12-2008 om 01:59 uur [tijdzone +0100], schreef Reinhold Kainhofer: Unfortunately, gmp does not build there, since the configure check seems to think it is on a 64-bit platform: Is this with GUB3? It's the checkout of git://github.com/janneke/gub.git checking size of mp_limb_t... 4 You can look in configure.ac for the test with this text configure: error: Oops, mp_limb_t is 32 bits, but the assembler code in this configuration expects 64 bits. and fix or disable it. Searching the web and the mailing lists a bit more revealed that there is an undocumented environment variable, which one can use to force a given ABI: ABI=32 make lilypond It's not ideal that gmp doesn't detect this automatically, but at least now it builds correctly. However, I'm now running into the next problem: Lilypond's configure claims it is missing guile! Here's the output: [...] checking for guile-config... i686-linux-guile-config checking i686-linux-guile-config version... 1.8.5 checking guile compile flags... -I/home/lilypond/gub/target/linux- x86/root/usr/include checking guile link flags... -L/home/lilypond/gub/target/linux-x86/root/usr/lib - -lguile -lgmp checking libguile.h usability... yes checking libguile.h presence... yes checking for libguile.h... yes checking for scm_boot_guile in -lguile... no checking for scm_boot_guile... no checking GUILE rational bugfix... ok [...] checking for guile... guile checking for guile... /home/lilypond/gub/target/tools/root/usr/bin/guile [...] config.status: creating config.make config.status: creating config.hh config.status: config.hh is unchanged ERROR: Please install required programs: libguile (libguile-dev, guile-devel or guile-dev package). Strange enough, on that same machine the nightly binary and docs builds work fine and detect guile just fine... The configure output of the current git master (using the system-wide installed guile) is: [...] checking for guile-config... guile-config checking guile-config version... 1.8.5 checking guile compile flags... -pthread checking guile link flags... -pthread -lguile -lltdl -Wl,-Bsymbolic-functions - -lgmp -lcrypt -lm -lltdl checking libguile.h usability... yes checking libguile.h presence... yes checking for libguile.h... yes checking for scm_boot_guile in -lguile... yes checking for scm_boot_guile... yes checking GUILE rational bugfix... ok [...] checking for guile... guile checking for guile... /usr/bin/guile So, apparently the guile built by gub is missing scm_boot_guile or some link flag Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJRlhsTqjEwhXvPN0RApAyAJ9MuLyiQu3M0xmn2pQ2+2PQxQIYOACeNlAG iiE7n2bGfUUQA8uUWOeqjnU= =/7rL -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Building LilyPond with GUB on a 64bit machine with 32bit OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a server with a 64-bit processor, on which I have installed a 32-bit Linux distribution (so I can reuse all my 32-bit self-created packages, among other reasons). Now, Graham is trying to use that server also as a build machine for lilypond releases. Unfortunately, gmp does not build there, since the configure check seems to think it is on a 64-bit platform: checking size of mp_limb_t... 4 configure: error: Oops, mp_limb_t is 32 bits, but the assembler code in this configuration expects 64 bits. You appear to have set $CFLAGS, perhaps you also need to tell GMP the intended ABI, see ABI and ISA in the manual. Command barfed: cd /home/lilypond/gub/target/tools/build/gmp-4.2.1 chmod +x /home/lilypond/gub/target/tools/src/gmp-4.2.1/configure /home/lilypond/gub/target/tools/src/gmp-4 .2.1/configure --prefix=/home/lilypond/gub/target/tools/install/gmp-4.2.1- root/usr --prefix=/home/lilypond/gub/target/tools/root/usr --enable-shared -- enable-static CFLAGS=-I/hom e/lilypond/gub/target/tools/root/usr/include LDFLAGS=- L/home/lilypond/gub/target/tools/root/usr/lib LD_LIBRARY_PATH=/home/lilypond/gub/target/tools/root/usr/lib Any idea how to solve this problem? Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJQwkCTqjEwhXvPN0RAuBNAKChRoxLljtskK0+SRt2GFt6LROEQQCbBnU8 TCVxZSV4h+IaC+k4nJ99TU4= =Y3+q -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
