This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: feature request: Include ncurses, openssl


Arnaud, All,

On Wednesday 30 June 2010 23:37:59 Arnaud Lacombe wrote:
> My comment's worth what it's worth, but openssl has no relation
> whatsoever with a toolchain, ie. a bunch of software tied together to
> build code from architecture X to Y... ncurses' alike.

Fully agreed. Except for ncurses that is required to build the native gdb,
see my answer to Ben.

> This concerns 
> also *_target steps in ct-ng. Speaking about these steps, they're
> funny, as you can't build a full compiler for the target... Of course
> all that only reflects my own opinion.

Well... I know. On one side, once gcc is working, then that's the end of
the day for crostool-NG. But here's my reasoning to add the debug stuff:

- having a cross gdb with its gdbserver built as part of the toolchain
  is really convenient.
- then, as we build gdbserver, why not also build a native gdb for the
  target? That comes handy at times.
- dmalloc and DUMA are libs used to help find memory issues. They're
  pretty standard, and easy to build. Having them in the toolchain's
  sysroot means every stuff you cross-compile can easily be built using
  those libs without extra configure option.
- ltrace and strace are quite standard as well to help debugging, and
  really easy to build. Also, they have to be configured to interpret
  the target format, so they fit well in the debug section as well.

That's for the debug section. Now here's the explanation for the *_target
steps:

- gmp_target and mpfr_target: gdb can be built using GMP and MPFR (I do
  not know what for, but it can, and it is supposed to enable some advanced
  stuff). So I build them, and have the target gdb use them. Also binutils
  can use them (see below).

- binutils_target: some libs from binutils are required to run oprofile
  on the target, and (to my knowledge, but I can be wrong) have to be the
  same libs as the ones used at link time. So we build those binutils libs
  for the target.

Now, there's a new feature in the current tree. The backend-mode will hide
all those stuff from sight. Backend-mode is suposed to make it easy for
a build-system (such as buildroot) to use crosstool-NG, masking some options
and forcing others. See docs/overview.txt for how backend-mode works.

Well, that's pretty all, I think... Whaoo... Long explanations recently.
I definitely have to gather that in an homogeneous form and put it in the
doc. Thank you for making me write that! :-)

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]