Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I have just been following the OS Specific Toolchain tutorial in the wiki, which appears to be very well writen. I am just having a slight problem trying to switch to an x86_64 target for binutils (specifically LD). Configure works fine, but when running make in cygwin, I get the following error:
ecaracal_x86_64.o: In function `gldcaracal_x86_64_after_parse':
/usr/src/build-binutils/ld/../../binutils-2.18/ld/emultempl/ia64elf.em:37: undef
ined reference to `_bfd_elf64_ia64_after_parse'
collect2: ld returned 1 exit status
I guess this is a problem with me converting the i586 target to x86_64, and the problem probably resides somewhere in the 'Edit configure.tgt' or 'Edit Makefile.in' steps.
Does anyone know where I should look to see what I did wrong? Oh - by the way, I have successfully cross-compiled a plain x86_64 binutils and gcc using the same installation of Cygwin (I just wanted my own toolchain which can be customised further in the future).
As it is a new day, I am going over all the steps of the tutorial again to ensure I didn't miss anything. I'll let you know if it works. I'll also make sure that anything I altered contains x86_64 rather than IA64, so thanks for that hint.
Nope - same error. I am going to have a play with the compiler and perhaps follow the tutorial using the i586-elf target to get more familiar with it before trying to be a smart arse and adapt the tutorial to x86_64.
/usr/src/build-binutils/ld/../../binutils-2.18/ld/emultempl/ia64elf.em:37: undef
ined reference to `_bfd_elf64_ia64_after_parse'
That is seriously wrong. There is some Itanium stuff (IA64) being compiled in. Did you in one place accidentally write ia64 instead of x86_64? Remember that for Intel IA32 is x86, IA64 is Itanium. (And a heap of junk it is too!)
Ok - my transposition mistake from i[3-7]86 to x86_64. I have just replaced binutils-2.18 with a freshly downloaded version to undo all of my changes and am giving it a go from scratch. Chances are I copied something from another section of a file and adapted it to my cross compiler entry. I must have copied from an IA64 rather than x86_64 target. I'll obviously be a bit more cautious this time!
I have just successfully completed the tutorial for GCC and Binutils for the i586 version of the compiler by following the tutorial to the letter. I can't emphasise this enough - if you miss something, you generally don't find out until 20 minutes in to the compilation .
I'm going to write down what I do with the conversion to x86_64 now and if it all works will post the changes I had to make.
I've just tested targeting a x86_64 target and following the instructions on the wiki seems to work (it appears --enable-64-bit-bfd isn't actually required to produce a libbfd that can handle elf64, at least in binutils 2.18). You obviously need to make the necessary changes. Some important ones to note are:
2) gas/configure.tgt: should still have case statement for i386-*-myos* (rather than x86_64) as the variable generic_target is formed from the variable cpu_type, where cpu_type is i386 for i[3-7]86 and x86_64 (defined further up the file)
3) ld/configure.tgt: targ_emul=myos_x86_64
You can also add targ_extra_emuls=myos_i386 if you like
4) define the emulation(s) as usual. I used elf_x86_64.sh as an emulparams template to base the specific one on. Add to Makefile.in as usual, watch those spaces/tabs and curly/round brackets.
Thanks for trying out the tutorial. Please let me know how you got on.
jnc100 wrote:2) gas/configure.tgt: should still have case statement for i386-*-myos* .
Dammit - I knew it was me doing somthing wrong - the actual tutorial is very good, though. I'll just have another go now. Although I am very familiar with the toolchain from the build, link, assemble and objdump point of view, all this automatic configuration stuff is Greek to me at the moment .
Thanks, John - I now have a working binutils and am about to apply the same theory to gcc. The only line I *know* I had wrong the first time was that gas/configure.tgt, which is odd seeing as the build always failed at the point of configuring ld. All that matters now is that it worked, though!
Ok - at the risk of appearing to like talking to myself (4 messages in a row ), I'll give a progress report. Using GCC 4.2.2 and Binutils 2.18, I have now successfully build toolchains for my OS. I have tried i586-pc-caracal and x86_64-pc-caracal (someone previously pointed out the -m32 switch, but I wanted separate chains for a different project anyway) and both worked very nicely.
If anyone else is doing the same and it doesn't work first time, my advice is to read the error messages carefully and persist, because it does work.
Just a thought - how about a grid with tested versions of the compiler and binutils, a la GCC Cross-Compiler? I could add this to the article, or leave it to jnc100, if you like.
AJ wrote:I have now successfully build toolchains for my OS
Good to hear it. Once again, thanks for testing the tutorial.
AJ wrote:Using GCC 4.2.2 and Binutils 2.18
I wrote it for 4.2.1/2.18, so that's another setup to put a tick by.
AJ wrote:how about a grid with tested versions of the compiler and binutils
Be my guest, if you think its necessary. Personally, I'd be more interested in something showing success with various combinations of gcc/binutils, processor, object type, whether an existing emulation was simply copied or a new one written from scratch (emultempl + scripttempl also), additions to the newlib scripts and things like that.
OK - I'll add the versions I have used to the discussion page for your wiki article. If we get enough people trying various things like that, perhaps we can then decide how to lay out a success/failure grid of some sort.
.
.
), I'll give a progress report. Using GCC 4.2.2 and Binutils 2.18, I have now successfully build toolchains for my OS. I have tried i586-pc-caracal and x86_64-pc-caracal (someone previously pointed out the -m32 switch, but I wanted separate chains for a different project anyway) and both worked very nicely.