This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


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: [PATCH] Always create lib32 and lib64 symlinks


All,

On Wednesday 29 September 2010 16:55:21 Ralf Corsepius wrote:
>   On 09/29/2010 04:50 PM, Anthony Foiani wrote:
> > On Wed, Sep 29, 2010 at 8:40 AM, Ralf Corsepius<rc040203@freenet.de>  wrote:
> >> On 09/29/2010 04:33 PM, Anthony Foiani wrote:
> >>> Always create lib32 and lib64 symlinks.
> >> Again, this is all wrong on multi-arch'ed systems (e.g. Fedora).
> >> You must not symlink 32bit libraries to 64bit libraries and vice versa.

Agreed. But there. we do *not* build multilib-ed toolchain in the first
place. So libs will be either 32-bit or 64-bit. Not both.

> > This is actually creating a place for the crosstool-NG tools to put
> > build libraries as they're built; it's not the system libraries
> > themselves.
> >
> > And, once again, my build completed with this patch, and it died
> > without it.
> Again, this doesn't mean anything.

At least, it means "there is a problem with how gcc decide where to put libs,
which turns down to ld having issues finding them later".

The patch fixes it by creating the */lib32 and */lib64  symlinks to the
corresponding */lib/ directories, which we know ld will find.

> >    Note that these symlinks are deleted without any
> > conditional in do_finish:

And we can do that because the cross ld will search in lib/ at runtime.

> > When I tried to use the stock version of crosstool-NG.sh.in, the build
> > failed at the end because the lib64 directory was created and had
> > "libiberty.a" within it.
> Right, crosstools doesn't handle multilibs/multiarchs correctly ...

It would be bettre phrased as: crostool-NG does *not* handle multilibs.
Multi-arch is yet another issue, and is sure not handled either.

> nor does your approach.

At least, it makes the toolchain build *and* work*. We can be academic and
try to do the Right Thing, and be stuck for the next X months (X being
quite large), or be pragmatic, and have it work now.

I do agree that we should try to handle it properly, and if you have the
solution to the problem, I'm ready to look at the patch. ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'



--
For unsubscribe information see http://sourceware.org/lists.html#faq


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