Error while building OS-Specific Toolchain

KemyLand · **Posted:** Wed Nov 05, 2014 5:02 am

Hi! As you noticed, I'm in the (frustrating) process of creating an OS-specific toolchain. I've followed the instructions in the wiki, and have managed to resolve most build errors, except one. When make'ing binutils, I end up with this error log:

Code:

make[4]: se ingresa al directorio «/usr/bluesky/src/binutils-build/ld»
make[4]: *** No hay ninguna regla para construir el objetivo «eelf_i386_bluesky.o», necesario para «ld-new».  Alto.
make[4]: se sale del directorio «/usr/bluesky/src/binutils-build/ld»
make[3]: *** [all-recursive] Error 1
make[3]: se sale del directorio «/usr/bluesky/src/binutils-build/ld»
make[2]: *** [all] Error 2
make[2]: se sale del directorio «/usr/bluesky/src/binutils-build/ld»
make[1]: *** [all-ld] Error 2
make[1]: se sale del directorio «/usr/bluesky/src/binutils-build»
make: *** [all] Error 2

I'm a native spanish speaker, so this is what I've translated

Code:

make[4]: entering directory «/usr/bluesky/src/binutils-build/ld»
make[4]: *** No rule found for building target «eelf_i386_bluesky.o», required for «ld-new».  Stop.
make[4]: leaving directory «/usr/bluesky/src/binutils-build/ld»
make[3]: *** [all-recursive] Error 1
make[3]: leaving directory «/usr/bluesky/src/binutils-build/ld»
make[2]: *** [all] Error 2
make[2]: leaving directory «/usr/bluesky/src/binutils-build/ld»
make[1]: *** [all-ld] Error 2
make[1]: leaving directory «/usr/bluesky/src/binutils-build»
make: *** [all] Error 2

This probably isn't what English make outputs, but its what I can provide...

I've deduced the problem is in /ld/Makefile.am. The wiki says:

OSDev Wiki wrote:

ld/Makefile.am
... The code...
You also need to add eelf_i386_myos.c to the ALL_EMULATION_SOURCES list; and you also need to add eelf_x86_64_myos.c to the ALL_64_EMULATION_SOURCES list.
Note: You must run automake in the ld directory after you modify Makefile.am to regenerate Makefile.in.

Those two statements became me crazy! The first one is pretty obvious, but took me a while to use the 'find' function of gedit to understand it...
Meanwhile, the second one, which is several times more obvious, generates me several times more troubles. That's because of all the version incompatibilities automake & friends have. If I run automake:

Code:

