This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Solved: glibc-2.2.5 undefined _dl_cpuclock_offset


On Monday, 13. May 2002 11:04, Andreas Schwab wrote:
> Ingo Krabbe <i.krabbe@dokom.net> writes:
> |> Wow, that was a real hard one:
> |>
> |> I thought that `gcc -L/glibc225/lib main.c -lpthread' would be enough to
> |> link against /glibc225/lib/libpthread.so.0. But that isn't so, at least
> |> it isn't with new binutils package (You can get all version Numbers from
> |> the attachment I made to the first E-mail of this thread).
> |>
> |> Gcc actually links to what is contained in /lib/ld.so.cache I think,
> |> though when using /glibc225/lib/ld-linux.so.2 gcc should use
> |> /glibc225/etc/ld.so.cache, if it should link against a cache at all ?!
>
> Dependent libraries (from DT_NEEDED) that are not linked in explicitly are
> searched by the linker in the same way as during runtime.  This means that
> -L options are ignored, and DT_RPATH, LD_LIBRARY_PATH, --rpath-link and
> /etc/ld.so.cache are used instead (probably in this order, I'm not sure).
>
> Andreas.

Andreas,

thanks for this distinct information, but shouldn't /glibc/etc/ld.so.cache
should be used in the case that -dynamic-linker is /glibc/lib/ld-linux.so.2 or
more general shouldn't ../etc/ld.so.cache be looked up ?

I though of this, because glibc itself installs ldconfig this way, to use that
path !

BYE INGO


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]