Re: [PATCH 1/1] Add multilib build support for libc target. Libc is build <multilib>-times in seperate sysroot directories. In a last step links are created to reflect the expected multilib structure.

["konrad.gaisler" <konrad@gaisler.com>]

On 12/26/2011 05:56 PM, Yann E. MORIN wrote:
> Konrad, All,
>
> On Saturday 24 December 2011 22:11:43 konrad.gaisler wrote:
> [--SNIP--]
>> Is it possible that I missed something here? I think the
>> first patch I sent included this lines:
>>
>> do_libc_start_files() {
> [--SNIP--]
>> }
> Indeed, this was missing in your first and second patches:
>      http://sourceware.org/ml/crossgcc/2011-11/msg00029.html
>      http://sourceware.org/ml/crossgcc/2011-11/msg00040.html
>
> I now have a better understanding of what is required, and where it is.
> Thanks!
>
>> The point here is that glibc's install process adds the /lib at the
>> end, however the multilib structure must have /lib before:
>> /lib/<multilib>. Adding these symlinks before makes the
>> libraries end up in the right place. The "rearrange" stage
>> then fixes up the wrong paths.
>> Hope that makes it more clear.
> That I understood, the part that was misleading was the missing hunk
> in do_libc_start_files.
>
> [--SNIP--]
>>>> +                               cat ${CT_SYSROOT_DIR}/${d}/${l}.so_ori_i | ${sed} -r -e "s/\/lib\/$l/\/lib\/$bdir\/$l/g">   ${CT_SYSROOT_DIR}/${d}/${l}.so
>>> With this sed expression, you are not rewriting the dynamic linker path,
>>> which means a multilib variant still uses the default "ld.so".
>> You might be right. My particular toolchain doesnt care as for the
>> ld.so probably doesnt differ. It is also so that in the final running
>> embedded-system, there is only one libc set, that is copied back
>> to /usr/lib.
> That is something we'll have to check later: is it possible to have more
> than one multilib running on the target? I believe that would need some
> non-trivial hackery to work properly...
No, not multiple multilibs, but one of the multilibs subdirs. For example
for the leon-sparc toolchain, the toolchain would have 4 subdirs: ./ 
msoft-float/
mv8 and mv8/msoft-float.
on hardware without fpu but mv8 you would  only copy and use the
mv8/msoft-float multilib-subdir  at /usr/lib, the others will not be used.
-- Konrad

>
> [--SNIP--]
>>> In the end, it leaves everything in "sysroot/${dir}".
>>> It would make much more sense to carefully move the libs in their correct
>>> place, that is:
>>>    - move everything from "sysroot/${dir}/lib"     ->   "sysroot/lib/${dir}"
>>>                       and "sysroot/${dir}/usr/lib" ->   "sysroot/usr/lib/${dir}"
>>>    - get rid of "sysroot/${dir}" alltogether
>>>
>>> That's because gcc will search for things in "sysroot/{usr/,}lib/${dir}/",
>>> not in "sysroot/${dir}/{usr/,}lib/"
>> I'm not an insider to glibc, but maybe there is a option to
>> glibc's configure that create the right multilib structure.
>> Then all the hustle with moving and or creating symbolic
>> links  would be unneeded.
> Anyway, with the missing part you added above, it is more clear what you
> were trying to achieve.
>
> [--SNIP--]
>>> Floats are not the only thing we have to account for. For example, some
>>> archs can define big/little multilib. And most probably other stuff
>>> as well...
>> Sorry, I dont really know the requirements for other archs, I
>> come up with this because I require for sparc glibc the --with-fp=no.
> Yep, I was just saying ;-)
>
> Regards,
> Yann E. MORIN.
>


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