I'm just porting my OS to x86_64 and I'm stuck with some toolchain problems.
First of all, I built a toolchain, i.e. binutils and gcc that are x86_64 targeted. Since my build system is a i686 pc with cygwin, I need to build cross compilers. My OS uses ELF executables, so I need a x86_64-elf targeted cross compiler. But when I configure binutils and gcc, it tells me that --target=x86_64-elf is not supported. So I followed this hint:
http://www.osdev.org/osfaq2/index.php/GCC Cross-Compiler
Now I got a cross compiler that is x86_64-pc-linux-gnu targeted, but without any Linux libraries. It works fine when I compile my source files manually using options -nostartfiles and -nostdlib. But for my OS I use autoconf to check for the presence of a compiler and tries to compile a c++ file to check if this compiler works. In this case it doesn't work because my auto generated configure script tries to compile a Linux executable, which doesn't work without the libraries.
Does anyone know how to create a toolchain that runs on i686 cygwin, works with autoconf and creates plain x86_64 ELF executables?
Thanks in advance!
x86_64 toolchain
Re:x86_64 toolchain
Hmmm... interesting problem. While I'm probably the main "maintainer" of that FAQ page, I have absolutely zero experience with autoconf... as it has never been part of my toolchain.
That you don't have any "libraries" (i.e., includes) is the normal case when you're making your own OS. The includes are OS-dependent, so you will have to port or write a C library to go with your OS. If autoconf didn't balk while you were working on 32bit, your 32bit toolchain was "illegal" anyway as it dragged in the C lib from Cygwin (which probably isn't what you want).
Now, you could somehow hack autoconf to skip the compiler check - but as far as I understand autoconf, that would pretty much defeat the purpose as many subsequent tests also depend on the compiler...
So I throw in two questions of my own to the autoconf wizards (if any are around): Why would anyone use autoconf for his OS project, and is that at all "legal" if you don't have a C lib / runtime of your own yet?
That you don't have any "libraries" (i.e., includes) is the normal case when you're making your own OS. The includes are OS-dependent, so you will have to port or write a C library to go with your OS. If autoconf didn't balk while you were working on 32bit, your 32bit toolchain was "illegal" anyway as it dragged in the C lib from Cygwin (which probably isn't what you want).
Now, you could somehow hack autoconf to skip the compiler check - but as far as I understand autoconf, that would pretty much defeat the purpose as many subsequent tests also depend on the compiler...
So I throw in two questions of my own to the autoconf wizards (if any are around): Why would anyone use autoconf for his OS project, and is that at all "legal" if you don't have a C lib / runtime of your own yet?
Every good solution is obvious once you've found it.
Re:x86_64 toolchain
If you make a cross-compiler the autoconf should never attempt to compile it and run it. If it tries to compile a linux executable, tell it not to.XenOS wrote: In this case it doesn't work because my auto generated configure script tries to compile a Linux executable, which doesn't work without the libraries.
Does anyone know how to create a toolchain that runs on i686 cygwin, works with autoconf and creates plain x86_64 ELF executables?
I'm not familiar with autoconf so I can't give you any hints on where to look exactly, but there should be something telling it "I'm compiling on this computer for that computer, don't bother testing". Try the sources for glibc for example, they have to run without glibc to link against.
Re:x86_64 toolchain
Quickly sifting through the autoconf manual, it seems as if a great many of the tests rely on the compiler being able to generate an executable, even when not depending on actually running that executable.
I'd say, put autoconf on ice until you at least got the C runtime environment done so you can actually compile executables for your OS. Even then, you'll have to take care to only use tests that do not rely on running your exe's.
Which brings us back to the question, why autoconf for an OS project? This tool is for adapting source to the variety of Unix flavours out there - and as such pretty much worthless when used for your OS project, or isn't it?
I'd say, put autoconf on ice until you at least got the C runtime environment done so you can actually compile executables for your OS. Even then, you'll have to take care to only use tests that do not rely on running your exe's.
Which brings us back to the question, why autoconf for an OS project? This tool is for adapting source to the variety of Unix flavours out there - and as such pretty much worthless when used for your OS project, or isn't it?
Every good solution is obvious once you've found it.
Re:x86_64 toolchain
autoconf has turned out to be quite useful for me - at least usually. My OS should run on quite different types of architectures, including i386 and x86_64. After some trial and error I found that using autotools is perfect for generating an configure script and makefiles. That's why I ended up using it. But if anyone has a better suggestion, please let me know.
I wonder why there is no plain x86_64-elf target support in gcc. I compiled a i686-elf targeted cross gcc and it works fine without any libraries. But doing exactly the same for x86_64 doesn't work, that's why i compiled a x86_64-linux targeted gcc. The i686-elf-gcc works fine with autoconf, although it can't create executables that run on my computer. It simply compiles autoconf's test file and produces a plain elf executable.
I wonder why there is no plain x86_64-elf target support in gcc. I compiled a i686-elf targeted cross gcc and it works fine without any libraries. But doing exactly the same for x86_64 doesn't work, that's why i compiled a x86_64-linux targeted gcc. The i686-elf-gcc works fine with autoconf, although it can't create executables that run on my computer. It simply compiles autoconf's test file and produces a plain elf executable.
Re:x86_64 toolchain
Although it took me some time, I finally managed to create a toolchain that fits my needs. I found I patch for binutils and gcc which allows to configure and build them with --target=x86_64-elf, creating plain elf files which do not rely on any OS specific libraries. However, there are some libraries like libstdc++ which did not compile but autoconf seemed to rely on them. So I simply took them from some x86_64 machine running Linux and copied them to my i686 cygwin machine. Now the whole thing works as it should and I can configure my kernel with either --host=i686-elf or --host=x86_64-elf, creating the correct executables.
Re:x86_64 toolchain
Could you make a patch of that and put it on the OS FAQ wiki? There'd be a lot of people wanting that patch. Also, you could send it to the gcc maintainers, they'd probably be interested.XenOS wrote: Although it took me some time, I finally managed to create a toolchain that fits my needs. I found I patch for binutils and gcc which allows to configure and build them with --target=x86_64-elf, creating plain elf files which do not rely on any OS specific libraries. However, there are some libraries like libstdc++ which did not compile but autoconf seemed to rely on them. So I simply took them from some x86_64 machine running Linux and copied them to my i686 cygwin machine. Now the whole thing works as it should and I can configure my kernel with either --host=i686-elf or --host=x86_64-elf, creating the correct executables.
Re:x86_64 toolchain
In fact, these patches are already available on the web for almost one year and I wonder why they haven't been merged into the binutils / gcc source trees by now. I found them here:
http://sourceware.org/ml/binutils/2005-03/msg00353.html
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01286.html
After applying these patches, both binutils and gcc can be configured with --target=x86_64-elf. I'll try to put them on the Wiki, too.
http://sourceware.org/ml/binutils/2005-03/msg00353.html
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01286.html
After applying these patches, both binutils and gcc can be configured with --target=x86_64-elf. I'll try to put them on the Wiki, too.
Re:x86_64 toolchain
I added the links to the Cross-Compiler page.
Every good solution is obvious once you've found it.