Re: ct-ng 1.8.2 how to select gcc 4.5.x ?

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Samson, Bryan, All,

On Friday 08 October 2010 14:46:12 Bryan Hundven wrote:
> On Thu, Oct 7, 2010 at 10:38 PM, Samson Luk <samsonluk@gmail.com> wrote:
> >> This is a known issue. glibc does not build with 'fortify'.
> >> Please try setting:
> >> ÂC-library Â--->
> >> Â(-U_FORTIFY_SOURCE) Âextra target CFLAGS
> > I suppose this also apply to eglibc?
> Yes.

Indeed.

> > I also found symlinks with "double slash" in path like below in the
> > target tree, are they normal, why is that using "double slash"?
> > lrwxrwxrwx 1 root root  23 2010-10-07 20:38 include -> .//sys-root/usr/include
> > lrwxrwxrwx 1 root root  15 2010-10-07 20:38 lib -> .//sys-root/lib

These symlinks are here to force gcc to put its headers and libs in the
sysroot. The fact that it searches this path is not really shocking, after
all. It was working with older versions, but it seems 4.5.x has somehow
been 'fixed', and is now exhibiting the issue. :-/

> > drwxr-xr-x 4 root root 4096 2010-10-07 20:38 sys-root
> This is ok.
[--SNIp--]
> Which I think is only needed for cross-canadian toolchains.

Nope, it's not. You can set it as well for simpe cross ctoolchains.
This allows to share both the sys-root and the debug-root without
also exporting binaries internal to gcc/binutils.

Look at what directories you have just side-by-side to the sys-root.

> > Beside, why is that required to generate two levels of
> > "arm-none-linux-gnueabi", can I eliminate one level or there are
> > special purposes for setup like this?

The two-level diretory structure is IMHO the correct way to do lay things.

The top-level directory can be named whatever you want. It is the place
where crosstool-NG wil install the toolchain. The default is to include
the target tuple, but this is not compulsory. Be aware, though, that
crostool-NG will forcibly remove the installation directory. So using
the tuple to name the installation directory is a good way not to remove
anything else.

I am not sure how gcc et al. would behave should the second-level
directory be named without the tuple. I am afraid it might break in
horrible ways in some corner cases, so I better be safe than sorry.

It works this way, I'm fine with it. If any one comes with an alternate
naming scheme that he can justify is working, I'm all for making a config
knob for this.

> > When a 'ct-ng build' aborted and configuration adjusted / problem
> > fixed, is it safe to simple 'ct-ng build' again or should I resume
> > from the exact failed step?

As said earlier, you have to restart from scratch if you change the
configuration. If you change a build script, you can restart from
the failing step.

> > Is there easy way to figure out which is 
> > the current step or have to dig through the build log?

Yes, the previous failing message will tell you something like:
    Build failed in step 'XXXX'

> But, you can enable CT_DEBUG_CT and CT_DEBUG_CT_SAVE_STEPS, and you
> should be able to restart at a step that failed. You have to restart
> your build with 'ct-ng clean; ct-ng build' before you can use the
> saved steps. If libc breaks again, and you somehow fix your issue, you
> can try:
> ct-ng RESTART=libc

Or more conveniently:
  ct-ng libc+   --> restart from step 'libc', continues onward
  ct-ng libc    --> restart from step 'libc', stops just after it
  ct-ng +libc   --> start from the begining, stops just before step 'libc'

See the docs! ;-)

> There is lots of great documentation in crosstool-ng/docs. A lot of
> what I know about crosstool-ng comes from these documents, and reading
> the scripts.

Thanks! ;-)

The documentation is suffering from these deficiencies, nonetheless:
- parts of the process is still undocumented;
- parts of the process is partially and/or poorly documented, or the doc
  is not up-to-date;
- I have made a lot of assumptions when writing the doc, and some stuff
  that seems obvious to me I simply left out.

I believe that installing and running crosstool-NG is properly documented,
but the docs for the internals is definitely in need of some love.
Any ine? ;-]

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