automake: warning: autoconf input should be named 'configure.ac', not 'configure.in'
aclocal.m4:16: warning: this file was generated for autoconf 2.64.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically `autoreconf'.
configure.in:21: error: Please use exactly Autoconf 2.64 instead of 2.69.
../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.in:21: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
automake: error: autoconf failed with exit status: 1

That's not a very hopeful message... now: autoreconf

Code:

aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
configure.in:21: error: Please use exactly Autoconf 2.64 instead of 2.69.
../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.in:21: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
autoreconf2.50: aclocal failed with exit status: 1

... autoreconf2.64 ...

Code:

aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
configure.in:31: error: Autoconf version 2.65 or higher is required
/usr/share/aclocal-1.14/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
configure.in:31: the top level
autom4te2.64: /usr/bin/m4 failed with exit status: 63
aclocal: error: echo failed with exit status: 63
autoreconf2.64: aclocal failed with exit status: 63

Just warnings and recursive references! What do I do?

mallard · **Posted:** Wed Nov 05, 2014 5:20 am

Which version of binutils are you trying to build?

I've successfully built v2.23 using autoconf 2.69 (despite the warnings) and automake 1.11 (newer versions can't build newlib, if you intend to use it).

KemyLand · **Posted:** Wed Nov 05, 2014 5:28 am

Binutils v2.24
GCC v4.9.2
Newlib 1.15.0

I've already apt-get removed && reinstalled autoconf, specifically the 2.64 version only. But autoconf (plain command) says its version is 2.69. If I automake in the ld directory, the same results... It seems that the Ubuntu repos automatically gives me the 2.69 version, which I don't want. However, automake seems to use the plain autoconf command, which redirects to v2.69...

max · **Posted:** Wed Nov 05, 2014 6:09 am

The problem is that you're using the wrong versions of autoconf and/or automake.
The message that the build of binutils gives you means that the makefile does not know how to build the sources of LD in a way that the resulting binary of LD can handle objects for your target. Thats what you configure when you add your target to the list of emulation sources as stated in the wiki.

For binutils 2.24 and gcc 4.9.1 you need exactly autoconf 2.64 and exactly automake 1.11.1 on your system (note that the AUTOMAKE and ACLOCAL variables must point to the binaries of automake 1.11.1).

sortie · **Joined:** Wed Mar 21, 2012 3:01 pm **Posts:** 930

I feel your pain. It's absolutely insane what's really going on when you need to regenerate all the generated files in the binutils and gcc trees. The developers should be ashamed. My favourite part is gcc releases using an unreleased libtool version.

I recommend getting the correct autoconf/automake source code releases and installing it somewhere like ~/opt/autoconf-2.64 and adding it to your PATH when you need it. Adding a program suffix could be useful. This ensures you are really using the proper versions and that they are nicely separated, as opposed to using other versions that comes with your distro.

You don't need to autoreconf, that runs a lot of autotools. Those must match the expected versions and all that. You just want to only automake in this case. It is possible to reautoconf the entire tree, but don't do that unless you really want to do that; if you do, talk to me, I got a script that does it, but it's not pretty or even perfect.

Btw. you can use LC_ALL=C to force the C locale, where you get English error messages. (Read the locale environment variable documentation, there is more to this, but that this is a fail-safe way)

KemyLand · **Posted:** Thu Nov 06, 2014 2:08 am

IT WORKED!! How is it possible that something like *GNU* Autotools is so incompatible with itself? Now I'm going with the real work, GCC

BTW, thanks sortie, the LC_ALL method worked perfectly :wink:

KemyLand · **Posted:** Thu Nov 06, 2014 2:24 am

Problems again

Code:

make[2]: Entering directory `/usr/bluesky/src/gcc-build/gcc'
make[2]: *** No rule to make target `../../gcc-4.9.2/gcc/config/bluesky.h', needed by `s-gtype'.  Stop.
make[2]: Leaving directory `/usr/bluesky/src/gcc-build/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/usr/bluesky/src/gcc-build'
make: *** [all] Error 2

After this, I'm gonna end up updating (and correcting) the wiki...

The wiki says here: http://wiki.osdev.org/OS_Specific_Toolc ... g.2Fmyos.h (sorry, the [wiki] feature doesn't allows specific sections), something about some macros not documented in there, namely

OSDev Wiki wrote:

TODO: It would make sense to document the handling of STARTFILE_SPEC, ENDFILE_SPEC, and LIB_SPEC here as well.

Although that's obviously not the problem, its automake again :evil:

. I don't want to automake all (its GCC!). The wiki doesn't specifies the directory that must be rebuilt.

It was a really bad idea, and I did it... I think must redownload GCC...

I ran automake/autoconf/autoreconf/aclocal on the root dir, first with the recommended versions. Then make

Code:

/usr/bluesky/src/gcc-4.9.2/gcc/configure: line 4265: syntax error near unexpected token `-I"$srcdir"/ada'
/usr/bluesky/src/gcc-4.9.2/gcc/configure: line 4265: `ACX_PROG_GNAT(-I"$srcdir"/ada)'

Runned the autos with the distro version. Make throws the same... I'm not even using Ada! What did I just did? Is that really invalid syntax?

Rebuilt with a new, fresh GCC download. Now, there was no error for about 20 minutes, then this:

Code:

checking whether ln -s works... yes
checking for i686-elf-bluesky-gcc... /usr/bluesky/src/gcc-build/./gcc/xgcc -B/usr/bluesky/src/gcc-build/./gcc/ -B/usr/bluesky/sysroot/usr/bin/i686-elf-bluesky/bin/ -B/usr/bluesky/sysroot/usr/bin/i686-elf-bluesky/lib/ -isystem /usr/bluesky/sysroot/usr/bin/i686-elf-bluesky/include -isystem /usr/bluesky/sysroot/usr/bin/i686-elf-bluesky/sys-include   
checking for suffix of object files... configure: error: in `/usr/bluesky/src/gcc-build/i686-elf-bluesky/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
make[1]: se sale del directorio «/usr/bluesky/src/gcc-build»
make: *** [all] Error 2

