public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/10063] New: 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail
@ 2009-04-11 23:04 sergstesh at yahoo dot com
2009-04-12 0:31 ` [Bug libc/10063] " sergstesh at yahoo dot com
` (8 more replies)
0 siblings, 9 replies; 11+ messages in thread
From: sergstesh at yahoo dot com @ 2009-04-11 23:04 UTC (permalink / raw)
To: glibc-bugs
Now that I've managed to successfully build glibc-2.9 I see a lot of 'make
check' failures related to pthreads, and a lot of
libgcc_s.so.1 must be installed for pthread_cancel to work
messages.
Either 'configure' should check presence of libgcc_s.so.1 or, at least,
glibc-2.9/INSTALL file should contain instruction to have the library installed.
I see neither.
Build was configured the same way as in
http://sourceware.org/bugzilla/show_bug.cgi?id=10062
.
Still, ideally 'configure' check libgcc_s.so.1 presence and if it is not found,
exclude the tests which depend on it from the test suite.
--
Summary: 'configure' for glibc-2.9 does not check libgcc_s.so.1
presence, test fail
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper at redhat dot com
ReportedBy: sergstesh at yahoo dot com
CC: glibc-bugs at sources dot redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=10063
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libc/10063] 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail
2009-04-11 23:04 [Bug libc/10063] New: 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail sergstesh at yahoo dot com
@ 2009-04-12 0:31 ` sergstesh at yahoo dot com
2009-04-12 16:25 ` drepper at redhat dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 11+ messages in thread
From: sergstesh at yahoo dot com @ 2009-04-12 0:31 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From sergstesh at yahoo dot com 2009-04-12 00:31 -------
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.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10063
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libc/10063] 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail
2009-04-11 23:04 [Bug libc/10063] New: 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail sergstesh at yahoo dot com
2009-04-12 0:31 ` [Bug libc/10063] " sergstesh at yahoo dot com
@ 2009-04-12 16:25 ` drepper at redhat dot com
2009-04-12 21:09 ` sergstesh at yahoo dot com
` (6 subsequent siblings)
8 siblings, 0 replies; 11+ messages in thread
From: drepper at redhat dot com @ 2009-04-12 16:25 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper at redhat dot com 2009-04-12 16:25 -------
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.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
http://sourceware.org/bugzilla/show_bug.cgi?id=10063
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libc/10063] 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail
2009-04-11 23:04 [Bug libc/10063] New: 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail sergstesh at yahoo dot com
2009-04-12 0:31 ` [Bug libc/10063] " sergstesh at yahoo dot com
2009-04-12 16:25 ` drepper at redhat dot com
@ 2009-04-12 21:09 ` sergstesh at yahoo dot com
2009-04-12 21:11 ` sergstesh at yahoo dot com
` (5 subsequent siblings)
8 siblings, 0 replies; 11+ messages in thread
From: sergstesh at yahoo dot com @ 2009-04-12 21:09 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From sergstesh at yahoo dot com 2009-04-12 21:09 -------
(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 ?
--
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WORKSFORME |
http://sourceware.org/bugzilla/show_bug.cgi?id=10063
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libc/10063] 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail
2009-04-11 23:04 [Bug libc/10063] New: 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail sergstesh at yahoo dot com
` (2 preceding siblings ...)
2009-04-12 21:09 ` sergstesh at yahoo dot com
@ 2009-04-12 21:11 ` sergstesh at yahoo dot com
2009-04-12 21:21 ` sergstesh at yahoo dot com
` (4 subsequent siblings)
8 siblings, 0 replies; 11+ messages in thread
From: sergstesh at yahoo dot com @ 2009-04-12 21:11 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From sergstesh at yahoo dot com 2009-04-12 21:11 -------
Created an attachment (id=3881)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=3881&action=view)
autogenerated wrapper script used to run 'make - k check'
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10063
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libc/10063] 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail
2009-04-11 23:04 [Bug libc/10063] New: 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail sergstesh at yahoo dot com
` (3 preceding siblings ...)
2009-04-12 21:11 ` sergstesh at yahoo dot com
@ 2009-04-12 21:21 ` sergstesh at yahoo dot com
2009-04-13 21:22 ` pasky at suse dot cz
` (3 subsequent siblings)
8 siblings, 0 replies; 11+ messages in thread
From: sergstesh at yahoo dot com @ 2009-04-12 21:21 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From sergstesh at yahoo dot com 2009-04-12 21:21 -------
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.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10063
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libc/10063] 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail
2009-04-11 23:04 [Bug libc/10063] New: 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail sergstesh at yahoo dot com
` (4 preceding siblings ...)
2009-04-12 21:21 ` sergstesh at yahoo dot com
@ 2009-04-13 21:22 ` pasky at suse dot cz
2009-04-13 23:17 ` sergstesh at yahoo dot com
` (2 subsequent siblings)
8 siblings, 0 replies; 11+ messages in thread
From: pasky at suse dot cz @ 2009-04-13 21:22 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From pasky at suse dot cz 2009-04-13 21:22 -------
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.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10063
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libc/10063] 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail
2009-04-11 23:04 [Bug libc/10063] New: 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail sergstesh at yahoo dot com
` (5 preceding siblings ...)
2009-04-13 21:22 ` pasky at suse dot cz
@ 2009-04-13 23:17 ` sergstesh at yahoo dot com
2009-04-14 3:08 ` pasky at suse dot cz
2010-06-01 4:05 ` pasky at suse dot cz
8 siblings, 0 replies; 11+ messages in thread
From: sergstesh at yahoo dot com @ 2009-04-13 23:17 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From sergstesh at yahoo dot com 2009-04-13 23:17 -------
(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.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10063
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libc/10063] 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail
2009-04-11 23:04 [Bug libc/10063] New: 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail sergstesh at yahoo dot com
` (6 preceding siblings ...)
2009-04-13 23:17 ` sergstesh at yahoo dot com
@ 2009-04-14 3:08 ` pasky at suse dot cz
2010-06-01 4:05 ` pasky at suse dot cz
8 siblings, 0 replies; 11+ messages in thread
From: pasky at suse dot cz @ 2009-04-14 3:08 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From pasky at suse dot cz 2009-04-14 03:08 -------
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.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10063
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libc/10063] 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail
2009-04-11 23:04 [Bug libc/10063] New: 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail sergstesh at yahoo dot com
` (7 preceding siblings ...)
2009-04-14 3:08 ` pasky at suse dot cz
@ 2010-06-01 4:05 ` pasky at suse dot cz
8 siblings, 0 replies; 11+ messages in thread
From: pasky at suse dot cz @ 2010-06-01 4:05 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From pasky at suse dot cz 2010-06-01 04:04 -------
The only real part of the bug seems to have ended up being the same as bug 10062.
*** This bug has been marked as a duplicate of 10062 ***
--
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |DUPLICATE
http://sourceware.org/bugzilla/show_bug.cgi?id=10063
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libc/10063] 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail
[not found] <bug-10063-131@http.sourceware.org/bugzilla/>
@ 2014-07-01 7:19 ` fweimer at redhat dot com
0 siblings, 0 replies; 11+ messages in thread
From: fweimer at redhat dot com @ 2014-07-01 7:19 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=10063
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security-
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-07-01 7:19 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-11 23:04 [Bug libc/10063] New: 'configure' for glibc-2.9 does not check libgcc_s.so.1 presence, test fail sergstesh at yahoo dot com
2009-04-12 0:31 ` [Bug libc/10063] " sergstesh at yahoo dot com
2009-04-12 16:25 ` drepper at redhat dot com
2009-04-12 21:09 ` sergstesh at yahoo dot com
2009-04-12 21:11 ` sergstesh at yahoo dot com
2009-04-12 21:21 ` sergstesh at yahoo dot com
2009-04-13 21:22 ` pasky at suse dot cz
2009-04-13 23:17 ` sergstesh at yahoo dot com
2009-04-14 3:08 ` pasky at suse dot cz
2010-06-01 4:05 ` pasky at suse dot cz
[not found] <bug-10063-131@http.sourceware.org/bugzilla/>
2014-07-01 7:19 ` fweimer at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).