Summary: | 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail | ||
---|---|---|---|
Product: | glibc | Reporter: | Sergei Steshenko <sergstesh> |
Component: | libc | Assignee: | Ulrich Drepper <drepper.fsp> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | glibc-bugs |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | i686-pc-linux-gnu | Target: | i686-pc-linux-gnu |
Build: | i686-pc-linux-gnu | Last reconfirmed: | |
Attachments: | autogenerated wrapper script used to run 'make - k check' |
Description
Sergei Steshenko
2009-04-11 23:04:11 UTC
I've had a closer look at what is happening, and now I understand that that when 'make check' is run, LDFLAGS specified to 'configure' and indeed used during just 'make' (not 'make check') are not used, and even though libgcc_s.so.1 _could_ be found had LDFLAGS been passed/used, it is not found. I am rebuilding everything from scratch in order to have clean files without the excess debug info, and after I'm done I'll post the files with explanations hopefully proving my point. You have really no idea what you're talking about. libgcc_s is used at runtime and LDFLAGS has nothing to do with that. Again, nobody who is not an expert is ever supposed to compile and install glibc because it is far too dangerous. Nobody with some understand needed more information so far, otherwise documentation would have been contributed. If you want to describe in detail how the installation process works feel free to come up with a patch. But the process itself (configure etc) is fine and don't expect anyone else to compare about this. (In reply to comment #2) > You have really no idea what you're talking about. libgcc_s is used at runtime > and LDFLAGS has nothing to do with that. Again, nobody who is not an expert is > ever supposed to compile and install glibc because it is far too dangerous. > Nobody with some understand needed more information so far, otherwise > documentation would have been contributed. If you want to describe in detail > how the installation process works feel free to come up with a patch. But the > process itself (configure etc) is fine and don't expect anyone else to compare > about this. I actually have an idea how it's working, and yes LDFLAGS are used at link time and not at runtime. However, I also set LD_LIBRARY_PATH to point to the directories with .so files, and in this particular case it points to the directory with library in question. Now, let's stop talking about experts - in http://sourceware.org/bugzilla/show_bug.cgi?id=10062 I have already established that 'configure' doesn't guess target as it should, and I have established that the INSTALL file says nothing about the need to guide 'configure'. Were 'configure' and INSTALL files written by experts ? Created attachment 3881 [details]
autogenerated wrapper script used to run 'make - k check'
In the http://sourceware.org/bugzilla/attachment.cgi?id=3881&action=view file one can see this portion: " LD_LIBRARY_PATH=/mnt/sdb8/sergei/AFSWD_debug/install/autogen-5.9.5/lib:/mnt/sdb8/sergei/AFSWD_debug/install/binutils-2.19.1/lib:/mnt/sdb8/sergei/AFSWD_debug/install/bison-2.3/lib:/mnt/sdb8/sergei/AFSWD_debug/install/flex-2.5.35/lib:/mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/lib:/mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/lib/gcc/i686-pc-linux-gnu/4.3.3:/mnt/sdb8/sergei/AFSWD_debug/install/gmp-4.2.2/lib:/mnt/sdb8/sergei/AFSWD_debug/install/guile-1.8.6/lib:/mnt/sdb8/sergei/AFSWD_debug/install/libtool-2.2.6a/lib:/mnt/sdb8/sergei/AFSWD_debug/install/mpfr-2.3.2/lib:/mnt/sdb8/sergei/AFSWD_debug/install/ncurses-5.7/lib:/mnt/sdb8/sergei/AFSWD_debug/install/readline-5.1/lib:/mnt/sdb8/sergei/AFSWD_debug/install/tcl-8.4.19/lib:/mnt/sdb8/sergei/AFSWD_debug/install/tcl-8.4.19/lib/expect5.44.1:/mnt/sdb8/sergei/AFSWD_debug/install/tk-8.4.19/lib; export LD_LIBRARY_PATH; ", and in the portion one can also see /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/lib path, and 'ls' shows: " sergei@amdam2:~/junk> ls -ltr /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/lib/ total 22667sergei@amdam2:~/junk> ls -ltr /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/lib/ total 22667 drwxr-xr-x 3 qemu users 1024 2009-04-04 06:02 gcc -rwxr-xr-x 1 qemu users 939 2009-04-04 06:03 libsupc++.la -rw-r--r-- 1 qemu users 541554 2009-04-04 06:03 libsupc++.a -rwxr-xr-x 1 qemu users 4439219 2009-04-04 06:03 libstdc++.so.6.0.10 lrwxrwxrwx 1 qemu users 19 2009-04-04 06:03 libstdc++.so.6 -> libstdc++.so.6.0.10 lrwxrwxrwx 1 qemu users 19 2009-04-04 06:03 libstdc++.so -> libstdc++.so.6.0.10 -rwxr-xr-x 1 qemu users 1001 2009-04-04 06:03 libstdc++.la -rw-r--r-- 1 qemu users 7848186 2009-04-04 06:03 libstdc++.a -rwxr-xr-x 1 qemu users 35184 2009-04-04 06:03 libssp.so.0.0.0 lrwxrwxrwx 1 qemu users 15 2009-04-04 06:03 libssp.so.0 -> libssp.so.0.0.0 lrwxrwxrwx 1 qemu users 15 2009-04-04 06:03 libssp.so -> libssp.so.0.0.0 -rwxr-xr-x 1 qemu users 956 2009-04-04 06:03 libssp_nonshared.la -rw-r--r-- 1 qemu users 2704 2009-04-04 06:03 libssp_nonshared.a -rwxr-xr-x 1 qemu users 974 2009-04-04 06:03 libssp.la -rw-r--r-- 1 qemu users 59462 2009-04-04 06:03 libssp.a -rwxr-xr-x 1 qemu users 257229 2009-04-04 06:03 libmudflapth.so.0.0.0 lrwxrwxrwx 1 qemu users 21 2009-04-04 06:03 libmudflapth.so.0 -> libmudflapth.so.0.0.0 lrwxrwxrwx 1 qemu users 21 2009-04-04 06:03 libmudflapth.so -> libmudflapth.so.0.0.0 -rwxr-xr-x 1 qemu users 1021 2009-04-04 06:03 libmudflapth.la -rw-r--r-- 1 qemu users 298136 2009-04-04 06:03 libmudflapth.a -rwxr-xr-x 1 qemu users 249178 2009-04-04 06:03 libmudflap.so.0.0.0 lrwxrwxrwx 1 qemu users 19 2009-04-04 06:03 libmudflap.so.0 -> libmudflap.so.0.0.0 lrwxrwxrwx 1 qemu users 19 2009-04-04 06:03 libmudflap.so -> libmudflap.so.0.0.0 -rwxr-xr-x 1 qemu users 1007 2009-04-04 06:03 libmudflap.la -rw-r--r-- 1 qemu users 389686 2009-04-04 06:03 libmudflap.a -rw-r--r-- 1 qemu users 287721 2009-04-04 06:03 libgcc_s.so.1 lrwxrwxrwx 1 qemu users 13 2009-04-04 06:03 libgcc_s.so -> libgcc_s.so.1 -rwxr-xr-x 1 qemu users 2607001 2009-04-04 06:03 libgfortran.so.3.0.0 lrwxrwxrwx 1 qemu users 20 2009-04-04 06:03 libgfortran.so.3 -> libgfortran.so.3.0.0 lrwxrwxrwx 1 qemu users 20 2009-04-04 06:03 libgfortran.so -> libgfortran.so.3.0.0 -rwxr-xr-x 1 qemu users 1013 2009-04-04 06:03 libgfortran.la -rw-r--r-- 1 qemu users 4389444 2009-04-04 06:03 libgfortran.a -rwxr-xr-x 1 qemu users 306523 2009-04-04 06:03 libobjc.so.2.0.0 lrwxrwxrwx 1 qemu users 16 2009-04-04 06:03 libobjc.so.2 -> libobjc.so.2.0.0 lrwxrwxrwx 1 qemu users 16 2009-04-04 06:03 libobjc.so -> libobjc.so.2.0.0 -rwxr-xr-x 1 qemu users 981 2009-04-04 06:03 libobjc.la -rw-r--r-- 1 qemu users 411198 2009-04-04 06:03 libobjc.a -rw-r--r-- 1 qemu users 630484 2009-04-04 06:03 libiberty.a -rw-r--r-- 1 qemu users 170 2009-04-04 06:03 libgomp.spec -rwxr-xr-x 1 qemu users 128226 2009-04-04 06:03 libgomp.so.1.0.0 lrwxrwxrwx 1 qemu users 16 2009-04-04 06:03 libgomp.so.1 -> libgomp.so.1.0.0 lrwxrwxrwx 1 qemu users 16 2009-04-04 06:03 libgomp.so -> libgomp.so.1.0.0 -rwxr-xr-x 1 qemu users 986 2009-04-04 06:03 libgomp.la -rw-r--r-- 1 qemu users 199228 2009-04-04 06:03 libgomp.a sergei@amdam2:~/junk> drwxr-xr-x 3 qemu users 1024 2009-04-04 06:02 gcc -rwxr-xr-x 1 qemu users 939 2009-04-04 06:03 libsupc++.la -rw-r--r-- 1 qemu users 541554 2009-04-04 06:03 libsupc++.a -rwxr-xr-x 1 qemu users 4439219 2009-04-04 06:03 libstdc++.so.6.0.10 lrwxrwxrwx 1 qemu users 19 2009-04-04 06:03 libstdc++.so.6 -> libstdc++.so.6.0.10 lrwxrwxrwx 1 qemu users 19 2009-04-04 06:03 libstdc++.so -> libstdc++.so.6.0.10 -rwxr-xr-x 1 qemu users 1001 2009-04-04 06:03 libstdc++.la -rw-r--r-- 1 qemu users 7848186 2009-04-04 06:03 libstdc++.a -rwxr-xr-x 1 qemu users 35184 2009-04-04 06:03 libssp.so.0.0.0 lrwxrwxrwx 1 qemu users 15 2009-04-04 06:03 libssp.so.0 -> libssp.so.0.0.0 lrwxrwxrwx 1 qemu users 15 2009-04-04 06:03 libssp.so -> libssp.so.0.0.0 -rwxr-xr-x 1 qemu users 956 2009-04-04 06:03 libssp_nonshared.la -rw-r--r-- 1 qemu users 2704 2009-04-04 06:03 libssp_nonshared.a -rwxr-xr-x 1 qemu users 974 2009-04-04 06:03 libssp.la -rw-r--r-- 1 qemu users 59462 2009-04-04 06:03 libssp.a -rwxr-xr-x 1 qemu users 257229 2009-04-04 06:03 libmudflapth.so.0.0.0 lrwxrwxrwx 1 qemu users 21 2009-04-04 06:03 libmudflapth.so.0 -> libmudflapth.so.0.0.0 lrwxrwxrwx 1 qemu users 21 2009-04-04 06:03 libmudflapth.so -> libmudflapth.so.0.0.0 -rwxr-xr-x 1 qemu users 1021 2009-04-04 06:03 libmudflapth.la -rw-r--r-- 1 qemu users 298136 2009-04-04 06:03 libmudflapth.a -rwxr-xr-x 1 qemu users 249178 2009-04-04 06:03 libmudflap.so.0.0.0 lrwxrwxrwx 1 qemu users 19 2009-04-04 06:03 libmudflap.so.0 -> libmudflap.so.0.0.0 lrwxrwxrwx 1 qemu users 19 2009-04-04 06:03 libmudflap.so -> libmudflap.so.0.0.0 -rwxr-xr-x 1 qemu users 1007 2009-04-04 06:03 libmudflap.la -rw-r--r-- 1 qemu users 389686 2009-04-04 06:03 libmudflap.a -rw-r--r-- 1 qemu users 287721 2009-04-04 06:03 libgcc_s.so.1 lrwxrwxrwx 1 qemu users 13 2009-04-04 06:03 libgcc_s.so -> libgcc_s.so.1 -rwxr-xr-x 1 qemu users 2607001 2009-04-04 06:03 libgfortran.so.3.0.0 lrwxrwxrwx 1 qemu users 20 2009-04-04 06:03 libgfortran.so.3 -> libgfortran.so.3.0.0 lrwxrwxrwx 1 qemu users 20 2009-04-04 06:03 libgfortran.so -> libgfortran.so.3.0.0 -rwxr-xr-x 1 qemu users 1013 2009-04-04 06:03 libgfortran.la -rw-r--r-- 1 qemu users 4389444 2009-04-04 06:03 libgfortran.a -rwxr-xr-x 1 qemu users 306523 2009-04-04 06:03 libobjc.so.2.0.0 lrwxrwxrwx 1 qemu users 16 2009-04-04 06:03 libobjc.so.2 -> libobjc.so.2.0.0 lrwxrwxrwx 1 qemu users 16 2009-04-04 06:03 libobjc.so -> libobjc.so.2.0.0 -rwxr-xr-x 1 qemu users 981 2009-04-04 06:03 libobjc.la -rw-r--r-- 1 qemu users 411198 2009-04-04 06:03 libobjc.a -rw-r--r-- 1 qemu users 630484 2009-04-04 06:03 libiberty.a -rw-r--r-- 1 qemu users 170 2009-04-04 06:03 libgomp.spec -rwxr-xr-x 1 qemu users 128226 2009-04-04 06:03 libgomp.so.1.0.0 lrwxrwxrwx 1 qemu users 16 2009-04-04 06:03 libgomp.so.1 -> libgomp.so.1.0.0 lrwxrwxrwx 1 qemu users 16 2009-04-04 06:03 libgomp.so -> libgomp.so.1.0.0 -rwxr-xr-x 1 qemu users 986 2009-04-04 06:03 libgomp.la -rw-r--r-- 1 qemu users 199228 2009-04-04 06:03 libgomp.a sergei@amdam2:~/junk> " - among the files there is "libgcc_s.so -> libgcc_s.so.1" in question. 'glibc' is not the first target which needs to dynamically load libraries, and LD_LIBRARY_PATH is set by my tool by default. So, the remaining for me thing is to establish why/exactly where this setting is ignored. I am in the middle of something now, but I'll find this now. And do not close bugs with WORKSFORME - it's obvious that when SW is released, it undergoes some testing, but my tool stresses really well build mechanisms exercising cases normally not tried by developers, so I've got used that first build by myself quite often reveals a bunch of bugs in build mechanism. I'll reread 'ld' manual WRT LD_LIBRARY_PATH and other mechanisms to guide it to look for DLLs (.so files) in proper places. Maybe I'll have to use another mechanism or I'll come to the conclusion that build mechanism is flawed - time and effort will show. Sergstesh, I think Ulrich's point is that everyone who normally needs to build glibc (hackers and packagers) figured out how to do it and while making this process easier for newcomers might be nice, it's nowhere near being a priority for any glibc developer - potential new developers need to strap in for much more anyway and expanding the user base is irrelevant in this case. So if you want to have this fixed, you need to do all the work up to a final patch yourself and noone will probably even be much willing to spend time supporting you in the process. (In reply to comment #6) > Sergstesh, I think Ulrich's point is that everyone who normally needs to build > glibc (hackers and packagers) figured out how to do it and while making this > process easier for newcomers might be nice, it's nowhere near being a priority > for any glibc developer - potential new developers need to strap in for much > more anyway and expanding the user base is irrelevant in this case. So if you > want to have this fixed, you need to do all the work up to a final patch > yourself and noone will probably even be much willing to spend time supporting > you in the process. (In reply to comment #6) Too many words have been spent for nothing - I mean both bug reports of mine. So, I have a practical question to which I can fins an answer myself, or to which I can get the answer is shorter than the all the words already said in vain, and the question is: what mechanism WRT file paths is used to load, where necessary, libgcc_s.so.1: 1) absolute path related to system locations, like /lib, /usr/lib, etc.; 2) no path at all, but rather contents of LD_LIBRARY_PATH or another environment variable ? 3) a path calculated according to 'gcc' directory tree, e.g. 'gcc' is /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/bin/gcc , so its bin directory is simply dirname(/mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/bin/gcc) , i.e. /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/bin and, consequently, the 'lib directory is /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/bin/../lib == /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/lib ? I can answer the answer myself because I know about LD_DEBUG environment variable and I have already tried it, though not yet in the places I need to nail down this issue, but it will take more time from me than from those whi know the answer "by construction". Thanks in advance. AFAICS standard lookup rules apply, so (1) + (2). But please bear in mind that bugzilla is not a support forum; you might have better luck on IRC or at the mailing list, and best luck by trying to figure out the answers on your own first. |