[PATCH] Always create lib32 and lib64 symlinks

[Ralf Corsepius]

  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.
>>>
>>> Since we always remove them without checking CT_HOST, we need to
>>> create them without checking CT_HOST either.
>>>
>> 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.
> Ralf --
>
> 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.

>    Note that these symlinks are deleted without any
> conditional in do_finish:
>
>      # Remove the lib* symlinks, now:
>      # The symlinks are needed only during the build process.
>      # The final gcc will still search those dirs, but will also search
>      # the standard lib/ dirs, so we can get rid of the symlinks
>      for d in                            \
>          "${CT_PREFIX_DIR}"              \
>          "${CT_SYSROOT_DIR}"             \
>          "${CT_SYSROOT_DIR}/usr"         \
>          "${CT_PREFIX_DIR}/${CT_TARGET}" \
>      ; do
>          CT_DoExecLog ALL rm -f "${d}/lib32"
>          CT_DoExecLog ALL rm -f "${d}/lib64"
>      done
>
> 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 ... nor 
does your approach.

Ralf


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