* ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' @ 2009-09-04 3:47 Godmar Back 2009-09-04 8:49 ` building patched gcc ng 2009-09-04 15:07 ` ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' Yann E. MORIN 0 siblings, 2 replies; 16+ messages in thread From: Godmar Back @ 2009-09-04 3:47 UTC (permalink / raw) To: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* building patched gcc 2009-09-04 3:47 ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' Godmar Back @ 2009-09-04 8:49 ` ng 2009-09-04 12:54 ` Thomas Petazzoni 2009-09-04 15:16 ` Yann E. MORIN 2009-09-04 15:07 ` ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' Yann E. MORIN 1 sibling, 2 replies; 16+ messages in thread From: ng @ 2009-09-04 8:49 UTC (permalink / raw) Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: building patched gcc 2009-09-04 8:49 ` building patched gcc ng @ 2009-09-04 12:54 ` Thomas Petazzoni 2009-09-04 15:16 ` Yann E. MORIN 1 sibling, 0 replies; 16+ messages in thread From: Thomas Petazzoni @ 2009-09-04 12:54 UTC (permalink / raw) To: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: building patched gcc 2009-09-04 8:49 ` building patched gcc ng 2009-09-04 12:54 ` Thomas Petazzoni @ 2009-09-04 15:16 ` Yann E. MORIN 1 sibling, 0 replies; 16+ messages in thread From: Yann E. MORIN @ 2009-09-04 15:16 UTC (permalink / raw) To: crossgcc; +Cc: ng 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' 2009-09-04 3:47 ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' Godmar Back 2009-09-04 8:49 ` building patched gcc ng @ 2009-09-04 15:07 ` Yann E. MORIN 2009-09-04 19:03 ` Godmar Back 1 sibling, 1 reply; 16+ messages in thread From: Yann E. MORIN @ 2009-09-04 15:07 UTC (permalink / raw) To: crossgcc; +Cc: Godmar Back 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' 2009-09-04 15:07 ` ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' Yann E. MORIN @ 2009-09-04 19:03 ` Godmar Back 2009-09-04 22:20 ` Yann E. MORIN 0 siblings, 1 reply; 16+ messages in thread From: Godmar Back @ 2009-09-04 19:03 UTC (permalink / raw) To: Yann E. MORIN; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' 2009-09-04 19:03 ` Godmar Back @ 2009-09-04 22:20 ` Yann E. MORIN 2009-09-05 14:13 ` Godmar Back 0 siblings, 1 reply; 16+ messages in thread From: Yann E. MORIN @ 2009-09-04 22:20 UTC (permalink / raw) To: Godmar Back; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' 2009-09-04 22:20 ` Yann E. MORIN @ 2009-09-05 14:13 ` Godmar Back 2009-09-06 13:06 ` Yann E. MORIN 0 siblings, 1 reply; 16+ messages in thread From: Godmar Back @ 2009-09-05 14:13 UTC (permalink / raw) To: Yann E. MORIN; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' 2009-09-05 14:13 ` Godmar Back @ 2009-09-06 13:06 ` Yann E. MORIN 2009-09-06 13:34 ` Godmar Back 0 siblings, 1 reply; 16+ messages in thread From: Yann E. MORIN @ 2009-09-06 13:06 UTC (permalink / raw) To: Godmar Back; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' 2009-09-06 13:06 ` Yann E. MORIN @ 2009-09-06 13:34 ` Godmar Back 2009-09-06 13:39 ` Yann E. MORIN 0 siblings, 1 reply; 16+ messages in thread From: Godmar Back @ 2009-09-06 13:34 UTC (permalink / raw) To: Yann E. MORIN; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' 2009-09-06 13:34 ` Godmar Back @ 2009-09-06 13:39 ` Yann E. MORIN 2009-09-07 14:04 ` Godmar Back 0 siblings, 1 reply; 16+ messages in thread From: Yann E. MORIN @ 2009-09-06 13:39 UTC (permalink / raw) To: Godmar Back; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' 2009-09-06 13:39 ` Yann E. MORIN @ 2009-09-07 14:04 ` Godmar Back 2009-09-07 16:06 ` Yann E. MORIN 0 siblings, 1 reply; 16+ messages in thread From: Godmar Back @ 2009-09-07 14:04 UTC (permalink / raw) To: Yann E. MORIN; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' 2009-09-07 14:04 ` Godmar Back @ 2009-09-07 16:06 ` Yann E. MORIN 2009-09-09 13:31 ` Godmar Back 0 siblings, 1 reply; 16+ messages in thread From: Yann E. MORIN @ 2009-09-07 16:06 UTC (permalink / raw) To: Godmar Back; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' 2009-09-07 16:06 ` Yann E. MORIN @ 2009-09-09 13:31 ` Godmar Back 2009-09-09 19:56 ` Yann E. MORIN 0 siblings, 1 reply; 16+ messages in thread From: Godmar Back @ 2009-09-09 13:31 UTC (permalink / raw) To: Yann E. MORIN; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' 2009-09-09 13:31 ` Godmar Back @ 2009-09-09 19:56 ` Yann E. MORIN [not found] ` <719dced30909092215qe1bf9a2i1d7f10f15733e11c@mail.gmail.com> 0 siblings, 1 reply; 16+ messages in thread From: Yann E. MORIN @ 2009-09-09 19:56 UTC (permalink / raw) To: Godmar Back; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <719dced30909092215qe1bf9a2i1d7f10f15733e11c@mail.gmail.com>]
* Re: ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' [not found] ` <719dced30909092215qe1bf9a2i1d7f10f15733e11c@mail.gmail.com> @ 2009-09-10 5:16 ` Godmar Back 0 siblings, 0 replies; 16+ messages in thread From: Godmar Back @ 2009-09-10 5:16 UTC (permalink / raw) To: crossgcc 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2009-09-10 5:16 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-04 3:47 ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' Godmar Back 2009-09-04 8:49 ` building patched gcc ng 2009-09-04 12:54 ` Thomas Petazzoni 2009-09-04 15:16 ` Yann E. MORIN 2009-09-04 15:07 ` ct-ng build fails with 'make[1]: *** [configure-binutils] Error 1' Yann E. MORIN 2009-09-04 19:03 ` Godmar Back 2009-09-04 22:20 ` Yann E. MORIN 2009-09-05 14:13 ` Godmar Back 2009-09-06 13:06 ` Yann E. MORIN 2009-09-06 13:34 ` Godmar Back 2009-09-06 13:39 ` Yann E. MORIN 2009-09-07 14:04 ` Godmar Back 2009-09-07 16:06 ` Yann E. MORIN 2009-09-09 13:31 ` Godmar Back 2009-09-09 19:56 ` Yann E. MORIN [not found] ` <719dced30909092215qe1bf9a2i1d7f10f15733e11c@mail.gmail.com> 2009-09-10 5:16 ` Godmar Back
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).