Building a static toolchain ?

Building a static toolchain ?

[M P]

Is it possible to make a toolchain independant from the host libc ? ie
compiled with --static or something ..

Michael

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Yann E. MORIN]

Michael, All,

On Tuesday 23 March 2010 18:46:36 M P wrote:
> Is it possible to make a toolchain independant from the host libc ? ie
> compiled with --static or something ..

Yes it is possible.
No, crosstool-NG does not (yet?) support that. Sorry.

You could have a look at Firmware Linux ( http://impactlinux.com/fwl/ )
and see how they handle that. If you have a litle time to tackle this into
crosstool-NG, I'd gladly accept a patch! ;-)

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

Re: Building a static toolchain ?

[Josh Henderson]

You can give the patch at http://www.digitalpeer.com/pub/patches a
try.  I have yet to get around to Yann's comments on it.  Look in the
mailing list archives for more.

On 3/24/10, Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote:
> Michael, All,
>
> On Tuesday 23 March 2010 18:46:36 M P wrote:
>> Is it possible to make a toolchain independant from the host libc ? ie
>> compiled with --static or something ..
>
> Yes it is possible.
> No, crosstool-NG does not (yet?) support that. Sorry.
>
> You could have a look at Firmware Linux ( http://impactlinux.com/fwl/ )
> and see how they handle that. If you have a litle time to tackle this into
> crosstool-NG, I'd gladly accept a patch! ;-)
>
> 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
>
>

-- 
Sent from my mobile device

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Yann E. MORIN]

Josh, Michael, All,

On Wednesday 24 March 2010 21:04:37 Josh Henderson wrote:
> You can give the patch at http://www.digitalpeer.com/pub/patches a
> try.  I have yet to get around to Yann's comments on it.  Look in the
> mailing list archives for more.

Yeah, I remember.

Overall your patch was good. There are a few points I really want to get
fixed before inclusion:

1) do not build our own static zlib, use the distro's packaged one.

2) make the companion libraries build statically. I got burned twice, and
   bailed out. Start there: http://gcc.gnu.org/install/configure.html
   and look for --with-host-libstdcxx=

3) The rest was trivial eye-candy.

Also, forget about Firmware Linux, they're still using a pre-GPLv3 gcc which
IIRC wass 4.2.1, which means it does not need/use the companion libraries
that are now required with gcc-4.3 and 4.4.

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

Re: Building a static toolchain ?

[Trevor Woerner]

Just out of curiosity... I keep thinking about this question off and
on and I just can't figure out what the advantage would be to having a
toolchain that doesn't use the build host's language libraries. So it
can be copied to and run from another machine (one which may be using
a different version of, say, glibc)?

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Dimitry Andric]

On 2010-03-31 22:37, Trevor Woerner wrote:
> Just out of curiosity... I keep thinking about this question off and
> on and I just can't figure out what the advantage would be to having a
> toolchain that doesn't use the build host's language libraries. So it
> can be copied to and run from another machine (one which may be using
> a different version of, say, glibc)?

Usually that is the goal, yes.  Note the following fine points, however:

- glibc is always compiled with a 'minimum supported kernel version',
so even if you link your application statically with it, that does not
guarantee that the application runs on any lower kernel version.

- newer glibc versions are always compatible with older glibc versions
(on the same architecture, of course), but not the other way around.

So linking all toolchain executables completely static is really a tiny
bit overkill. :)  It is mostly enough to:

- build your toolchain on an "oldish" Linux distro (at least, one with
an oldish version of glibc), such as Debian Stable or Red Hat 5, or even
4, if you really want to go for lowest common denominator.

- make sure any extra dependencies, usually libgmp and/or libmpfr,
*are* statically linked into the toolchain executables, since not
everybody will have those as .so files on their system, or may have
different, incompatible versions.

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Trevor Woerner]

Okay, thanks so much for the information!

Just out of curiosity:

1. Since newer glibc's are compatible with older glibc's (but not the
other way around) is it not possible to take the latest glibc and
lower the 'minimum supported kernel version'?

2. If you have built your toolchain statically linked to an older
glibc then wouldn't it would mean you couldn't compile programs which
use newer system calls (e.g. futex, inotify)?

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Josh Henderson]

I can add a few more comments. In my case I have a variety of distros
that have incompatible glibc versions. To lessen the burden of
maintaining multiple toolchain builds, a single static gcc gets the
job done. However, be aware that gcc RAM usage is considerably higher
when compiling.

On 3/31/10, Trevor Woerner <twoerner@gmail.com> wrote:
> Okay, thanks so much for the information!
>
> Just out of curiosity:
>
> 1. Since newer glibc's are compatible with older glibc's (but not the
> other way around) is it not possible to take the latest glibc and
> lower the 'minimum supported kernel version'?
>
> 2. If you have built your toolchain statically linked to an older
> glibc then wouldn't it would mean you couldn't compile programs which
> use newer system calls (e.g. futex, inotify)?
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>
>

-- 
Sent from my mobile device

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Khem Raj]

On Wed, Mar 31, 2010 at 2:08 PM, Trevor Woerner <twoerner@gmail.com> wrote:
> Okay, thanks so much for the information!
>
> Just out of curiosity:
>
> 1. Since newer glibc's are compatible with older glibc's (but not the
> other way around) is it not possible to take the latest glibc and
> lower the 'minimum supported kernel version'?

in addition to system calls. there could be other symbols which are
not present in older libc

>
> 2. If you have built your toolchain statically linked to an older
> glibc then wouldn't it would mean you couldn't compile programs which
> use newer system calls (e.g. futex, inotify)?

you have to understand that the toolchain components themselves need a
libc when they run. Its not same as the target libc that you
would use to link the programs that will be generated by your
statically linked cross compiler.

>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Trevor Woerner]

On Wed, Mar 31, 2010 at 5:22 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> 2. If you have built your toolchain statically linked to an older
>> glibc then wouldn't it would mean you couldn't compile programs which
>> use newer system calls (e.g. futex, inotify)?
>
> you have to understand that the toolchain components themselves need a
> libc when they run. Its not same as the target libc that you
> would use to link the programs that will be generated by your
> statically linked cross compiler.

