Canadian build and CT_TARGET fails

[Yann E. MORIN]

Per-Arnold, All,

On Friday 03 August 2012 08:37:56 Per Arnold Blaasmo wrote:
> Here is the patch I made yesterday to get to build to work with the
> attached config file.

OK, I ran your .config without the patch against the current repository,
and the core pass-1 and core pass-2 compilers built fine.

There was still an error in the final gcc that I'm ironing out. See my
comment about the C library, below.

> It is Building a toolchain for:
>       build  = x86_64-unknown-linux-gnu
>       host   = i686-pc-mingw32
>       target = arm-none-eabi
> with MULTILIB enabled.
> 
> Please see trough it and see if it is OK.
> I have not tested it on other configs yet.
> 
> I will do some more testing today.
> 
> NB! this patch do not include the last changes you did yesterday (3
> commits I think).

OK, not your fault, but this is too late for the current release, which is
now 3 days late. I'll cut the release tonight without this change.

As for the patch content:

 - I think the comments in gcc.sh are either wrong, or the code is incorrect:
   the core gcc are always built for build, not for host. In retrospect, I
   believe the comments are right, but the tests are wrong; they might work,
   but they are not testing what they should: one can not decide that
   $host == $CT_BUILD implies the core compiler; $host == $CT_BUILD is a
   _consequence_ of the core compiler.
   "A implies B", where 'A' is 'core compiler', and B is '$host == $CT_BUILD'
   does not mean tht "B implies A".

   Which means that we need to pass an option to the core backend stating
   that we actually build a core or a final compiler.

 - the "system zlib" option is here for a reason, and the comment you added
   is right: if you want to use the "system zlib", it should be built and
   installed for the host prior to build ing the canadian toolchain. If zlib
   is not present on the host, then do not choose to use the system zlib.

 - the libc_for_{host,build} looks dubious. After all, the C library that
   runs on the target is exactly the same, whether the compiler runs on
   build or on host.
   I think that the correct fix would be to build the C library before
   cc_for_build (move step 'libc' one-up). The cc_for_build already uses
   the same sysroot as the final gcc. That way, we build the C library
   only once, but install it twice.

 - the patch is space/tab mangled. In crosstool-NG, we do not use tabs, and
   we use a 4-space wide indentation.

I also have a few comments on submitting that patch:

 - please rebase your patch onto the current repository tip
 - split the patch into self-contained, semantically separated patches
 - do not forget to SoB your patches
 - send a proper Hg patchset (eg. using the patchbomb extension)
 - send mails with in-body patches, they are easier to review and comment
   upon.

(there is a nice step-by-step procedure in "docs/ C - Misc. tutorials.txt"
 section "Using Mercurial to hack crosstool-NG")

Thank you for raising all these issues, and digging in! ;-)

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