ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

[Godmar Back]

Hi,

I am trying to build a cross-compiler for x86_64 that runs on a CentOS
5.3 installation. The last time I've build a cross-gcc was 10 years
ago (approximately), so I was hoping ct-ng could help.

When building ct-ng, it indicated that my automake and autoconf were
out-of-date (that, by itself, triggered repressed memories...)
So I downloaded and configured autoconf-2.64 and automake-1.10.2 with
the same prefix into which I installed ct-ng.

My attempt to build crosstools breaks with:

$ env PATH=/home/courses/cs3214/cross-x86_64/bin:$PATH ct-ng build
[INFO ]  Build started 20090903.234300
[INFO ]  Checking environment sanity
[INFO ]  Building environment variables
[WARN ]  You did not specify the build system. That's OK, I can guess...
[INFO ]  =================================================================
[INFO ]  Retrieving needed toolchain components' tarballs
[INFO ]  Retrieving needed toolchain components' tarballs: done in
0.02s (at 00:02)
[INFO ]  =================================================================
[INFO ]  Extracting and patching toolchain components
[INFO ]  Extracting and patching toolchain components: done in 0.03s (at 00:02)
[INFO ]  =================================================================
[INFO ]  Installing binutils
[ERROR]    make[1]: *** [configure-binutils] Error 1
[ERROR]    checking for inttypes.h... make[1]: *** [configure-opcodes] Error 1
[ERROR]    Build failed in step 'Installing binutils'
[ERROR]    Error happened in
'/home/courses/cs3214/cross-x86_64/lib/ct-ng-1.4.2/scripts/functions'
in function 'CT_DoExecLog' (line unknown, sorry)
[ERROR]          called from
'/home/courses/cs3214/cross-x86_64/lib/ct-ng-1.4.2/scripts/build/binutils.sh'
at line # 49 in function 'do_binutils'
[ERROR]          called from
'/home/courses/cs3214/cross-x86_64/lib/ct-ng-1.4.2/scripts/crosstool-NG.sh'
at line # 497 in function 'main'
[ERROR]    Look at
'/home/courses/cs3214/x-tools/x86_64-unknown-elf/build.log' for more
info on this error.
[ERROR]  (elapsed: 0:21.83)
[00:22] / make: *** [build] Error 2

Note that I have the correct automake/autoconf:
[cs3214@ghestal crossbuild]$ env
PATH=/home/courses/cs3214/cross-x86_64/bin:$PATH automake --version
automake (GNU automake) 1.10.2
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey <tromey@redhat.com>
       and Alexandre Duret-Lutz <adl@gnu.org>.
[cs3214@ghestal crossbuild]$ env
PATH=/home/courses/cs3214/cross-x86_64/bin:$PATH autoconf --version
autoconf (GNU Autoconf) 2.64
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later
<http://gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

------------------

You can see my .config and build.log here:

http://courses.cs.vt.edu/~cs3214/crosstools-ng/build.log
http://courses.cs.vt.edu/~cs3214/crosstools-ng/dot.config

build.log contains:

[ALL  ]    *** BFD does not support target x86_64-unknown-elf.
[ALL  ]    *** Look in bfd/config.bfd for supported targets.
[ERROR]    make[1]: *** [configure-binutils] Error 1

What gives?  All I did was select 'x86_64' in menuconfig.

Thanks!

 - Godmar

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

building patched gcc

[ng]

Hi,

I have become aware of the need to patch gcc for certain ARM hardware 
and have some patches that need to be applied.

Is there a convenient way to make sure that the patched source does not 
get overwritten by the release tarball when re-running ct-ng?

If it is necessary to start hacking the build scripts to add the patch 
commands , where do I need to be looking ?

TIA, Peter.

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

Re: building patched gcc

[Thomas Petazzoni]

Le Fri, 04 Sep 2009 10:49:51 +0200,
ng@piments.com a écrit :

> If it is necessary to start hacking the build scripts to add the
> patch commands , where do I need to be looking ?