D'oh! Of course, thanks :-D

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Yann E. MORIN]

Trevor, Dimitry, All,

On Wednesday 31 March 2010 22:50:24 Dimitry Andric wrote:
> On 2010-03-31 22:37, Trevor Woerner wrote:
> > Just out of curiosity... I keep thinking about this question off and
> > on and I just can't figure out what the advantage would be to having a
> > toolchain that doesn't use the build host's language libraries. So it
> > can be copied to and run from another machine (one which may be using
> > a different version of, say, glibc)?
> - glibc is always compiled with a 'minimum supported kernel version',
> so even if you link your application statically with it, that does not
> guarantee that the application runs on any lower kernel version.
> 
> - newer glibc versions are always compatible with older glibc versions
> (on the same architecture, of course), but not the other way around.

That, plus:

- glibc has issues with NSS (Name Service Switch) when compiled statically.
  Although I don't see why a toolchain would need to resolve host or user
  names... Nice to keep in mind whenever building statically with glibc.

> So linking all toolchain executables completely static is really a tiny
> bit overkill. :)  It is mostly enough to:

I would tend to agree with you, Dimitry. But, think about this hypotetical
situation (which I do *not* condone):

- responsible for build tools, you build updated toolchains for you team,
  and make those available to all your developpers;

- you have a fast, very recent multi-core machine, so you can easily
  experiment with new toolchains, and build them *fast*; most probably,
  being a recent machine, you installed the latest (stable?) version of
  your favourite distro (Debian/Udbuntu/Fedora/...)

- OTOH, your developpers have lower-end machines, that date a few years
  back, if not more (I know some situations where this is the case, up
  to 6 year-old machines), that have not been updated, out of lazyness,
  or just because "It Works (TM)";

- so if you give them your shared-linked toolchain, Kaboom! it breaks on
  their machines...

> - build your toolchain on an "oldish" Linux distro (at least, one with
> an oldish version of glibc), such as Debian Stable or Red Hat 5, or even
> 4, if you really want to go for lowest common denominator.

Or you can do that, of course! :-) Anyone has an yggdrasil handy?

> - make sure any extra dependencies, usually libgmp and/or libmpfr,
> *are* statically linked into the toolchain executables, since not
> everybody will have those as .so files on their system, or may have
> different, incompatible versions.

Yes, and those *I* was not able to properly build statically (yet!)... :-(

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

Re: Building a static toolchain ?

[Yann E. MORIN]

On Wednesday 31 March 2010 23:08:36 Trevor Woerner wrote:
> 
> Okay, thanks so much for the information!
> 
> Just out of curiosity:
> 
> 1. Since newer glibc's are compatible with older glibc's (but not the
> other way around) is it not possible to take the latest glibc and
> lower the 'minimum supported kernel version'?

Woohoo... Stop!
We're speaking of building the toolchain components statically!
That is: gcc and binutils, period. (yes, and gdb if you want).

The glibc that is built with the toolchain is not what we are speaking
about! And this is this glibc that has a 'minimum supported kernel
version'.

But I have to agree that it gets messy to speak about this stuff! ;-)

> 2. If you have built your toolchain statically linked to an older
> glibc then wouldn't it would mean you couldn't compile programs which
> use newer system calls (e.g. futex, inotify)?

See above, irrelevant, we're speaking a bout the *host* C library, not
the target's C library.

Hope this makes it clear. :-) (BTW, I just saw Khem answered the same).

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

Re: Building a static toolchain ?

[Dimitry Andric]

[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]

