Re: gub: I can now completely build lilypond
Am Sa., 12. Jan. 2019 um 16:06 Uhr schrieb Thomas Morley : > I'll redo testings with a 32-bit OS soon. FWIW, I did a successful complete run of 'make lilypond' in LilyDev 4(?), based on debian-8, 32 bit (only thing I had to install was missing 'unzip') gub was amended with pull-requests 53, 54, 55, 56 Otherwise I copied `output-distance.py' from lilypond's git to $HOME and changed gub's lilypond.make according to the attached diff to the initial mail of this thread. Some observations: (1) in ./target/tools/log/python.log ./target/linux-ppc/log/python.log I read: failed python modules:nis_failed.soRunning dump_file (2) close to the end of 'make lilypond' terminal displays: print-success rule python test-lily/upload.py --branch=master --url git://git.sv.gnu.org/lilypond.git test result does not exist for lilypond-2.21.0-1.linux-x86.sh test result does not exist for lilypond-2.21.0-1.linux-64.sh test result does not exist for lilypond-2.21.0-1.linux-ppc.sh test result does not exist for lilypond-2.21.0-1.darwin-ppc.tar.bz2 test result does not exist for lilypond-2.21.0-1.darwin-x86.tar.bz2 test result does not exist for lilypond-2.21.0-1.freebsd-x86.sh test result does not exist for lilypond-2.21.0-1.freebsd-64.sh test result does not exist for lilypond-2.21.0-1.mingw.exe No clue how serious this may be... @ Karlin Am Sa., 12. Jan. 2019 um 19:06 Uhr schrieb Karlin High : > > On 1/12/2019 10:54 AM, Knut Petersen wrote: > > Attached patch fixes building of guile with gub on openSuSE tumbleweed > > and Ubuntu 18.04. > > For people who have never used GUB before, what is the preferred > operating system they should begin with? Ubuntu? Debian? One of the > LilyDevs? 32 or 64 bit? Which release? Looks like LilyDev 4 is a good start. Afterwards it may be worth to check how the new containers (with debian 9, iirc) perform. Would be very nice to have more people working/testing. Did I mention I've a weak laptop? This run of 'make lilypond' lasted more than 24h - a pain ... Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub: I can now completely build lilypond
On 14.01.19 12:15, Knut Petersen wrote:
Nothing suspicious with one exception:
home/gub/NewGub/gub/target/tools/root/usr/lib/libdb-4.7.so is opened as well as
/usr/lib64/libdb-4.8.so. Why did we link against libdb-4.8?
No time left for today ... maybe someone else has an idea how to prevent
tooly::python from using the system's libdb-4.8.
[ continued ]
Why is libdb-4.8 used? Let's search for the usage of the db.h include file ...
grep '^open\(at\)*(' STRACE/TP* | grep '/db\.h'
gives
STRACE/TP.6339:open("/home/gub/NewGub/gub/target/tools/build/python-2.4.5/db.h",
O_RDONLY|O_NOCTTY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
STRACE/TP.6339:open("/home/gub/NewGub/gub/target/tools/src/python-2.4.5/Include/db.h",
O_RDONLY|O_NOCTTY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
STRACE/TP.6339:open("/home/gub/NewGub/gub/target/tools/root/usr/include/db.h",
O_RDONLY|O_NOCTTY) = 4
In STRACE/TP.6339 we see that cc1 compiles dbmmodule.c:
"/usr/lib64/gcc/x86_64-suse-linux/8/cc1",
"-quiet",
"-I", "/home/gub/NewGub/gub/target/tools/build/python-2.4.5",
"-I", ".",
"-I", "/home/gub/NewGub/gub/target/tools/src/python-2.4.5/Include",
"-D_REENTRANT",
"-D", "NDEBUG",
"-D", "Py_BUILD_CORE",
"-D", "HAVE_BERKDB_H",
"-D", "DB_DBM_HSEARCH",
"/home/gub/NewGub/gub/target/tools/src/python-2.4.5/Modules/dbmmodule.c",
"-quiet",
"-dumpbase",
"dbmmodule.c",
"-mtune=generic",
"-march=x86-64",
"-auxbase-strip",
"Modules/dbmmodule.o",
"-g",
"-O3",
"-Wall",
"-Wstrict-prototypes",
"-fno-strict-aliasing",
"-fPIC",
"-o", "/tmp/cc6oFDrN.s"],
That's ok - cc1 uses our own db.h.
Somewhere there's a log of linking, find that file:
grep dbmmodule.o STRACE/* | grep 'open\(at\)*('
gives
STRACE/TP.6340:openat(AT_FDCWD, "Modules/dbmmodule.o",
O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
STRACE/TP.6358:openat(AT_FDCWD, "Modules/dbmmodule.o", O_RDONLY) = 14
STRACE/TP.6358:open("Modules/dbmmodule.o", O_RDONLY) = 18
STRACE/TP.6365:openat(AT_FDCWD, "Modules/dbmmodule.o", O_RDONLY) = 100
STRACE/TP.6365:open("Modules/dbmmodule.o", O_RDONLY) = 101
After cc* we expect 'as' and 'ar', so 6365 probably is the link log ... it is.
Now inspect how 'ld' searches/uses libdb:
grep libdb STRACE/TP.6365
gives
openat(AT_FDCWD,
"/home/gub/NewGub/gub/target/tools/root/usr/lib/../lib64/libdb.so", O_RDONLY) =
-1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD,
"/home/gub/NewGub/gub/target/tools/root/usr/lib/../lib64/libdb.a", O_RDONLY) =
-1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib64/gcc/x86_64-suse-linux/8/libdb.so", O_RDONLY) =
-1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib64/gcc/x86_64-suse-linux/8/libdb.a", O_RDONLY) =
-1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD,
"/usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64/libdb.so", O_RDONLY) = 108
open("/usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64/libdb.so",
O_RDONLY) = 109
and
dir /usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64/libdb.so
gives that this is a link to libdb-4.8.so:
lrwxrwxrwx 1 root root 12 28. Dez 12:39
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64/libdb.so -> libdb-4.8.so
So we have
/home/gub/NewGub/gub/target/tools/root/usr/lib/libdb-4.7.so
and a link to libdb-4.7.so
/home/gub/NewGub/gub/target/tools/root/usr/lib/libdb.so
but ld tries to use
/home/gub/NewGub/gub/target/tools/root/usr/lib/../lib64/libdb.so
, gives up and uses the system's libdb.so that is a link to libdb-4.8.so.
Let's inspect the ld's argv. We find some '-L' args:
"-L/home/gub/NewGub/gub/target/tools/root/usr/lib/../lib64",
"-L/usr/lib64/gcc/x86_64-suse-linux/8",
"-L/usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64",
"-L/lib/../lib64",
"-L/usr/lib/../lib64",
"-L/home/gub/NewGub/gub/target/tools/root/usr/lib",
"-L/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/lib",
"-L/usr/lib64/gcc/x86_64-suse-linux/8/../../..",
We also have a LIBRARY_PATH in the environment:
"LIBRARY_PATH=/home/gub/NewGub/gub/target/tools/root/usr/lib/../lib64/
:/usr/lib64/gcc/x86_64-suse-linux/8/
:/usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64/
:/lib/../lib64/
:/usr/lib/../lib64/
:/home/gub/NewGub/gub/target/tools/root/usr/lib/
:/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/lib/
:/usr/lib64/gcc/x86_64-suse-linux/8/../../../
:/lib/
:/usr/lib/",
But remember: LIBRARY_PATH is used only if all -L* options failed.
It's too late now, and I don't know if I have some spare time tomorrow.
tbc,
Knut
||
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Chord names clean-up; no more Banter, exceptionsPartial or \powerChords. (issue 363880043 by v.villen...@gmail.com)
Counted down, and pushed as https://git.savannah.gnu.org/cgit/lilypond.git/commit/?h=staging&id=78225bc1b386e12dc1d03a5d2c7a017c0a52a22d Thanks! https://codereview.appspot.com/363880043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES - Countdown for January 14th
Hello, Here is the current patch countdown list. The next countdown will be on the January 17th. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: 5459 Avoid Ghostscript-specific max/min operators in PS - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5459 http://codereview.appspot.com/342300043 5449 Chord names clean-up; no more Banter, exceptionsPartial or \powerChords. - Valentin Villenave https://sourceforge.net/p/testlilyissues/issues/5449 http://codereview.appspot.com/363880043 5448 Documentation: correction in guitar "power chords" tab example - Valentin Villenave https://sourceforge.net/p/testlilyissues/issues/5448 http://codereview.appspot.com/347030043 5447 Documentation: add predefined \powerChords command - Valentin Villenave https://sourceforge.net/p/testlilyissues/issues/5447 http://codereview.appspot.com/344100043 5251 document restNumberThreshold - Malte Meyn https://sourceforge.net/p/testlilyissues/issues/5251 http://codereview.appspot.com/353850043 5218 Footnote separator line - Malte Meyn https://sourceforge.net/p/testlilyissues/issues/5218 http://codereview.appspot.com/349080043 Countdown: 5458 ly: Updates to predefined Ukulele fretboards - James Lowe https://sourceforge.net/p/testlilyissues/issues/5458 http://codereview.appspot.com/367880043 Review: No patches in review at this time. New: No new patches at this time. Regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ly: Updates to predefined Ukulele fretboards (issue 367880043 by pkxgnugi...@runbox.com)
Patch on countdown for January 17th https://codereview.appspot.com/367880043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub: I can now completely build lilypond
On 13.01.19 13:59, Werner LEMBERG wrote:
Looks like it's `strace' time again...
Yes.
Building tools::python is broken on openSuSE tumbleweed as well as on ubuntu
18, but inspection reveals that the problems are _not_ identical. On ubuntu 18
the building of tools::python fails because libs are not found, but
diff --git a/gub/specs/python.py b/gub/specs/python.py
index 049b26f2..ac7251a0 100644
--- a/gub/specs/python.py
+++ b/gub/specs/python.py
@@ -191,6 +191,11 @@ class Python__tools (tools.AutoBuild, Python):
]
force_autoupdate = True
parallel_build_broken = True
+ configure_command =
('LD_LIBRARY_PATH=%(system_prefix)s/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} '
+ + tools.AutoBuild.configure_command)
+ install_command =
('LD_LIBRARY_PATH=%(system_prefix)s/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} '
+ + tools.AutoBuild.install_command)
+
make_flags = Python.make_flags + ' LIBC="-lcrypt -ldb"'
def patch (self):
Python.patch (self)
helps to cure that (most other xxx::python builds are still broken).
On openSuSE tumbleweed the situation is different: Let's have a look at a
broken build:
rm STRACE/*; strace -v -f -ff -s 1024 -o STRACE/TP bin/gub --fresh
tools::python
fails with
calculating dependencies
Checking for g++ ... /usr/bin/g++
Checking for gcc ... /usr/bin/gcc
must rebuild[tools]: system::gcc system::g++ python
building package: tools::python
*** Stage: download (python, tools)
*** Stage: untar (python, tools)
*** Stage: patch (python, tools)
*** Stage: autoupdate (python, tools)
*** Stage: configure (python, tools)
*** Stage: compile (python, tools)
Command barfed: cd /home/gub/NewGub/gub/target/tools/build/python-2.4.5 && make
BLDLIBRARY='-Wl,-rpath -Wl,\$$ORIGIN/../lib -Wl,-rpath
-Wl,/home/gub/NewGub/gub/target/tools/root/usr/lib -L. -lpython$(VERSION)' LIBC="-lcrypt
-ldb"
Tail of target/tools/log/python.log
esac
/bin/sh: line 1: 6376 Segmentation fault (core dumped)
LD_LIBRARY_PATH=/home/gub/NewGub/gub/target/tools/build/python-2.4.5:/home/gub/NewGub/gub/target/tools/root
CC='gcc -pthread -I/home/gub/NewGub/gub/target/tools/build/python-2.4.5'
LDSHARED='gcc -pthread
-I/home/gub/NewGub/gub/target/tools/build/python-2.4.5 -shared'
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E
/home/gub/NewGub/gub/target/tools/src/python-2.4.5/setup.py build
make: *** [sharedmods] Error 139
Command barfed: cd /home/gub/NewGub/gub/target/tools/build/python-2.4.5 && make
BLDLIBRARY='-Wl,-rpath -Wl,\$$ORIGIN/../lib -Wl,-rpath
-Wl,/home/gub/NewGub/gub/target/tools/root/usr/lib -L. -lpython$(VERSION)' LIBC="-lcrypt
-ldb"
Tail of target/tools/log/python.log
Segfault. Nice.
STRACE/TP.6376 shows the executable that caused the problem:
execve("./python", ["./python", "-E",
"/home/gub/NewGub/gub/target/tools/src/python-2.4.5/setup.py", "build"]
grep 'openat(' STRACE/TP.6376 | grep -v ENOENT' shows the files that were
opened with success:
openat(AT_FDCWD,
"/home/gub/NewGub/gub/target/tools/root/usr/lib/librestrict.so",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/gub/NewGub/gub/target/tools/build/python-2.4.5/libpython2.4.so.1.0",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libutil.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/gub/NewGub/gub/target/tools/root/usr/lib/libdb-4.7.so",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/libdb-4.8.so", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/gub/NewGub/gub/target/tools/src/python-2.4.5/setup.py", O_RDONLY) = 3
Nothing suspicious with one exception:
home/gub/NewGub/gub/target/tools/root/usr/lib/libdb-4.7.so is opened as well as
/usr/lib64/libdb-4.8.so. Why did we link against libdb-4.8?
Let's have a look at an ubuntu 16.04 strace log of '/python -E
/home/gub/NewGub/gub/target/tools/src/python-2.4.5/setup.py':
Rebuild with strace, find the relevant log:
mkdir STRACE
rm -f STRACE/*; strace -v -f -ff -s 1024 -o STRACE/TP bin/gub --fresh
tools::python
grep '"-E", "/home/gub/NewGub/gub/target/tools/src/python-2.4.5/setup.py", "build"'
STRACE/* | sed -e "s/\([^:]*\)[[:print:]]*/\1/"
reveals two log files. setup.py is processed twice. Obviously the older is the
file to inspect. Which files are opened during the successful build on ubuntu?
grep 'open(' STRACE/TP.17633 | grep -v ENOENT
gives
open("/home/gub/NewG
