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

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

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