On 2010-03-31 23:25, Yann E. MORIN wrote:
>> - make sure any extra dependencies, usually libgmp and/or libmpfr,
>> *are* statically linked into the toolchain executables, since not
>> everybody will have those as .so files on their system, or may have
>> different, incompatible versions.
>
> Yes, and those *I* was not able to properly build statically (yet!)... :-(

For that, I use something like the attached patch, which should apply
cleanly to gcc 4.3.3, but most likely also to later versions.

After building the toolchain, you can check out the dependencies with
ldd, for example:

$ ldd $TOOLCHAIN_ROOT/libexec/gcc/$TARGET_TRIPLET/4.3.3/cc1
          linux-gate.so.1 =>  (0x00a5b000)
          libc.so.6 => /lib/libc.so.6 (0x00110000)
          /lib/ld-linux.so.2 (0x00996000)

So it only links dynamically with glibc, while it contains gmp and mpfr
statically:

$ strings $TOOLCHAIN_ROOT/libexec/gcc/$TARGET_TRIPLET/4.3.3/cc1|grep -E "gmp|mpfr"
real_from_mpfr
mpfr_from_real
|*p+>(__builtin_constant_p (1) && (1) == 0 ? (((S)->_mpfr_exp == ((mp_exp_t)((~((~(unsigned long)0)>>1))+1))) ? 0 : ((S)->_mpfr_sign)) : mpfr_cmp_ui_2exp ((S),(1),0)) < 0
!(((t)->_mpfr_exp) == (((-2147483647L - 1L))+2))
prec >= 2 && prec <= ((mpfr_prec_t)((mpfr_prec_t)(~(mpfr_prec_t)0)>>1))
p >= 2 && p <= ((mpfr_prec_t)((mpfr_prec_t)(~(mpfr_prec_t)0)>>1))
(((k)->_mpfr_exp) == ((((long) ((~ (unsigned long) 0) ^ ((unsigned long) (~ (unsigned long) 0) >> 1))))+1)) || ((k)->_mpfr_exp) <= 2
(!(((r)->_mpfr_exp) == ((((long) ((~ (unsigned long) 0) ^ ((unsigned long) (~ (unsigned long) 0) >> 1))))+2)) && !(((r)->_mpfr_exp) == ((((long) ((~ (unsigned long) 0) ^ ((unsigned long) (~ (unsigned long) 0) >> 1))))+3)))
(((cache->x)->_mpfr_sign) > 0)
! (un < pn || (un == pn && __gmpn_cmp (up, pp, pn) < 0))


[-- Attachment #2: gcc-4.3.3-static-gmp-mpfr.diff --]
[-- Type: text/plain, Size: 617 bytes --]

diff -ur a/configure.ac b/configure.ac
--- a/configure.ac	2008-02-02 04:29:30.000000000 +0100
+++ b/configure.ac	2010-04-01 11:18:19.000000000 +0200
@@ -1139,7 +1139,7 @@
 ACX_PROG_CMP_IGNORE_INITIAL
 
 # Check for GMP and MPFR
-gmplibs="-lmpfr -lgmp"
+gmplibs="-Wl,-Bstatic -lmpfr -lgmp -Wl,-Bdynamic"
 gmpinc=
 have_gmp=no
 
diff -ur a/configure b/configure
--- a/configure	2008-02-02 04:29:30.000000000 +0100
+++ b/configure	2010-04-01 11:18:19.000000000 +0200
@@ -4368,7 +4368,7 @@
 
 
 # Check for GMP and MPFR
-gmplibs="-lmpfr -lgmp"
+gmplibs="-Wl,-Bstatic -lmpfr -lgmp -Wl,-Bdynamic"
 gmpinc=
 have_gmp=no
 



[-- Attachment #3: Type: text/plain, Size: 71 bytes --]

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Khem Raj]

On (01/04/10 11:43), Dimitry Andric wrote:
> On 2010-03-31 23:25, Yann E. MORIN wrote:
> >>- make sure any extra dependencies, usually libgmp and/or libmpfr,
> >>*are* statically linked into the toolchain executables, since not
> >>everybody will have those as .so files on their system, or may have
> >>different, incompatible versions.
> >
> >Yes, and those *I* was not able to properly build statically (yet!)... :-(
> 
> For that, I use something like the attached patch, which should apply
> cleanly to gcc 4.3.3, but most likely also to later versions.
> 
> After building the toolchain, you can check out the dependencies with
> ldd, for example:
> 
> $ ldd $TOOLCHAIN_ROOT/libexec/gcc/$TARGET_TRIPLET/4.3.3/cc1
>          linux-gate.so.1 =>  (0x00a5b000)
>          libc.so.6 => /lib/libc.so.6 (0x00110000)
>          /lib/ld-linux.so.2 (0x00996000)
> 
> So it only links dynamically with glibc, while it contains gmp and mpfr
> statically:
> 
> $ strings $TOOLCHAIN_ROOT/libexec/gcc/$TARGET_TRIPLET/4.3.3/cc1|grep -E "gmp|mpfr"
> real_from_mpfr
> mpfr_from_real
> |*p+>(__builtin_constant_p (1) && (1) == 0 ? (((S)->_mpfr_exp == ((mp_exp_t)((~((~(unsigned long)0)>>1))+1))) ? 0 : ((S)->_mpfr_sign)) : mpfr_cmp_ui_2exp ((S),(1),0)) < 0
> !(((t)->_mpfr_exp) == (((-2147483647L - 1L))+2))
> prec >= 2 && prec <= ((mpfr_prec_t)((mpfr_prec_t)(~(mpfr_prec_t)0)>>1))
> p >= 2 && p <= ((mpfr_prec_t)((mpfr_prec_t)(~(mpfr_prec_t)0)>>1))
> (((k)->_mpfr_exp) == ((((long) ((~ (unsigned long) 0) ^ ((unsigned long) (~ (unsigned long) 0) >> 1))))+1)) || ((k)->_mpfr_exp) <= 2
> (!(((r)->_mpfr_exp) == ((((long) ((~ (unsigned long) 0) ^ ((unsigned long) (~ (unsigned long) 0) >> 1))))+2)) && !(((r)->_mpfr_exp) == ((((long) ((~ (unsigned long) 0) ^ ((unsigned long) (~ (unsigned long) 0) >> 1))))+3)))
> (((cache->x)->_mpfr_sign) > 0)
> ! (un < pn || (un == pn && __gmpn_cmp (up, pp, pn) < 0))
> 

> diff -ur a/configure.ac b/configure.ac
> --- a/configure.ac	2008-02-02 04:29:30.000000000 +0100
> +++ b/configure.ac	2010-04-01 11:18:19.000000000 +0200
> @@ -1139,7 +1139,7 @@
>  ACX_PROG_CMP_IGNORE_INITIAL
>  
>  # Check for GMP and MPFR
> -gmplibs="-lmpfr -lgmp"
> +gmplibs="-Wl,-Bstatic -lmpfr -lgmp -Wl,-Bdynamic"
>  gmpinc=
>  have_gmp=no
>  
> diff -ur a/configure b/configure
> --- a/configure	2008-02-02 04:29:30.000000000 +0100
> +++ b/configure	2010-04-01 11:18:19.000000000 +0200
> @@ -4368,7 +4368,7 @@
>  
>  
>  # Check for GMP and MPFR
> -gmplibs="-lmpfr -lgmp"
> +gmplibs="-Wl,-Bstatic -lmpfr -lgmp -Wl,-Bdynamic"
>  gmpinc=
>  have_gmp=no
>  
> 
> 

you could add symlinks to gmp and mpfr sources on top of gcc tree
and then it should link them statically you would not need this patch.

> --
> For unsubscribe information see http://sourceware.org/lists.html#faq


--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Marc Kleine-Budde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dimitry Andric wrote:
> On 2010-03-31 23:25, Yann E. MORIN wrote:
>>> - make sure any extra dependencies, usually libgmp and/or libmpfr,
>>> *are* statically linked into the toolchain executables, since not
>>> everybody will have those as .so files on their system, or may have
>>> different, incompatible versions.
>>
>> Yes, and those *I* was not able to properly build statically (yet!)...
>> :-(
> 
> For that, I use something like the attached patch, which should apply
> cleanly to gcc 4.3.3, but most likely also to later versions.

Why bother to patch gcc. Just ./configure the mpfr and friends with
"--enable-static --disable-shared". Works like charm here.

cheers, Marc

- --
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAku07lwACgkQjTAFq1RaXHOvWQCeMrYqkCq2gW8FSLjNKL+0/4H3
InYAoIyWZczXk/vhdvjj4xPNMXhiMem1
=fjrA
-----END PGP SIGNATURE-----

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Dimitry Andric]

On 2010-04-01 21:05, Marc Kleine-Budde wrote:
> Why bother to patch gcc. Just ./configure the mpfr and friends with
> "--enable-static --disable-shared". Works like charm here.

This was when I wanted to use the system versions of gmp and mpfr at
that time... :)

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Yann E. MORIN]

Arnaud, All,

On Saturday 10 April 2010 19:28:16 Yann E. MORIN wrote:
> On Saturday 10 April 2010 19:20:29 Yann E. MORIN wrote:
> > What I thought. But cloog is built with:
> >  --with-host-libstdcxx='-Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
> > I have tried to manually link the sucker, but to no avail. I have to
> > understand why on earth libtool passes the above link flags *before* the
> > other libs. It must be *after*, or the libstdc++ will not be parsed for
> > required symbols.
> Yes, that was the issue. Passing -Wl,-Bstatic,blabla after all the other
> libraries fixes it.
> Sigh. I hate libtool. Period.

OK, that's because libtool reoders the arguments list, so that all libraries
( args staring with -l ) comes after all library paths ( args starting with
-L ). And it does so by moving all non -l arguments to the beginning of the
list, and all -l arguments at the end of the list.

Unfortunately, -Wl,-Bstatic,-lstdc++,-Bdynamic does not start with -l, so
it is moved before all -l args, and thus libstdc++ is scanned before any of
its members is needed, so it does not get linked.

Sigh.

Passing LDFLAGS=-lstdc++ seems to be enough, though.

> Forget about it, I now have a hammer, and a nail to... nail.

Done. We might be able to get rid of the wrapper very shortly, I hope.

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

Re: Building a static toolchain ?

[Yann E. MORIN]

Arnaud, All,

On Saturday 10 April 2010 19:20:29 Yann E. MORIN wrote:
> What I thought. But cloog is built with:
>  --with-host-libstdcxx='-Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
> I have tried to manually link the sucker, but to no avail. I have to
> understand why on earth libtool passes the above link flags *before* the
> other libs. It must be *after*, or the libstdc++ will not be parsed for
> required symbols.

Yes, that was the issue. Passing -Wl,-Bstatic,blabla after all the other
libraries fixes it.

Sigh. I hate libtool. Period.

> > What is your .config btw ?

Forget about it, I now have a hammer, and a nail to... nail.

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

Re: Building a static toolchain ?

[Yann E. MORIN]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

Arnaud, All,

On Saturday 10 April 2010 19:10:41 Arnaud Lacombe wrote:
> On Sat, Apr 10, 2010 at 6:50 AM, Yann E. MORIN
> <yann.morin.1998@anciens.enib.fr> wrote:
> > Does not work for me:
> >
> > [ALL  ]    libtool: link: x86_64-build_pc-linux-gnu-gcc -Wall -fomit-frame-pointer -pipe -o cloog cloog.o  -L/home/ymorin/x-tools/armeb-unknown-linux-u
> > [ALL  ]    /home/ymorin/x-tools/armeb-unknown-linux-uclibcgnueabi/lib/libppl_c.a(ppl_c_implementation_common.o): In function `ppl_delete_Grid_Generator
> > [ALL  ]    ppl_c_implementation_common.cc:(.text+0x41a): undefined reference to `operator delete(void*)'
> > And many, many more errors related to C++ symbols...
> d'oh... certainly a missing -lstd++ ${somewhere},

What I thought. But cloog is built with:
 --with-host-libstdcxx='-Wl,-Bstatic,-lstdc++,-Bdynamic -lm'

I have tried to manually link the sucker, but to no avail. I have to
understand why on earth libtool passes the above link flags *before* the
other libs. It must be *after*, or the libstdc++ will not be parsed for
required symbols.

> let me come back to 
> you with something cleaner. What is your .config btw ?

Attached. Makes me feel strange, as for the first time, someone is asking
*me* my .config to help me. Hehe! :-)

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.  |
'------------------------------^-------^------------------^--------------------'

