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

[Godmar Back <godmar at gmail dot com>]

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