lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gub: I can now completely build lilypond


From: Knut Petersen
Subject: Re: gub: I can now completely build lilypond
Date: Tue, 15 Jan 2019 00:57:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3

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

||




reply via email to

[Prev in Thread] Current Thread [Next in Thread]