[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 8349 bytes --]

#
# Automatically generated make config: don't edit
# crosstool-NG version: hg_default@1889_534bcaaaecd0
# Sat Apr 10 12:38:10 2010
#
# CT_BACKEND is not set

#
# Paths and misc options
#

#
# crosstool-NG behavior
#
# CT_OBSOLETE is not set
# CT_EXPERIMENTAL is not set
# CT_DEBUG_CT is not set

#
# Paths
#
CT_LOCAL_TARBALLS_DIR="${HOME}/src"
CT_SAVE_TARBALLS=y
CT_WORK_DIR="${CT_TOP_DIR}/targets"
CT_PREFIX_DIR="${HOME}/x-tools/${CT_TARGET}"
CT_INSTALL_DIR="${CT_PREFIX_DIR}"
CT_REMOVE_DOCS=y
CT_INSTALL_DIR_RO=y

#
# Downloading
#
# CT_FORBID_DOWNLOAD is not set
# CT_FORCE_DOWNLOAD is not set
CT_USE_MIRROR=y
# CT_PREFER_MIRROR is not set
CT_MIRROR_BASE_URL="http://ymorin.is-a-geek.org/mirrors/"
CT_CONNECT_TIMEOUT=10
CT_DOWNLOAD_MAX_CHUNKS=5
# CT_ONLY_DOWNLOAD is not set

#
# Extracting
#
# CT_FORCE_EXTRACT is not set
CT_OVERIDE_CONFIG_GUESS_SUB=y
# CT_ONLY_EXTRACT is not set
CT_PATCH_BUNDLED=y
# CT_PATCH_LOCAL is not set
# CT_PATCH_BUNDLED_LOCAL is not set
# CT_PATCH_LOCAL_BUNDLED is not set
# CT_PATCH_BUNDLED_FALLBACK_LOCAL is not set
# CT_PATCH_LOCAL_FALLBACK_BUNDLED is not set
# CT_PATCH_NONE is not set
CT_PATCH_ORDER="bundled"
# CT_PATCH_SINGLE is not set
# CT_PATCH_USE_LOCAL is not set

#
# Build behavior
#
CT_PARALLEL_JOBS=1
CT_LOAD=0
CT_USE_PIPES=y
# CT_CONFIG_SHELL_SH is not set
# CT_CONFIG_SHELL_ASH is not set
CT_CONFIG_SHELL_BASH=y
# CT_CONFIG_SHELL_CUSTOM is not set
CT_CONFIG_SHELL="bash"

