Bug 10063

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.

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 ***