OSDev.org

Posted: **Wed Apr 05, 2006 12:34 pm**

I was wondering if anyone has managed to build a cross-compiler exactly as described in the FAQ with Cygwin?
I always end up with some error messages when 'making' binutils (tried various versions): couldn't make stderr distinct from stdout... and then it exits.

And anyway, I found something strange. For NASM, I have the option -f elf, in my linker script elf32-i386 and when doing the cross-compiler, I use export TARGET=i586-elf. Shouldn't i use i386 also when making the cross-compiler? Because I'm buying an old test-machine, and it has an i486, so I'm not sure about using i586...

If Cygwin wouldn't work, I could also install Linux on my test machine, although it would be very slow, but am I the only scr*wed one that still (has to) uses WinXP/Cygwin?

Thanks for all your comprehension in some of my recent posts,

Candamir/Robin

Posted: **Wed Apr 05, 2006 1:02 pm**

The cross-compiler has been explicitly created with Cygwin in mind, and was frequently verified whenever threads like this popped up. It does work with Cygwin, at the very least for the binutils / GCC combinations stated on the page.

As for 586, 386 or 686, use whatever suits you. I chose 586 when writing that tutorial, for some architectural decision I've long since forgotten.

Posted: **Wed Apr 05, 2006 6:25 pm**

Solar wrote: As for 586, 386 or 686, use whatever suits you. I chose 586 when writing that tutorial, for some architectural decision I've long since forgotten.

But I suppose that I have to use the same architecture on both...

Ah, now I understand: I think there is one part of that article that is a little bit confusing:

There are two sections which tell you which versions to use of binutils and gcc, and I think that one is meant to tell the versions you need to have /installed/, and the other one the versiones you'll need to /compile/. Is that right?

I think this is the table of version you need to have installed right?

This has been tested to work with the below combinations of binutils and gcc:

Code: Select all

       3.4.3      3.4.4      3.4.5      4.0.0      4.0.1      4.0.2 
 2.16      OK      OK      OK      OK      OK      OK 
 2.16.1      OK      OK      OK      OK      OK      OK

And then, the versions listed right after the bootstrap title are the ones you need to compile?

Are my suppositions correct?

Posted: **Wed Apr 05, 2006 8:17 pm**

Now I know what's the problem (the first part of it): When you have DJGPP on your machine and switch to cygwin, it still invokes the djgpp gcc (somehow) and also ld. I had to uninstall djgpp and download gcc and make (from cygwin setup.exe) first, and then the build process worked quite well a time, but then it stopped because it couldn't read a lex file. I looked it up on the faq and looked up that this should only happend with versions < 3.4.3, but I use 3.4.4 Maybe it has something to do with the fact that I only downloaded gcc-core; I don't know. I'll try the build process again tomorrow and tell you how it worked (with bison and flex).

@Solar: I think it's you working on that particular faq article, so I don't want to mess up your work, but I think the advice for DJGPP users would be _very_ useful.

Posted: **Wed Apr 05, 2006 10:27 pm**

Candamir wrote: @Solar: I think it's you working on that particular faq article, so I don't want to mess up your work, but I think the advice for DJGPP users would be _very_ useful.

Edit away. I'm a bit preoccupied at the moment but will have a check on what you edit, so don't fear you could break something.

Posted: **Thu Apr 06, 2006 1:22 am**

your problem with GCC messing up is likely to be due of the %PATH% environment variable giving DJGPP's directory preference over cygwin's. I don't know if there's a "which" equivalent in windows (under unix, it reveals the name of the program being actually called e.g. "which gcc" says "/usr/bin/gcc") but just calling "SET" under the dos prompt should tell you what is going to be used.

Posted: **Thu Apr 06, 2006 6:01 am**

That's why I added a few lines in the FAQ saying that one should uninstall DJGPP, as I did, because I wasn't aware at first that some of my windows environment variables are included. And anyway, why would you want DJGPP with Cygwin?

Posted: **Thu Apr 06, 2006 9:17 am**