#
# Logging
#
# CT_LOG_ERROR is not set
# CT_LOG_WARN is not set
# CT_LOG_INFO is not set
CT_LOG_EXTRA=y
# CT_LOG_ALL is not set
# CT_LOG_DEBUG is not set
CT_LOG_LEVEL_MAX="EXTRA"
# CT_LOG_SEE_TOOLS_WARN is not set
CT_LOG_PROGRESS_BAR=y
CT_LOG_TO_FILE=y
CT_LOG_FILE_COMPRESS=y

#
# Target options
#
CT_ARCH="arm"
CT_ARCH_SUPPORTS_BOTH_MMU=y
CT_ARCH_SUPPORTS_BOTH_ENDIAN=y
CT_ARCH_SUPPORTS_32=y
# CT_ARCH_SUPPORTS_64 is not set
CT_ARCH_SUPPORT_ARCH=y
# CT_ARCH_SUPPORT_ABI is not set
CT_ARCH_SUPPORT_CPU=y
CT_ARCH_SUPPORT_TUNE=y
CT_ARCH_SUPPORT_FPU=y
CT_ARCH_DEFAULT_HAS_MMU=y
# CT_ARCH_DEFAULT_BE is not set
CT_ARCH_DEFAULT_LE=y
CT_ARCH_DEFAULT_32=y
# CT_ARCH_DEFAULT_64 is not set
CT_ARCH_ARCH="armv5te"
CT_ARCH_CPU="xscale"
CT_ARCH_TUNE="xscale"
CT_ARCH_FPU=""
CT_ARCH_BE=y
# CT_ARCH_LE is not set
CT_ARCH_32=y
# CT_ARCH_64 is not set
CT_ARCH_BITNESS=32
# CT_ARCH_FLOAT_HW is not set
CT_ARCH_FLOAT_SW=y
CT_TARGET_CFLAGS=""
CT_TARGET_LDFLAGS=""

#
# General target options
#
# CT_ARCH_alpha is not set
CT_ARCH_arm=y
# CT_ARCH_avr32 is not set
# CT_ARCH_ia64 is not set
# CT_ARCH_m68k is not set
# CT_ARCH_mips is not set
# CT_ARCH_powerpc is not set
# CT_ARCH_s390 is not set
# CT_ARCH_sh is not set
# CT_ARCH_x86 is not set
CT_ARCH_alpha_AVAILABLE=y
CT_ARCH_arm_AVAILABLE=y
CT_ARCH_ARM_MODE="arm"
CT_ARCH_ARM_MODE_ARM=y
# CT_ARCH_ARM_MODE_THUMB is not set
CT_ARCH_ARM_EABI=y
CT_ARCH_avr32_AVAILABLE=y
CT_ARCH_ia64_AVAILABLE=y
CT_ARCH_m68k_AVAILABLE=y
CT_ARCH_mips_AVAILABLE=y
CT_ARCH_powerpc_AVAILABLE=y
CT_ARCH_s390_AVAILABLE=y
CT_ARCH_sh_AVAILABLE=y
CT_ARCH_x86_AVAILABLE=y
CT_ARCH_USE_MMU=y

#
# Target optimisations
#

#
# Toolchain options
#

#
# General toolchain options
#
CT_USE_SYSROOT=y
CT_SYSROOT_DIR_PREFIX=""

#
# Tuple completion and aliasing
#
CT_TARGET_VENDOR="unknown"
CT_TARGET_ALIAS_SED_EXPR=""
CT_TARGET_ALIAS=""

#
# Toolchain type
#
# CT_NATIVE is not set
CT_CROSS=y
# CT_CROSS_NATIVE is not set
# CT_CANADIAN is not set
CT_TOOLCHAIN_TYPE="cross"

#
# Build system
#
CT_BUILD=""
CT_BUILD_PREFIX=""
CT_BUILD_SUFFIX=""

#
# Operating System
#
# CT_BARE_METAL is not set
CT_KERNEL_SUPPORTS_SHARED_LIBS=y
CT_KERNEL="linux"
CT_KERNEL_VERSION="2.6.33.2"
# CT_KERNEL_bare_metal is not set
CT_KERNEL_linux=y
CT_KERNEL_bare_metal_AVAILABLE=y
CT_KERNEL_linux_AVAILABLE=y
CT_KERNEL_LINUX_INSTALL=y
CT_KERNEL_LINUX_INSTALL_CHECK=y
CT_KERNEL_V_2_6_33_2=y
# CT_KERNEL_V_2_6_33_1 is not set
# CT_KERNEL_V_2_6_33 is not set
# CT_KERNEL_V_2_6_32_11 is not set
# CT_KERNEL_V_2_6_31_13 is not set
# CT_KERNEL_V_2_6_30_10 is not set
# CT_KERNEL_V_2_6_29_6 is not set
# CT_KERNEL_V_2_6_28_10 is not set
# CT_KERNEL_V_2_6_27_46 is not set
CT_KERNEL_LINUX_VERBOSITY_0=y
# CT_KERNEL_LINUX_VERBOSITY_1 is not set
# CT_KERNEL_LINUX_VERBOSITY_2 is not set
CT_KERNEL_LINUX_VERBOSE_LEVEL=0
# CT_KERNEL_LINUX_USE_CUSTOM_HEADERS is not set

#
# Common kernel options
#
CT_SHARED_LIBS=y

#
# Binary utilities
#
CT_ARCH_BINFMT_ELF=y
# CT_ARCH_BINFMT_FLAT is not set
# CT_ARCH_BINFMT_FDPIC is not set

#
# GNU binutils
#
CT_BINUTILS_V_2_20=y
# CT_BINUTILS_V_2_19_1 is not set
# CT_BINUTILS_V_2_19 is not set
# CT_BINUTILS_V_2_18 is not set
# CT_BINUTILS_V_2_17 is not set
# CT_BINUTILS_V_2_16_1 is not set
CT_BINUTILS_VERSION="2.20"
CT_BINUTILS_EXTRA_CONFIG=""
# CT_BINUTILS_FOR_TARGET is not set

#
# sstrip
#
CT_SSTRIP=y