Just add your patches in patches/gcc/<version>/. Don't forget to share
your patches with the community if it makes sense :-)

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

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

Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

[Yann E. MORIN]

Godmar,
All,

On Friday 04 September 2009 05:47:13 Godmar Back wrote:
> When building ct-ng, it indicated that my automake and autoconf were
> out-of-date (that, by itself, triggered repressed memories...)
> So I downloaded and configured autoconf-2.64 and automake-1.10.2 with
> the same prefix into which I installed ct-ng.

Yes, some of the components in the toolchain require those updated versions.
There has recently been discussions on this list whether it'd make sense
for crosstool-NG to build its own version, to alleviate the problem.

I haven't had time to look into this, but it's on the tablets...

> My attempt to build crosstools breaks with:
[[--SNIP--]
> build.log contains:
> 
> [ALL  ]    *** BFD does not support target x86_64-unknown-elf.
> [ALL  ]    *** Look in bfd/config.bfd for supported targets.
> [ERROR]    make[1]: *** [configure-binutils] Error 1

Tuples in the form arch-vendor-elf are for bare-metal. Are you sure
you want to run on bare-metal x86-64? Are did you forget to set the
"Target OS" to "linux"?

> What gives?  All I did was select 'x86_64' in menuconfig.

Hmm.. There is no "default" configuration for crosstool-NG. There are so
many possibilities, depending on so many factors, that deciding upon a
sane default is not easy. For the "Target OS", the default is "bare metal"
which alphabetically sorts before "linux"

That's bad because the sorting can be different, depending on the locale
in use... But I consider this as being a minor issue (if at all), and
I didn't look at /fixing/ it.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  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 patched gcc

[Yann E. MORIN]

Peter,
All,

On Friday 04 September 2009 10:49:51 ng@piments.com wrote:
> I have become aware of the need to patch gcc for certain ARM hardware 
> and have some patches that need to be applied.

If only it was gcc for ARM... A lot of other components require patching
for diverse reasons: proper arch support, PR fixes, non-PR fixes...

> Is there a convenient way to make sure that the patched source does not 
> get overwritten by the release tarball when re-running ct-ng?

Once crosstool-NG has extracted the tarball, it will not be
overwriten but subsequent calls to ct-ng.

> If it is necessary to start hacking the build scripts to add the patch 
> commands , where do I need to be looking ?

You don't have to hack the scripts (unless there's a bug, which I am
not aware of so far in this part).

By default, crosstool-NG comes bundled with a proper set of patches
for each version of each supported component. And ct-ng knows where
to find this patchset.