Candamir wrote: And anyway, why would you want DJGPP with Cygwin?

maybe because you're using the same machine for developing MS-DOS programs with DjGPP and an OS with cygwin

or maybe because you fear that Cygwin install will not fulfill your hopes and want to save the hassles of reinstalling DjGPP afterwards ...
Both are very unlikely, i heartfully admit, so uninstalling DJ first is certainly a GoodIdea (tm)

Posted: **Thu Apr 06, 2006 4:21 pm**

I think everything's running correctly now, but binutils still won't compile. I use gcc 3.3.4 and have now tried to compile binutils 2.14, 2.15 and 2.16.1. The configure script runs smoothly and so does the make script during quite a long time, but when it's building the ld part, soon gcc spits out errors during three seconds (?!) for syntax errors in a file called eelf_i386.c (yes, it's called eelf, not elf). In the FAQ it says the following:

Problems have been reported on trying to build bintils 2.14 with Cygwin GCC < 3.3.3.3 as host compiler, as well as on trying to build binutils <= 2.15 with GCC 4.x as host compiler.

Is it possible that this is referring to this error?

Thanks

Edit: BTW, the table of version numbers /and/ the list of packages we need to download refer both to packes being built? Doesn't make much sense to me, confusing...

Edit: I downloaded and built GCC 4.1.0 (as host) and afterwards tried to create my bootstrap binutils, and still the same results... do I have to apply some patches or what? BTW, when installing gcc, afterwards I can remove the directory where I built it, can't I?