#
# C compiler
#
CT_CC="gcc"
CT_CC_VERSION="4.4.3"
CT_CC_gcc=y
CT_CC_V_4_4_3=y
# CT_CC_V_4_4_2 is not set
# CT_CC_V_4_4_1 is not set
# CT_CC_V_4_4_0 is not set
# CT_CC_V_4_3_4 is not set
# CT_CC_V_4_3_3 is not set
# CT_CC_V_4_3_2 is not set
# CT_CC_V_4_3_1 is not set
# CT_CC_V_4_2_4 is not set
# CT_CC_V_4_2_3 is not set
# CT_CC_V_4_2_2 is not set
# CT_CC_V_4_2_1 is not set
# CT_CC_V_4_2_0 is not set
# CT_CC_V_4_1_2 is not set
# CT_CC_V_4_0_4 is not set
# CT_CC_V_3_4_6 is not set
CT_CC_GCC_4_2_or_later=y
CT_CC_GCC_4_3_or_later=y
CT_CC_GCC_4_4_or_later=y
CT_CC_GCC_USE_GMP_MPFR=y
CT_CC_GCC_USE_PPL_CLOOG_MPC=y
CT_CC_CXA_ATEXIT=y
# CT_CC_SJLJ_EXCEPTIONS_CONFIGURE is not set
# CT_CC_SJLJ_EXCEPTIONS_USE is not set
CT_CC_SJLJ_EXCEPTIONS_DONT_USE=y
CT_CC_ENABLE_CXX_FLAGS=""
CT_CC_CORE_EXTRA_CONFIG=""
CT_CC_EXTRA_CONFIG=""
CT_CC_PKGVERSION="crosstool-NG-${CT_VERSION}"
CT_CC_BUGURL=""
CT_CC_SUPPORT_CXX=y
CT_CC_SUPPORT_FORTRAN=y
CT_CC_SUPPORT_JAVA=y
CT_CC_SUPPORT_ADA=y
CT_CC_SUPPORT_OBJC=y
CT_CC_SUPPORT_OBJCXX=y

#
# Additional supported languages:
#
# CT_CC_LANG_CXX is not set
# CT_CC_LANG_FORTRAN is not set
# CT_CC_LANG_JAVA is not set

#
# C-library
#
CT_LIBC="uClibc"
CT_LIBC_VERSION="0.9.30.2"
# CT_LIBC_eglibc is not set
# CT_LIBC_glibc is not set
# CT_LIBC_newlib is not set
# CT_LIBC_none is not set
CT_LIBC_uClibc=y
CT_LIBC_eglibc_AVAILABLE=y
CT_LIBC_glibc_AVAILABLE=y
CT_LIBC_newlib_AVAILABLE=y
CT_LIBC_none_AVAILABLE=y
CT_LIBC_uClibc_AVAILABLE=y
# CT_LIBC_UCLIBC_V_0_9_31 is not set
CT_LIBC_UCLIBC_V_0_9_30_2=y
# CT_LIBC_V_0_9_30_1 is not set
# CT_LIBC_V_0_9_30 is not set
# CT_LIBC_V_0_9_29 is not set
# CT_LIBC_V_0_9_28_3 is not set
# CT_LIBC_V_snapshot is not set
# CT_LIBC_V_specific_date is not set
CT_LIBC_UCLIBC_0_9_30_or_later=y
CT_LIBC_UCLIBC_PARALLEL=y
CT_LIBC_UCLIBC_VERBOSITY_0=y
# CT_LIBC_UCLIBC_VERBOSITY_1 is not set
CT_LIBC_UCLIBC_VERBOSITY=""
CT_LIBC_UCLIBC_DEBUG_LEVEL_0=y
# CT_LIBC_UCLIBC_DEBUG_LEVEL_1 is not set
# CT_LIBC_UCLIBC_DEBUG_LEVEL_2 is not set
CT_LIBC_UCLIBC_DEBUG_LEVEL=0
CT_LIBC_UCLIBC_BUILD_CROSS_LDD=y
CT_LIBC_UCLIBC_CONFIG_FILE="${CT_LIB_DIR}/samples/${CT_TARGET}/${CT_LIBC}-${CT_LIBC_VERSION}.config"
# CT_LIBC_UCLIBC_LOCALES is not set
# CT_LIBC_UCLIBC_WCHAR is not set
# CT_LIBC_SUPPORT_NPTL is not set
CT_LIBC_SUPPORT_LINUXTHREADS=y
CT_THREADS="linuxthreads"

#
# Common C library options
#
# CT_THREADS_NPTL is not set
CT_THREADS_LINUXTHREADS=y
# CT_THREADS_NONE is not set

#
# Debug facilities
#
# CT_DEBUG_dmalloc is not set
# CT_DEBUG_duma is not set
# CT_DEBUG_gdb is not set
# CT_DEBUG_ltrace is not set
# CT_DEBUG_strace is not set

#
# Companion libraries
#

#
# FIXME: check real dependencies!!!
#
CT_COMPLIBS=y
CT_WRAPPER_NEEDED=y
CT_GMP=y
CT_MPFR=y
CT_PPL=y
CT_CLOOG=y
CT_MPC=y
# CT_GMP_V_5_0_1 is not set
CT_GMP_V_4_3_2=y
# CT_GMP_V_4_3_1 is not set
# CT_GMP_V_4_3_0 is not set
# CT_GMP_V_4_2_4 is not set
# CT_GMP_V_4_2_2 is not set
CT_GMP_VERSION="4.3.2"
CT_MPFR_V_2_4_2=y
# CT_MPFR_V_2_4_1 is not set
# CT_MPFR_V_2_4_0 is not set
# CT_MPFR_V_2_3_2 is not set
# CT_MPFR_V_2_3_1 is not set
CT_MPFR_VERSION="2.4.2"
CT_PPL_V_0_10_2=y
CT_PPL_VERSION="0.10.2"
CT_CLOOG_V_0_15_9=y
# CT_CLOOG_V_0_15_8 is not set
# CT_CLOOG_V_0_15_7 is not set
# CT_CLOOG_V_0_15_6 is not set
# CT_CLOOG_V_0_15_5 is not set
# CT_CLOOG_V_0_15_4 is not set
# CT_CLOOG_V_0_15_3 is not set
CT_CLOOG_VERSION="0.15.9"
CT_MPC_V_0_8_1=y
# CT_MPC_V_0_7 is not set
# CT_MPC_V_0_6 is not set
CT_MPC_VERSION="0.8.1"

