Re: Essential Symlinks: Explainations

On 1/4/06, Greg Schafer <[EMAIL PROTECTED]> wrote: > > No. It's more complicated than that :-/ GCC also has a say in the library > search path too. This is why the startfile_prefix_spec hack to GCC makes > it (mostly) do the right thing. The directory is passed as a -L flag to the linker by gcc.

Re: Essential Symlinks: Explainations

Tushar Teredesai wrote: > It found the libgcc_s in > /tools/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../libgcc_s.so. > Confirmed. Though it did come as a surprise. When I tried the test > that you mentioned, it found the glibc libraries in /tools/lib, not in > /usr/lib. I checked the command that

Re: Essential Symlinks: Explainations

On 1/1/06, Greg Schafer <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > > Additionally, the libgcc_s.so symlink is not needed. Only the > > libgcc_s.so.1 is needed so that glibc can dlopen that library (used in > > nptl). > > Are you sure? It found the libgcc_s in /tools/lib/gcc/i686-pc-l

Re: Essential Symlinks: Explainations

Tushar Teredesai wrote: > Additionally, the libgcc_s.so symlink is not needed. Only the > libgcc_s.so.1 is needed so that glibc can dlopen that library (used in > nptl). Are you sure? The libgcc_s.so symlink became necessary when LFS adopted the startfile_prefix_spec hackery in the toolchain read

Re: Essential Symlinks: Explainations

On 12/31/05, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > Additionally, the libgcc_s.so symlink is not needed. Only the > > libgcc_s.so.1 is needed so that glibc can dlopen that library (used in > > nptl). > > Used only in nptl testsuite :) Thanks. I was trying to

Re: Essential Symlinks: Explainations

Tushar Teredesai wrote: The section creates the necessary symlinks but does not explain why they are needed. Indeed, this would be a very valuable addition. Additionally, the libgcc_s.so symlink is not needed.