simple multilib option
Konrad Eisele
konrad@gaisler.com
Tue Nov 15 10:32:00 GMT 2011
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
More information about the crossgcc
mailing list