If you have custom patches, there are two ways you can use them:
 - as Thomas suggested, include them in the same place crosstool-NG
   has the existing patches (but you'd better submit them)
 - or you can have a place on your machine that is completly out of
   control from crosstool-NG and put your patches there. Then you
   tell ct-ng where to find those patches, and it will happily get
   them and apply them. So if you later need to remove the build
   directory, you don't loose the patches, and on subsequent run,
   the patches will again be applied.

Look at:
Paths and misc options  --->
    [X] Use custom patch directory
    [ ]   Only use custom patches
    ()    Custom patch directory

Read the help for those two entries, they should be quite self explanatory.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  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: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

[Godmar Back]

On Fri, Sep 4, 2009 at 11:07 AM, Yann E.
MORIN<yann.morin.1998@anciens.enib.fr> wrote:

Yann, thanks for your answer.

>
> On Friday 04 September 2009 05:47:13 Godmar Back wrote:
>> When building ct-ng, it indicated that my automake and autoconf were
>> out-of-date (that, by itself, triggered repressed memories...)
>> So I downloaded and configured autoconf-2.64 and automake-1.10.2 with
>> the same prefix into which I installed ct-ng.
>
> Yes, some of the components in the toolchain require those updated versions.
> There has recently been discussions on this list whether it'd make sense
> for crosstool-NG to build its own version, to alleviate the problem.
>
> I haven't had time to look into this, but it's on the tablets...

To be clear: in this situation, I'm trying to build a cross compiler
on a shared platform that I do not administer. So I can't put anything
in, say /etc/ld.so.conf, /usr/bin, or /usr/lib, or even /usr/local.
That's why I installed these versions of automake/autoconf in
$prefix/bin where $prefix is the --prefix argument to ct-ng. I then
prepend this directory to the path when running ct-ng.

>
> Tuples in the form arch-vendor-elf are for bare-metal. Are you sure
> you want to run on bare-metal x86-64? Are did you forget to set the
> "Target OS" to "linux"?

I did not - setting x86_64 was the only change I made. I have now
remedied that and made two changes:
- target to x86_64
- OS to Linux.

Now the build fails with:
[INFO ]  Installing shared core C compiler
[ERROR]    Build failed in step 'Installing shared core C compiler'
[ERROR]    Error happened in
'/home/courses/cs3214/cross-x86_64/lib/ct-ng-1.4.2/scripts/functions'
in function 'CT_DoExecLog' (line unknown, sorry)
[ERROR]          called from
'/home/courses/cs3214/cross-x86_64/lib/ct-ng-1.4.2/scripts/build/cc/gcc.sh'
at line # 213 in function 'do_cc_core'
[ERROR]          called from
'/home/courses/cs3214/cross-x86_64/lib/ct-ng-1.4.2/scripts/build/cc/gcc.sh'
at line # 69 in function 'do_cc_core_pass_2'
[ERROR]          called from
'/home/courses/cs3214/cross-x86_64/lib/ct-ng-1.4.2/scripts/crosstool-NG.sh'
at line # 497 in function 'main'
[ERROR]    Look at
'/home/courses/cs3214/x-tools/x86_64-unknown-linux-gnu/build.log' for
more info on this error.
[ERROR]  (elapsed: 25:00.40)
[25:01] / make: *** [build] Error 2

build.log shows:
[ALL  ]    make[1]: *** No rule to make target
`../build-i386-build_redhat-linux-gnu/libiberty/libiberty.a', needed
by `build/genmodes'.  Stop.
[ALL  ]    make[1]: Leaving directory
`/home/courses/cs3214/software/crossbuild/targets/x86_64-unknown-linux-gnu/build/build-cc-core-shared/gcc'

Full log is:
http://courses.cs.vt.edu/~cs3214/crosstools-ng/build.log
.config is:
http://courses.cs.vt.edu/~cs3214/crosstools-ng/dot.config

>
> Hmm.. There is no "default" configuration for crosstool-NG. There are so
> many possibilities, depending on so many factors, that deciding upon a
> sane default is not easy. For the "Target OS", the default is "bare metal"
> which alphabetically sorts before "linux"
>
> That's bad because the sorting can be different, depending on the locale
> in use... But I consider this as being a minor issue (if at all), and
> I didn't look at /fixing/ it.
>

All I am interested in is getting a compiler that emits x86_64
assembly code for some ISO-C code for instructional purposes. It
doesn't need to run. It doesn't need a particular libc version. I'm
not picky.

Do you know of a configuration that is known to work?

 - Godmar

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

Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

[Yann E. MORIN]

Godmar,
All,

On Friday 04 September 2009 21:03:16 Godmar Back wrote:
> > Yes, some of the components in the toolchain require those updated versions.
> > There has recently been discussions on this list whether it'd make sense
> > for crosstool-NG to build its own version, to alleviate the problem.
> To be clear: in this situation, I'm trying to build a cross compiler
> on a shared platform that I do not administer. So I can't put anything
> in, say /etc/ld.so.conf, /usr/bin, or /usr/lib, or even /usr/local.
> That's why I installed these versions of automake/autoconf in
> $prefix/bin where $prefix is the --prefix argument to ct-ng. I then
> prepend this directory to the path when running ct-ng.

That's all perfectly fine. I was just pointing out that it was a known
situation.

> > did you forget to set the
> > "Target OS" to "linux"?
> I did not - setting x86_64 was the only change I made. I have now
> remedied that and made two changes:
> - target to x86_64
> - OS to Linux.

Well, building a toolchain does not go with the snap of fingers.
As I said previously, there is *no* *sane* defaults to the config
options. So you can *not* rely on just setting a few options here
and there, you have to look at (almost) every other options...

> Now the build fails with:
[--SNIP--]
> build.log shows:
> [ALL  ]    make[1]: *** No rule to make target
> `../build-i386-build_redhat-linux-gnu/libiberty/libiberty.a', needed
> by `build/genmodes'.  Stop.

Did you google for this error?

> All I am interested in is getting a compiler that emits x86_64
> assembly code for some ISO-C code for instructional purposes. It
> doesn't need to run. It doesn't need a particular libc version. I'm
> not picky.
> Do you know of a configuration that is known to work?

The bundled sample x86_64-unknown-linux-uclibc would seem to fit.

How to use samples:
  ct-ng "put the sample name here"

Eg. in this case:
  ct-ng x86_64-unknown-linux-uclibc

How to list all available samples:
  ct-ng list-samples

Regards,
Yann E. MORIN.


-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  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: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

[Godmar Back]

On Fri, Sep 4, 2009 at 6:20 PM, Yann E.
MORIN<yann.morin.1998@anciens.enib.fr> wrote:
>
>> Now the build fails with:
> [--SNIP--]
>> build.log shows:
>> [ALL  ]    make[1]: *** No rule to make target
>> `../build-i386-build_redhat-linux-gnu/libiberty/libiberty.a', needed
>> by `build/genmodes'.  Stop.
>
> Did you google for this error?

No. But I'm happy to...:

http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla:en-US:official&hs=gAR&ei=s9KhSsrvNsvHlAeDoaH1CA&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=../build-i386-build+redhat-linux-gnu/libiberty/libiberty.a+needed+by+build/genmodes&spell=1

- the top 3 hits are people having the same issue, with no one being
able to help them.

I also checked the Makefile, which doesn't have a rule for libiberty.a.

From what I recall, libiberty.a is typically built as part of gcc
(it's in a subdirectory in a traditional gcc distribution.) Why it
isn't, I don't know.

>
>> All I am interested in is getting a compiler that emits x86_64
>> assembly code for some ISO-C code for instructional purposes. It
>> doesn't need to run. It doesn't need a particular libc version. I'm
>> not picky.
>> Do you know of a configuration that is known to work?
>
> The bundled sample x86_64-unknown-linux-uclibc would seem to fit.
>
> How to use samples:
>  ct-ng "put the sample name here"
>
> Eg. in this case:
>  ct-ng x86_64-unknown-linux-uclibc
>
> How to list all available samples:
>  ct-ng list-samples
>

Thank you for this tip. I saw that both x86_64-unknown-linux-uclibc
and x86_64-unknown-linux-gnu were listed (the latter, I assume, is
using the GNU C library), so I got adventurous and tried it instead of
using the smaller uclibc. 3 hours and 20 mins later, it blows up with:

[INFO ]  =================================================================
[INFO ]  Installing ltrace
[EXTRA]    Copying sources to build dir
[EXTRA]    Configuring ltrace
[EXTRA]    Building ltrace
[ERROR]    make[1]: *** [ltrace] Error 1
[ERROR]    Build failed in step 'Installing ltrace'
[ERROR]    Error happened in
'/home/courses/cs3214/cross-x86_64/lib/ct-ng-1.4.2/scripts/functions'
in function 'CT_DoExecLog' (line unknown, sorry)
[ERROR]          called from
'/home/courses/cs3214/cross-x86_64/lib/ct-ng-1.4.2/scripts/build/debug/400-ltrace.sh'
at line # 37 in function 'do_debug_ltrace_build'
[ERROR]          called from
'/home/courses/cs3214/cross-x86_64/lib/ct-ng-1.4.2/scripts/build/debug.sh'
at line # 35 in function 'do_debug'
[ERROR]          called from
'/home/courses/cs3214/cross-x86_64/lib/ct-ng-1.4.2/scripts/crosstool-NG.sh'
at line # 497 in function 'main'
[ERROR]    Look at
'/home/courses/cs3214/x-tools/x86_64-unknown-linux-gnu/build.log' for
more info on this error.
[ERROR]  (elapsed: 200:18.61)
[200:19] / make: *** [build] Error 2

The error is caused by:
[ALL  ]    x86_64-unknown-linux-gnu-gcc  sysdeps/sysdep.o ltrace.o
options.o elf.o output.o read_config_file.o execute_program.o
wait_for_something.o process_event.o display_args.o breakpoints.o
proc.o demangle.o dict.o debug.o summary.o -lsupc++ -liberty  -o
ltrace
[ALL  ]    elf.o: In function `do_init_elf':
[ALL  ]    /home/courses/cs3214/software/crossbuild/targets/x86_64-unknown-linux-gnu/build/build-ltrace/elf.c:48:
undefined reference to `elf_begin'
...

So, you may wish to remove x86_64-unknown-linux-gnu from the list of
samples known to work out of the box.

Looking at this more closely: elf_begin is traditionally in libelf.a,
but the Makefile for ltrace does not specify -lelf. Adding -lelf
doesn't work because x86_64...ranlib hasn't been run on libelf.a
(although libelf.a has been built and installed in
x-tools/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu//sys-root/usr/lib/../lib64/libelf.a
). Manually running x86_...ranlib on libelf.a, then specifying
libelf.a on the link line does make ltrace link successfully. Good.
Perhaps a patch is missing?  Or, dare I say, automake/autoconf screwed
up again?

After successfully building ltrace by hand in the build directory, I
made the mistake of issuing a new ct-ng build command, hoping it would
continue like an ordinary build, rather than starting from scratch;
but it doesn't. Is there a way to make ct-ng continue after a failure?

I then disabled ltrace in the configuration and, not wanting to risk
anything, also strace, which is the last command that would be built.
69 minutes later (this time, with 4 parallel jobs), I ended up as the
proud owner of a working x86_64 toolchain.

Excellent, and thank you again for your help!

 - Godmar

(*) I then couldn't withstand the temptation to actually run a
statically compiled binary on a Ubuntu 8.10 machine with a x86_64
2.6.27 kernel. This triggered a "FATAL: Kernel too old" error in
__libc_start_main. It used to be that Linux provided binary
compatibility for static binaries; but those days are long past, it
seems. Or is there a way to tell ct-ng to build a compiler/library
whose static binaries will run on all kernels? Going through
menuconfig, it appears you had to decide on a kernel version?

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

Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

[Yann E. MORIN]

Godmar,
All,

On Saturday 05 September 2009 16:13:02 Godmar Back wrote:
[--SNIp--]
> Thank you for this tip. I saw that both x86_64-unknown-linux-uclibc
> and x86_64-unknown-linux-gnu were listed (the latter, I assume, is
> using the GNU C library), so I got adventurous and tried it instead of
> using the smaller uclibc. 3 hours and 20 mins later, it blows up with:
[--SNIP--]
> The error is caused by:
> [ALL  ]    x86_64-unknown-linux-gnu-gcc  sysdeps/sysdep.o ltrace.o
> options.o elf.o output.o read_config_file.o execute_program.o
> wait_for_something.o process_event.o display_args.o breakpoints.o
> proc.o demangle.o dict.o debug.o summary.o -lsupc++ -liberty  -o
> ltrace
> [ALL  ]    elf.o: In function `do_init_elf':
> [ALL  ]    /home/courses/cs3214/software/crossbuild/targets/x86_64-unknown-linux-gnu/build/build-ltrace/elf.c:48:
> undefined reference to `elf_begin'
> So, you may wish to remove x86_64-unknown-linux-gnu from the list of
> samples known to work out of the box.

Or I'll try to fix it...

> Looking at this more closely: elf_begin is traditionally in libelf.a,
> but the Makefile for ltrace does not specify -lelf. Adding -lelf
> doesn't work because x86_64...ranlib hasn't been run on libelf.a
> (although libelf.a has been built and installed in
> x-tools/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu//sys-root/usr/lib/../lib64/libelf.a
> ). Manually running x86_...ranlib on libelf.a, then specifying
> libelf.a on the link line does make ltrace link successfully. Good.
> Perhaps a patch is missing?  Or, dare I say, automake/autoconf screwed
> up again?

I'll look up this issue...

> After successfully building ltrace by hand in the build directory, I
> made the mistake of issuing a new ct-ng build command, hoping it would
> continue like an ordinary build, rather than starting from scratch;
> but it doesn't. Is there a way to make ct-ng continue after a failure?

crosstool-NG is not really a Makefile. It wont automagically restart
where it failed.

You can however set the following in the configuration menu:
  Paths and misc options -->
  [*] Debug crosstool-NG
  [ ]   Pause between every steps
  [*]   Save intermediate steps
  [*]     gzip saved states

Then run crosstool-NG as usual. If it breaks, you can try and fix the
issue, and then resume with:
  ct-ng RESTART="step-that-failed"

Eg. if it failed during the libc build:
  ct-ng RESTART=libc

Or you can use the shortcut (notice the trailing '+'):
  ct-ng libc+

> I then disabled ltrace in the configuration and, not wanting to risk
> anything, also strace, which is the last command that would be built.
> 69 minutes later (this time, with 4 parallel jobs), I ended up as the
> proud owner of a working x86_64 toolchain.

Yep. It you don't need the debug and tools, you can safely unselect them.

> Excellent, and thank you again for your help!

Cheers! :-)

> (*) I then couldn't withstand the temptation to actually run a
> statically compiled binary on a Ubuntu 8.10 machine with a x86_64
> 2.6.27 kernel. This triggered a "FATAL: Kernel too old" error in
> __libc_start_main. It used to be that Linux provided binary
> compatibility for static binaries; but those days are long past, it
> seems. Or is there a way to tell ct-ng to build a compiler/library
> whose static binaries will run on all kernels? Going through
> menuconfig, it appears you had to decide on a kernel version?

Look at the option:
  C-library  -->
  Minimum supported kernel version  -->
    ( ) Let ./configure decide
    (X) Same as kernel headers (default)
    ( ) Specific kernel version

This means that glibc is configured at build-time to enable (or disable)
support for old kernels, by including (or ommiting) certain functions
and/or code paths. By default, crosstool-NG configure glibc to not include
support for kernels older than the version of the headers being used to
build the toolchain. You can override this by choosing one of the two other
options, above.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  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: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

[Godmar Back]

On Sun, Sep 6, 2009 at 9:06 AM, Yann E.
MORIN<yann.morin.1998@anciens.enib.fr> wrote:
>
>> (*) I then couldn't withstand the temptation to actually run a
>> statically compiled binary on a Ubuntu 8.10 machine with a x86_64
>> 2.6.27 kernel. This triggered a "FATAL: Kernel too old" error in
>> __libc_start_main. It used to be that Linux provided binary
>> compatibility for static binaries; but those days are long past, it
>> seems. Or is there a way to tell ct-ng to build a compiler/library
>> whose static binaries will run on all kernels? Going through
>> menuconfig, it appears you had to decide on a kernel version?
>
> Look at the option:
>  C-library  -->
>  Minimum supported kernel version  -->
>    ( ) Let ./configure decide
>    (X) Same as kernel headers (default)
>    ( ) Specific kernel version
>
> This means that glibc is configured at build-time to enable (or disable)
> support for old kernels, by including (or ommiting) certain functions
> and/or code paths. By default, crosstool-NG configure glibc to not include
> support for kernels older than the version of the headers being used to
> build the toolchain. You can override this by choosing one of the two other
> options, above.
>

Can you clarify what you mean by "one of the two others options"?

Choosing "Let ./configure decide" and "Specific kernel version" will
enable support for older kernels?
That's not intuitive.

 - Godmar

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

Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

[Yann E. MORIN]

Godmar,
All,

On Sunday 06 September 2009 15:34:41 Godmar Back wrote:
> > This means that glibc is configured at build-time to enable (or disable)
> > support for old kernels, by including (or ommiting) certain functions
> > and/or code paths. By default, crosstool-NG configure glibc to not include
> > support for kernels older than the version of the headers being used to
> > build the toolchain. You can override this by choosing one of the two other
> > options, above.
> Can you clarify what you mean by "one of the two others options"?
> Choosing "Let ./configure decide" and "Specific kernel version" will
> enable support for older kernels?
> That's not intuitive.

Hopefully, that's explained quite in length in the "Help" entries for the
three options. If that's still not clear enough, then come back, and ask
again, please.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  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: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

[Godmar Back]

On Sun, Sep 6, 2009 at 9:39 AM, Yann E.
MORIN<yann.morin.1998@anciens.enib.fr> wrote:
>> Can you clarify what you mean by "one of the two others options"?
>> Choosing "Let ./configure decide" and "Specific kernel version" will
>> enable support for older kernels?
>> That's not intuitive.
>
> Hopefully, that's explained quite in length in the "Help" entries for the
> three options. If that's still not clear enough, then come back, and ask
> again, please.
>

It's explained there; still, it's not intuitive. I don't usually read
"Help" entries unless I think the label given to the option applies to
me.  Perhaps make the label more informative to make clear that the
options influence the ability to run on all kernels?

 - Godmar

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

Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

[Yann E. MORIN]

Godmar,
All,

On Monday 07 September 2009 16:04:32 Godmar Back wrote:
> It's explained there; still, it's not intuitive. I don't usually read
> "Help" entries unless I think the label given to the option applies to
> me.  Perhaps make the label more informative to make clear that the 
> options influence the ability to run on all kernels?

I thought that "Minimum supported kernel version" was explicit enough.
What would you suggest instead (keep it short)?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  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: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

[Godmar Back]

On Mon, Sep 7, 2009 at 12:06 PM, Yann E.
MORIN<yann.morin.1998@anciens.enib.fr> wrote:
> Godmar,
> All,
>
> On Monday 07 September 2009 16:04:32 Godmar Back wrote:
>> It's explained there; still, it's not intuitive. I don't usually read
>> "Help" entries unless I think the label given to the option applies to
>> me.  Perhaps make the label more informative to make clear that the
>> options influence the ability to run on all kernels?
>
> I thought that "Minimum supported kernel version" was explicit enough.
> What would you suggest instead (keep it short)?

That's not the confusing part, though this label could, perhaps, be
made more clear by saying "Minimum supported target kernel version" to
make clear it's the target that's being talked about.

The more confusing issue IMO is one level below that one, where it says:

Let ./configure decide
Same as kernel headers (default)
Specific kernel version

None of these three options imply that support for all kernels is
provided. For the first one, the Help doesn't say, btw, *how*
configure makes that decision. The label "Let ./configure decide" did
not make me look in the Help to learn that this provides support for
all kernels. Perhaps change to "Support all compatible kernels" or
something like that?

The third option "Specific kernel version" makes it sound as though
only this version is supported. Perhaps change to: "Choose minimum
target kernel version"?

 - Godmar

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

Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

[Yann E. MORIN]

Godmar,
All,

On Wednesday 09 September 2009 15:31:40 Godmar Back wrote:
> > I thought that "Minimum supported kernel version" was explicit enough.
> > What would you suggest instead (keep it short)?
> That's not the confusing part, though this label could, perhaps, be
> made more clear by saying "Minimum supported target kernel version" to
> make clear it's the target that's being talked about.

Well, the C library is expected to run on the target, so it's implicit
we're talking about the kernel for the target. Would something like
"Minimum kernel version supported by C library" be better?

> The more confusing issue IMO is one level below that one, where it says:
> Let ./configure decide
> Same as kernel headers (default)
> Specific kernel version

> None of these three options imply that support for all kernels is
> provided.

Because it does *not* add support for *all* kernel.

> For the first one, the Help doesn't say, btw, *how* 
> configure makes that decision. The label "Let ./configure decide" did
> not make me look in the Help to learn that this provides support for
> all kernels. Perhaps change to "Support all compatible kernels" or
> something like that?

The help text gives _some_ examples of what minimum versions will be
supported. Excerpt:

--8<--
Let ./configure decide what minimum kernel version glibc/eglibc
will be able to run against.

This will include legacy compatibility code for older kernels in 
the C library, thus ensuring that it will run on a large number
of old kernels.

The minimum kernel version supported will be dependent upon the
target you build for. For example:
  alpha*-*-linux-gnu      Requires Linux 2.6.9 for NPTL
  sh[34]-*-linux-gnu      Requires Linux 2.6.11
  powerpc*                Requires Linux 2.4.19
  arm*-*-linux-*gnueabi   Requires Linux 2.6.16
--8<--

./configure uses some kind of "black-magic" to determine what the minimum
kernel version is required for a specific combination, and acts accordingly.

And I would say that if you don't know what to choose, read the help entries.
If you still don't know, google for it. And if you still don't know, keep
the default.

Now, if you read the help entry for the default choice, you'll read something
along the lines of:

--8<--
If enabled, crosstool-ng will use the chosen version of kernel
headers for the glibc minimum kernel version supported, which is
what gets passed to "--enable-kernel=" when configuring glibc.
--8<--

If that does not sounds clear to you, then head straight for the glibc
documentation:
  http://www.gnu.org/software/libc/manual/html_mono/libc.html

Appendix C "Installing the GNU C Library", chapter C.1 "Configuring and
compiling GNU Libc" states:

--8<--
‘--enable-kernel=version’
    This option is currently only useful on GNU/Linux systems. The version
    parameter should have the form X.Y.Z and describes the smallest version
    of the Linux kernel the generated library is expected to support. The
    higher the version number is, the less compatibility code is added, and
    the faster the code gets.
--8<--

(I confess that they are not telling what the default for this option is.)

And finally, reading the help entry for "Specific kernel version" says:

--8<--
If you want to be able to statically link programs with your
toolchain's C library, make sure this kernel version is lower than
all kernels you wish to support to avoid "FATAL: kernel too old"
errors.  The higher the version you specify, the less legacy code
will be built into libc.
--8<--

Which should hint you about the message you had...

Sorry if I sound harsh, but building a toolchain is really a complex matter
and crosstool-NG (or any other builder for that matter) does not prevent
the user from having at least some knowledge of what he/she is doing, and
do his/her homework prior to yelling about wolves...

> The third option "Specific kernel version" makes it sound as though
> only this version is supported. Perhaps change to: "Choose minimum
> target kernel version"?

OK for "Enter minimum suported kernel version below", then?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  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: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1'

[Godmar Back]

On Wed, Sep 9, 2009 at 3:56 PM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
>
> Sorry if I sound harsh, but building a toolchain is really a complex matter
> and crosstool-NG (or any other builder for that matter) does not prevent
> the user from having at least some knowledge of what he/she is doing, and
> do his/her homework prior to yelling about wolves...
>

Nobody's yelling; I was merely pointing out that "let ./configure
decide" in a submenu item does not make me read the "Help" to figure
out if that means that the resulting target would support multiple
kernel versions. (Perhaps you were hoping to inspire the reader's
curiosity - let ./configure decide ... hmmm, I wonder what ./configure
would decide - well the help must explain it. Ah!) In any event,
please take my feedback as a suggestion for possible improvement, not
yelling.

I think we all appreciate the tremendous amount of work and effort you
and others put into tools like crosstool-ng. It is an artifact that
represents probably tens of thousands of man hours of work and
experience, especially for a task like building gcc. One could compare
it to the fancy remote controlled augers with video equipment they
bring in to free clogged sewers - "high tech" for what otherwise would
be a disgusting chore. Always keep in mind that the community
appreciates your efforts.

 - Godmar

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