[crosstool-ng] Open discussion on binutils and gcc configuration options.

Yann E. MORIN yann.morin.1998@anciens.enib.fr
Fri Jul 1 20:40:00 GMT 2011

Bryan, Rainer, All,

On Friday 01 July 2011 20:03:07 Bryan Hundven wrote:
> So to start; this is spawned from my lack of better understanding of the inter-
> workings of gcc and binutils and how they are affected by the configuration
> options passed to them during the bootstrap procedure.
> As I just learned, --enable-symvars manually was something (maybe) needed by

IIRC, that was --enable-symvers=gnu (not symv_a_r).

> sh4 at one point, and worked for other architectures... maybe by mistake or
> luck, but was probably not correct.

It dates back to some gcc-3.2 that needed this option for sh4.

> My personal views on the configuration and make procedures up until now has
> been:
>   "If it ain't broke, don't fix it."

Ditto. crosstool-NG was built upon the original crosstool by Dan KEGEL.
As such, it inherited al the good, but also all the bad: fixes and
workarounds, but also kludges and mistakes. That they survived so far is
due to many factors:
- it does not break, thus it isn't fixed
- I have no ultimate and absolute knowledge about all obscur (or even
  non-obscur) options, not only for gcc, but also binutils, glibc...
  (uClibc is pretty OK for me, as is the kernel)
- people did not complain so far.

> But if enabling symvars manual is wrong,

'symvers' ;-)

> what else are we doing wrong?

As per your saying (to which I adhere), pretty nothing:
  If it ain't broke, don't fix it.

OTOH, a whole good deal of options we pass to gcc's ./configure we need.
Here's a quick (incomplete) summary:
- build, host and target
- prefix and sysroot (and local-prefix)
- companion libs (ppl, gmp...) location
- libstdc++ link flags (we use static companion libs)
- languages
- floats impl (HW/SW) and type (VFP/...) when meaningful
- enabled/disabled libs (ssp/gomp/...)
- threads (y/n)
- c99 (I never ever tested without it...)
- no NLS (I never ever needed localisation for my compilers!)
- disabling multi-lib (we do not (yet?) support that)
- enabling (the now infamous) symvers=gnu
- long-long
- optimise target libs for size (y/n)
- use of sjlj (y/n/auto)
- 128-bit long doubls (y/n/auto)
- use of __cxa_atexit
- pkgversion and bugurl strings
- enable-cxx-flags
- enable gold and plugins support, depending on binutils

Some of them are always passed (build, target, c99...), some are
user-configurable either by value (eg. pkgversion, languages) or by
en/disabling them (eg. sjlj, 128-bit long doubles...), and others are
conditional (eg. support for plugins, gold).

There is one point I would like to emphasise: crosstool-NG aims at
building toolchains that are 100% reproducible.

To achieve this goal, we might be passing more options than strictly
required, but this way we are sure that the toolchain will be doing what
we requested, and that the behavior does not depend on the phase of the

I am merely saying that, by passing all those options, if a requirement
is not met, then the build will break, rather than default to anything
we did not want.

The above emphasis applies when building every components that make up
the toolchain, not only to gcc: binutils, glibc/uClibc/eglibc, gmp/ppl/...

> At anyrate, the source can be browsed here:
>   http://crosstool-ng.org/hg/crosstool-ng/summary
> and you can check it out using mercurial:
>   hg clone http://crosstool-ng.org/hg/crosstool-ng crosstool-ng

And here is a quick tutorial:
  cd crosstool-ng
  ./configure --local
  ./ct-ng menuconfig

The gcc build script is there:

Thank you for putting up with me! ;-)

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

More information about the crossgcc mailing list