I think the problem is dependency-related...

Here's the relevant part of /usr/bluesky/src/gcc-build/i686-elf-bluesky/libgcc/config.log:

Code:

configure:3389: /usr/bluesky/src/gcc-build/./gcc/xgcc -B/usr/bluesky/src/gcc-build/./gcc/ -B/usr/bluesky/sysroot/usr/bin/i686-elf-bluesky/bin/ -B/usr/bluesky/sysroot/usr/bin/i686-elf-bluesky/lib/ -isystem /usr/bluesky/sysroot/usr/bin/i686-elf-bluesky/include -isystem /usr/bluesky/sysroot/usr/bin/i686-elf-bluesky/sys-include    -o conftest -g -O2   conftest.c  >&5
/usr/bluesky/src/gcc-build/./gcc/as: 106: exec: -o: not found
configure:3392: $? = 1
configure:3580: checking for suffix of object files
configure:3602: /usr/bluesky/src/gcc-build/./gcc/xgcc -B/usr/bluesky/src/gcc-build/./gcc/ -B/usr/bluesky/sysroot/usr/bin/i686-elf-bluesky/bin/ -B/usr/bluesky/sysroot/usr/bin/i686-elf-bluesky/lib/ -isystem /usr/bluesky/sysroot/usr/bin/i686-elf-bluesky/include -isystem /usr/bluesky/sysroot/usr/bin/i686-elf-bluesky/sys-include    -c -g -O2  conftest.c >&5
/usr/bluesky/src/gcc-build/./gcc/as: 106: exec: -o: not found
configure:3606: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3620: error: in `/usr/bluesky/src/gcc-build/i686-elf-bluesky/libgcc':
configure:3623: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

max · **Posted:** Thu Nov 06, 2014 4:38 am

KemyLand wrote:

How is it possible that something like *GNU* Autotools is so incompatible with itself?

Because *GNU* is not the holy grail, and autotools are buuull-****.

KemyLand wrote:

I ran automake/autoconf/autoreconf/aclocal on the root dir, first with the recommended versions. Then make

Why the hell would you want to do that? Didn't you hear what sortie said?

You *only* want to run for example automake where you changed the Makefile.in/am. The rest is already autotool'd and doesn't need your attention.

Also, don't make a dodekillion of new posts, edit your old ones.

KemyLand · **Posted:** Thu Nov 06, 2014 4:58 am

max wrote:

KemyLand wrote:

How is it possible that something like *GNU* Autotools is so incompatible with itself?

Because *GNU* is not the holy grail, and autotools are buuull-****.

Yes, its truly BS, but that's what GNU uses, (and I use GNU) so I have no alternative but to criticize it

max wrote:

KemyLand wrote:

I ran automake/autoconf/autoreconf/aclocal on the root dir, first with the recommended versions. Then make

Why the hell would you want to do that? Didn't you hear what sortie said?

You *only* want to run for example automake where you changed the Makefile.in/am. The rest is already autotool'd and doesn't need your attention.

It was a complete mistake, but I've managed to return to my "checkpoint" :wink:

max wrote:

Also, don't make a dodekillion of new posts, edit your old ones.

Already done :wink:

KemyLand · **Posted:** Fri Nov 07, 2014 11:57 am

Finally resolved all in the 4th try! $\:D/$

I was trying to use $SYSROOT/usr/bin as prefix, when it was $SYSROOT/usr/toolchain #-o

Thanks to all of you for you help!

OSDev.org

Error while building OS-Specific Toolchain

Who is online