BTW, tomorrow I can try compiling for a different architecture as target (I've thought about i386). Do you think it would help? And is elf32-i386 in my ld linker script aequivalent to i386-elf as target when creating my cross-compiler or must I invert the order?

Thanks

Posted: **Fri Apr 07, 2006 12:28 am**

Candamir wrote: Is it possible that this is referring to this error?

Possible but unlikely, as you reproduced the problem with GCC 4.x.

Which confuses me, by the way. Cygwin provides a 3.4.x series GCC for quite some time now. How did you get hold of either a 3.3.x or a 4.x Cygwin compiler?

What is the target you tried compiling for? What is the exact error message? (Not the whole list, just the first couple of lines.)

BTW, the table of version numbers /and/ the list of packages we need to download refer both to packes being built? Doesn't make much sense to me, confusing...

To me neither. Fixed.

I downloaded and built GCC 4.1.0 (as host) and afterwards tried to create my bootstrap binutils, and still the same results... do I have to apply some patches or what?

Try compiling a "hello world" program. Does it work?

BTW, when installing gcc, afterwards I can remove the directory where I built it, can't I?

Yes.

BTW, tomorrow I can try compiling for a different architecture as target (I've thought about i386). Do you think it would help?

Unlikely but possible.

Posted: **Fri Apr 07, 2006 5:40 am**

Well, sorry for posting wrong version numbers. I used 3.4.4, which was provided by Cygwin. I configured and built the 4.1.0 myself, downloading a package from gnu.org. Isn't that supposed to be possible? And I haven't written a helloworld program, but I do have compiled my kernel (with the host compiler), altough it wouldn't link afterwards. (That's why I want to build a cross compiler).

As there are thousands of errors in that file (probably just one that causes the other ones), I couldn't look at the first lines, but I'll try to do that during the morning. In case there was an error in there, would it be safe to play around with binutil's source code? Because it's just in the ld part, which I am particularly interested in...

Thanks...

Posted: **Fri Apr 07, 2006 5:59 am**

Candamir wrote: I configured and built the 4.1.0 myself, downloading a package from gnu.org. Isn't that supposed to be possible?

It certainly is, I was just trying to rule out some errors in your modus operandi.

And I haven't written a helloworld program, but I do have compiled my kernel (with the host compiler), altough it wouldn't link afterwards. (That's why I want to build a cross compiler).

Do I get this right: You have a Cygwin compiler toolchain (GCC version 3.4.4 plus binutils), which does not link a simple hello world, fails to build binutils from scratch, but does compile a GCC 4.1.0 without problems?

As there are thousands of errors in that file (probably just one that causes the other ones), I couldn't look at the first lines...

Redirect make's output to a file?

In case there was an error in there, would it be safe to play around with binutil's source code?

No. It should build OK, so the problem is with a 99.9% probability not in the binutils source. Tampering with that would perhaps solve the symptom, but not cure the problem.

Posted: **Fri Apr 07, 2006 2:28 pm**

Solar wrote: Do I get this right: You have a Cygwin compiler toolchain (GCC version 3.4.4 plus binutils), which does not link a simple hello world, fails to build binutils from scratch, but does compile a GCC 4.1.0 without problems?

Correct. As you've written it down, it also seems strange to me... The problem is not the compiler (I think so), because I can compile (and assemble) all of my kernel's files (which would be aequivalent to a hello-world because I've restarted from scratch), but ld complains: PE operations on non-PE file (the host ld). And actually, GCC 4.1.0 couldn't only compile, but also installed as default compiler and everything... Strange... But let me do the trick with redircting make's output and then I'll tell you. BTW, what is the option for redirecting the output? If you just know, could you please tell me? If not, I'll search it by myself...

Posted: **Fri Apr 07, 2006 3:03 pm**

Candamir wrote:
Solar wrote: Do I get this right: You have a Cygwin compiler toolchain (GCC version 3.4.4 plus binutils), which does not link a simple hello world, fails to build binutils from scratch, but does compile a GCC 4.1.0 without problems?
Correct. As you've written it down, it also seems strange to me... The problem is not the compiler (I think so), because I can compile (and assemble) all of my kernel's files (which would be aequivalent to a hello-world because I've restarted from scratch), but ld complains: PE operations on non-PE file (the host ld). And actually, GCC 4.1.0 couldn't only compile, but also installed as default compiler and everything... Strange... But let me do the trick with redircting make's output and then I'll tell you. BTW, what is the option for redirecting the output? If you just know, could you please tell me? If not, I'll search it by myself...

Are you SURE you've kept the host-gcc + host-binutils and cross-gcc + cross-binutils entirely fully separate?

make redirection:
make <something> ><output> 2>&1
replace <something> with whatever you want to make and <output> with your output file name. Bash logic requires you to first redirect 1 and then add 2 to 1...

Posted: **Fri Apr 07, 2006 4:20 pm**

Fully separated. I downloaded the *.tar.gz files to my /usr/src and decompressed them there and let them in their default folder. For compiling, I created new directories for them, as described in the FAQ. Is this what you mean? I followed exactly the procedure as described in the FAQ, so nothing strange should happen...(?)

Output from make attached as a screenshot (didn't manage make to do it for me

)

Edit: Seemed as it didn't work (to attach files). Here it goes:

Code: Select all

gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.16.1/ld -I. -D_GNU_SOURCE -I. -I../../binutils-2.16.1/ld -I../bfd -I../../binutils-2.16.1/ld/../bfd -I../../binutils-2.16.1/ld/../include -I../../binutils-2.16.1/ld/../intl -I../intl -g -O2 -DLOCALEDIR="\"/usr/cross/share/locale\""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -c eelf_i386.c
eelf_i386.c: In function 'gldelf_i386_get_script':
eelf_i386.c:1043: error: missing terminating " character
eelf_i386.c:1045: error: stray '\' in program
eelf_i386.c:1045: error: stray '\' in program
eelf_i386.c:1045: error: missing terminating " character
eelf_i386.c:1047: error: stray '\' in program
eelf_i386.c:1045: error: 'n' undeclared (first use in this function)
eelf_i386.c:1045: error: (Each undeclared identifier is reported only once
eelf_i386.c:1045: error: for each function it appears in)
eelf_i386.c:1047: error: expected ';' before 'nOUTPUT_ARCH'
eelf_i386.c:1049: error: stray '\' in program
eelf_i386.c:1051: error: stray '\' in program
....

OSDev.org

GCC Cross Compiler error in Cygwin

GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin

Re:GCC Cross Compiler error in Cygwin