libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: whole_archive/-r


From: Ralf Wildenhues
Subject: Re: whole_archive/-r
Date: Mon, 10 Jan 2005 12:17:40 +0100
User-agent: Mutt/1.4.1i

Hi Christopher,

* Christopher Mason wrote on Tue, Dec 21, 2004 at 05:12:00PM CET:
> 
> Two questions:

I haven't fully grokked the issue regarding your first question.
Hope somebody beats me to it..

Your second question consist of several questions:

> 2) Is there a way to stop libtool from doing -nostdlib nastiness?

In general it's necessary to avoid nuplicate symbols.  (I think.)

> Or indeed from hard coding library paths in general?

In general it's necessary to avoid that, when executed, your program
will work (i.e., use the right libraries linked to, and find them at all).

> (It seems to sometimes change my -lfoo into .../foo.so and sometimes
> not; I assume this is related to not being able to include static libs
> in .so's, but I can I turn it off on sane platforms)?  This doesn't
> work well when doing -m32 on 64 bit platforms; it hard codes the link
> paths for the 64 bit libraries, when if it just passed -lfoo
> everything would "just work."

This is a different problem.  Take a look at sys_lib_search_path_spec,
those paths are not hardcoded into the output (because the linker will
look there by default). 

You have most likely been hit by a problem which shows up much on
multiarch platforms:  libtool fails to sanitize paths before comparing:

E.g, linking against
  /usr/lib/libfoo.la
will work without the path hardcoded, but against
  /usr/lib/../lib64/libfoo.la
will fail.

We need to fix this.  The implications are not too easy to oversee,
however, and quite a bit of code in libtool is impacted.

Regards,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]