#
# Companion libraries common options
#
# CT_COMP_LIBS_CHECK is not set
CT_TOOLS_WRAPPER_SCRIPT=y
# CT_TOOLS_WRAPPER_EXEC is not set
CT_TOOLS_WRAPPER="script"


[-- Attachment #3: Type: text/plain, Size: 71 bytes --]

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Arnaud Lacombe]

On Sat, Apr 10, 2010 at 6:50 AM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> Does not work for me:
>
> [ALL  ]    libtool: link: x86_64-build_pc-linux-gnu-gcc -Wall -fomit-frame-pointer -pipe -o cloog cloog.o  -L/home/ymorin/x-tools/armeb-unknown-linux-u
> [ALL  ]    /home/ymorin/x-tools/armeb-unknown-linux-uclibcgnueabi/lib/libppl_c.a(ppl_c_implementation_common.o): In function `ppl_delete_Grid_Generator
> [ALL  ]    ppl_c_implementation_common.cc:(.text+0x41a): undefined reference to `operator delete(void*)'
>
> And many, many more errors related to C++ symbols...
>
d'oh... certainly a missing -lstd++ ${somewhere}, let me come back to
you with something cleaner. What is your .config btw ?

Thanks,
 - Arnaud

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Building a static toolchain ?

[Yann E. MORIN]

Arnaud, All,

On Monday 05 April 2010 02:30:46 Arnaud Lacombe wrote:
> Yes, I just build a i486/GCC 4.4.3/uclibc 0.9.31 that way, see the
> attached patch. These is just a nasty hack to fix gcc link (ppl needs
> libstdc++, which is not used automatically when gcc is called ()).
> --enable-static was not needed in my case, but may solve the stdc++
> crap... I'll give it a try.

Does not work for me:

[ALL  ]    libtool: link: x86_64-build_pc-linux-gnu-gcc -Wall -fomit-frame-pointer -pipe -o cloog cloog.o  -L/home/ymorin/x-tools/armeb-unknown-linux-u
[ALL  ]    /home/ymorin/x-tools/armeb-unknown-linux-uclibcgnueabi/lib/libppl_c.a(ppl_c_implementation_common.o): In function `ppl_delete_Grid_Generator
[ALL  ]    ppl_c_implementation_common.cc:(.text+0x41a): undefined reference to `operator delete(void*)'

And many, many more errors related to C++ symbols...

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

Re: Building a static toolchain ?

[Arnaud Lacombe]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

Hi,

