simple multilib option

[Konrad Eisele]

Yann E. MORIN wrote:
> Konrad, All,
> 
> On Monday 14 November 2011 11:30:54 Konrad Eisele wrote:
>> I'll send revised patches as reply to this one, in the
>> meantime here are the comment-comments:
> 
> OK, I saw your updated patch. I'll have a look tomorow, it's a bit late
> for me here for now, and I could not get to review it this evening...
> Sorry for the delay this implies... :-(
> 
>> I'll send the Multilib-patches only. I also skip the CC_MULTILIB
>> option definition, as for you have to decide where to put it.
> 
> Sorry I was not explicit. My opinion is it should go into the toolchain
> sub-menu. If you think of a better place, feel free to suggest it. :-)

You should decide.

>>>> +               done
>>>> +
>>>> +                # rewrite the library multiplexers
>>>> +               for l in libc libpthread libgcc_s; do
>>>> +                   for d in lib/${dir} usr/lib/${dir}; do
>>>> +                       if [ -f "${CT_SYSROOT_DIR}/${d}/${l}.so" -a ! -L ${CT_SYSROOT_DIR}/${d}/${l}.so ]; then
>>>> +                           if [ ! -f "${CT_SYSROOT_DIR}/${d}/${l}.so_ori_i" ]; then
>>>
>>> What if the the _ori_i file already exist?
>>> Surely, it should not happen, and if it does, we should consider this
>>> as an error.
>>
>> I emit a Warning. If _iri_i exist it will already have been patched.
> 
> But why would a file, that we _just_installed_, be already patched?

Yes you are right, the
"if [ ! -f "${CT_SYSROOT_DIR}/${d}/${l}.so_ori_i" ]; then"  ...
can be removed.

> 
>>>> +
> 
>>>> +        CT_DoLog EXTRA "Prepare C library"
>>>> +        CT_DoExecLog ALL make ${JOBSFLAGS}                      \
>>>> +                              "${extra_make_args[@]}"           \
>>>> +                              clean
>>>
>>> Why do you need to clean here?
>>> The build dir should be brand new, as we just mkdir it a few lines above.
>>> In any way, do not reuse any existing dir.
>>
>> I remember that it didnt proceed compiling without it when using the
>> "RESTART, STOP" option, maybe it can be removed, on the other hand it
>> doesnt hurt.
> 
> OK. But I would prefer to really understand why it breaks, so we get to
> fix it rather than have a workaround...
> 

I tried again with the "clean" rule removed. I built the whole chain
and also did a "RESTART=libc STOP=libc" and it still built. So again:
You are right and the "clean" rule can be removed.


>>> We need to find a place where to put that option, but I think the gcc
>>> sub-menu is not the proper place.
>>
>> I didnt add this to the patchset this time. I think you have
>> to decide where to place CC_MULTILIB ...
>>
>>> Multi-lib is a property of the toolchain, that is implemented by many
>>> components, and gcc is only one of those. binutils also plays a role in
>>> multilib.
>>>
>>> So, it makes more sense to put the option in a more global sub-menu, such
>>> as in the toolchain options sub-menu.
> 
> And here I said where to put it. ;-)
> 
> Thanks for the efforts you are putting in that feature. It's much
> appreciated!
> 
> As I said above (it was about 1h ago for me!), I'll review the new patch
> tomorrow.
> 
> Going to sleep for now... (eyes, stay open for a few more minutes, please)...

:-)

> 
> Regards,
> Yann E. MORIN.
> 


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