[sorry to break the thread, I'm not yet subscribed to the list]

Marc Kleine-Budde wrote:
>Dimitry Andric wrote:
>> On 2010-03-31 23:25, Yann E. MORIN wrote:
>>>> - make sure any extra dependencies, usually libgmp and/or libmpfr,
>>>> *are* statically linked into the toolchain executables, since not
>>>> everybody will have those as .so files on their system, or may have
>>>> different, incompatible versions.
>>>
>>> Yes, and those *I* was not able to properly build statically (yet!)...
>>> :-(
>>
>> For that, I use something like the attached patch, which should apply
>> cleanly to gcc 4.3.3, but most likely also to later versions.
>
>Why bother to patch gcc. Just ./configure the mpfr and friends with
>"--enable-static --disable-shared". Works like charm here.
Yes, I just build a i486/GCC 4.4.3/uclibc 0.9.31 that way, see the
attached patch. These is just a nasty hack to fix gcc link (ppl needs
libstdc++, which is not used automatically when gcc is called ()).
--enable-static was not needed in my case, but may solve the stdc++
crap... I'll give it a try.

The reason I need that is to get rid of the wrapper logic which
doesn't play nice on non GNU system.

 - Arnaud

[-- Attachment #2: 0001-static-companion-libs.patch --]
[-- Type: application/octet-stream, Size: 7322 bytes --]

From 41b77c9e245aa6740936b1eed92eff5a687b265d Mon Sep 17 00:00:00 2001
From: Arnaud Lacombe <lacombar@gmail.com>
Date: Sun, 4 Apr 2010 20:17:34 -0400
Subject: [PATCH] static companion libs

---
 config/companion_libs.in               |    6 ------
 scripts/build/cc/gcc.sh                |    2 ++
 scripts/build/companion_libs/cloog.sh  |    2 +-
 scripts/build/companion_libs/gmp.sh    |    2 +-
 scripts/build/companion_libs/libelf.sh |    4 ++--
 scripts/build/companion_libs/mpc.sh    |    2 +-
 scripts/build/companion_libs/mpfr.sh   |    2 +-
 scripts/build/companion_libs/ppl.sh    |    2 +-
 8 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/config/companion_libs.in b/config/companion_libs.in
index 64cf138..e93386d 100644
--- a/config/companion_libs.in
+++ b/config/companion_libs.in
@@ -17,7 +17,6 @@ config WRAPPER_NEEDED
 config GMP
     bool
     select COMPLIBS
-    select WRAPPER_NEEDED
     help
       gcc 4.3.0 and above requires GMP to build some frontends, and some
       other components can use them as well.
@@ -35,7 +34,6 @@ config MPFR
     bool
     select GMP
     select COMPLIBS
-    select WRAPPER_NEEDED
     help
       gcc 4.3.0 and above requires MPFR to build some frontends, and some
       other components can use them as well.
@@ -54,7 +52,6 @@ config PPL
     select GMP
     select MPFR
     select COMPLIBS
-    select WRAPPER_NEEDED
     help
       gcc-4.4.0 and above requires PPL to build some parts of the optimiser
       (the GRAPHITE loop optimisation, to be precise).
@@ -69,7 +66,6 @@ config CLOOG
     select MPFR
     select PPL
     select COMPLIBS
-    select WRAPPER_NEEDED
     help
       gcc-4.4.0 and above requires CLooG/PPL to build some parts of the
       optimiser (the GRAPHITE loop optimisation, to be precise).
@@ -85,7 +81,6 @@ config MPC
     select PPL
     select CLOOG
     select COMPLIBS
-    select WRAPPER_NEEDED
     help
       gcc-4.4.0 and above can also optionally use MPC to enable additional
       optimisations on complex numbers. Although MPC is optional,
@@ -98,7 +93,6 @@ config MPC
 config LIBELF
     bool
     select COMPLIBS
-    select WRAPPER_NEEDED
     help
       gcc-4.5.0 and above can also use libelf to enable some optimisation
       (LTO, Link-Time Optimisation, to be precise).  Although libelf is
diff --git a/scripts/build/cc/gcc.sh b/scripts/build/cc/gcc.sh
index f4cf7cb..6dc97e4 100644
--- a/scripts/build/cc/gcc.sh
+++ b/scripts/build/cc/gcc.sh
@@ -165,6 +165,7 @@ do_cc_core() {
     # Use --with-local-prefix so older gccs don't look in /usr/local (http://gcc.gnu.org/PR10532)
     CC_FOR_BUILD="${CT_BUILD}-gcc"                  \
     CFLAGS="${CT_CFLAGS_FOR_HOST}"                  \
+    LDFLAGS="-lstdc++"                              \
     CT_DoExecLog ALL                                \
     "${CT_SRC_DIR}/gcc-${CT_CC_VERSION}/configure"  \
         --build=${CT_BUILD}                         \
@@ -330,6 +331,7 @@ do_cc() {
     # embedded systems don't really need message catalogs...
     CC_FOR_BUILD="${CT_BUILD}-gcc"                  \
     CFLAGS="${CT_CFLAGS_FOR_HOST}"                  \
+    LDFLAGS="-lstdc++"                              \
     CFLAGS_FOR_TARGET="${CT_TARGET_CFLAGS}"         \
     CXXFLAGS_FOR_TARGET="${CT_TARGET_CFLAGS}"       \
     LDFLAGS_FOR_TARGET="${CT_TARGET_LDFLAGS}"       \
diff --git a/scripts/build/companion_libs/cloog.sh b/scripts/build/companion_libs/cloog.sh
index f2e0f0f..b10f47f 100644
--- a/scripts/build/companion_libs/cloog.sh
+++ b/scripts/build/companion_libs/cloog.sh
@@ -57,7 +57,7 @@ do_cloog() {
         --prefix="${CT_PREFIX_DIR}"             \
         --with-gmp="${CT_PREFIX_DIR}"           \
         --with-ppl="${CT_PREFIX_DIR}"           \
-        --enable-shared                         \
+        --disable-shared                         \
         --disable-static                        \
         --with-bits=gmp
 
diff --git a/scripts/build/companion_libs/gmp.sh b/scripts/build/companion_libs/gmp.sh
index 731838e..deee6c1 100644
--- a/scripts/build/companion_libs/gmp.sh
+++ b/scripts/build/companion_libs/gmp.sh
@@ -38,7 +38,7 @@ do_gmp() {
         --build=${CT_BUILD}                         \
         --host=${CT_HOST}                           \
         --prefix="${CT_PREFIX_DIR}"                 \
-        --enable-shared                             \
+        --disable-shared                             \
         --disable-static                            \
         --enable-fft                                \
         --enable-mpbsd                              \
diff --git a/scripts/build/companion_libs/libelf.sh b/scripts/build/companion_libs/libelf.sh
index ecda8ff..54e7407 100644
--- a/scripts/build/companion_libs/libelf.sh
+++ b/scripts/build/companion_libs/libelf.sh
@@ -72,9 +72,9 @@ do_libelf_target() {
         --prefix=/usr                                       \
         --enable-compat                                     \
         --enable-elf64                                      \
-        --enable-shared                                     \
+        --disable-shared                                    \
+        --disable-static                                    \
         --enable-extended-format                            \
-        --enable-static
 
     CT_DoLog EXTRA "Building libelf"
     CT_DoExecLog ALL make
diff --git a/scripts/build/companion_libs/mpc.sh b/scripts/build/companion_libs/mpc.sh
index 796e798..6d9bed3 100644
--- a/scripts/build/companion_libs/mpc.sh
+++ b/scripts/build/companion_libs/mpc.sh
@@ -37,7 +37,7 @@ do_mpc() {
         --prefix="${CT_PREFIX_DIR}"                 \
         --with-gmp="${CT_PREFIX_DIR}"               \
         --with-mpfr="${CT_PREFIX_DIR}"              \
-        --enable-shared                             \
+        --disable-shared                             \
         --disable-static                            \
 
     CT_DoLog EXTRA "Building MPC"
diff --git a/scripts/build/companion_libs/mpfr.sh b/scripts/build/companion_libs/mpfr.sh
index 12fe125..08ff7fe 100644
--- a/scripts/build/companion_libs/mpfr.sh
+++ b/scripts/build/companion_libs/mpfr.sh
@@ -90,7 +90,7 @@ do_mpfr() {
         --host=${CT_HOST}                               \
         --prefix="${CT_PREFIX_DIR}"                     \
         ${mpfr_opt}                                     \
-        --enable-shared                                 \
+        --disable-shared                                 \
         --disable-static                                \
         --with-gmp="${CT_PREFIX_DIR}"
 
diff --git a/scripts/build/companion_libs/ppl.sh b/scripts/build/companion_libs/ppl.sh
index 15312f0..d8d2e6d 100644
--- a/scripts/build/companion_libs/ppl.sh
+++ b/scripts/build/companion_libs/ppl.sh
@@ -40,7 +40,7 @@ do_ppl() {
         --prefix="${CT_PREFIX_DIR}"                 \
         --with-libgmp-prefix="${CT_PREFIX_DIR}"     \
         --with-libgmpxx-prefix="${CT_PREFIX_DIR}"   \
-        --enable-shared                             \
+        --disable-shared                             \
         --disable-static                            \
         --disable-debugging                         \
         --disable-assertions                        \
-- 
1.7.0.rc2.16.g99c03.dirty


[-- Attachment #3: Type: text/plain, Size: 71 bytes --]

--
For unsubscribe information see http://sourceware.org/lists.html#faq