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'm trying to move my project (currently the BareBones C example with a bit of my own stuff) from my Linux VM to Cygwin. Everything builds fine under Linux, but I'm getting a weird error from as under Cygwin:
If I comment out the offending line, it assembles ok, but then ld fails with "PE operation on non-PE file", but I gather this is part of the reason to build a cross-compiler (maybe next week ).
Top three reasons why my OS project died:
Too much overtime at work
Got married
My brain got stuck in an infinite loop while trying to design the memory manager
The as error has the same reason as the ld error: You are not compiling for an ELF target.
.comm accepts a third parameter only for ELF targets (as writ in the binutils/as manual). Once you have the cross-compiler set up, your woes will be gone.
(You should have built a cross-compiler under Linux, too, if only to avoid including standard headers, linking in the C runtime or getting funny sections in your object files by accident. You just were lucky. )
Every good solution is obvious once you've found it.
Solar wrote:
The as error has the same reason as the ld error: You are not compiling for an ELF target.
.comm accepts a third parameter only for ELF targets (as writ in the binutils/as manual). Once you have the cross-compiler set up, your woes will be gone.
(You should have built a cross-compiler under Linux, too, if only to avoid including standard headers, linking in the C runtime or getting funny sections in your object files by accident. You just were lucky. )
Follow the Wiki and it's eeaaasssssyyyyy.
BTW to make a cross compiler for m68K, would I just change the target from i386-elf to m68K-elf?
configure: error:
The following requested languages were not found: c++
The following languages were available: c treelang
Configure in /usr/src/build-gcc/gcc failed, exiting.
configure: error:
The following requested languages were not found: c++
The following languages were available: c treelang
Configure in /usr/src/build-gcc/gcc failed, exiting.
Did you download & unpack the gcc-g++ package for your version?
configure: error:
The following requested languages were not found: c++
The following languages were available: c treelang
Configure in /usr/src/build-gcc/gcc failed, exiting.
Did you download & unpack the gcc-g++ package for your version?
Solar wrote:
The as error has the same reason as the ld error: You are not compiling for an ELF target.
It's a pretty misleading error message then.
"You're using an unsupported featu... uhh, I mean, I see junk on that line!" [me=Colonel Kernel]smacks the GNU programmers who don't know how to write good error messages [/me]
I'll work on the cross-compiler next week... In the meantime, I was planning to switch from as to nasm -- will I run into the same problem (i.e. -- do I have to cross-compile nasm as well)?
Top three reasons why my OS project died:
Too much overtime at work
Got married
My brain got stuck in an infinite loop while trying to design the memory manager
The reason you have to recompile AS etc is because they work on X computers for Y targets with probably Z ways to do all things in there. You just disagree with the cygwin goal of Z and Y, but chose it because of X. Since their Y is your X, but your Y is different, you can use this compiler to make your own
Nasm has one input (nasm type source), multiple outputs that are all supported, and only one way to do it (just g*ddamn compile). That makes it a lot easier to get working decently
GNU as is part of binutils, which in turn is the backend of GCC. No matter whether you want to use as or NASM for the ASM parts, you still need the binutils compiled for the target in order to have GCC running.
If you want to have ELF output, GCC must be configured to support it. The easiest way is to follow the GCC Cross-Compiler tutorial, since that is valid on any platform regardless.
As for the as error message: as configured for x86-ELF is a completely different program from as configured for m68k-COFF, for example. They don't even know about the feature set of the other. as not configured for ELF doesn't know that as configured for ELF accepts a third argument to .comm, so it can't tell you more than that...
Every good solution is obvious once you've found it.
Solar wrote:
GNU as is part of binutils, which in turn is the backend of GCC. No matter whether you want to use as or NASM for the ASM parts, you still need the binutils compiled for the target in order to have GCC running.
I know -- I just want to use nasm for the "pure asm" parts of my project. I converted my modified BareBones over last night (after a bit of futzing around... if I strip it down to the original example, maybe I can post the changes on the wiki) and it assembles ok, but goes back to the linker error... which I guess is expected, except for the fact that I told nasm to output PE format, so I'm not sure what ld is really complaining about...
If you want to have ELF output, GCC must be configured to support it. The easiest way is to follow the GCC Cross-Compiler tutorial, since that is valid on any platform regardless.
I actually don't necessarily want ELF output. My kernel image is a flat binary file that just uses the basic multiboot header to get itself loaded correctly by GRUB. So, the only choice to make is what intermediate format to use as the output of GCC/as and nasm (and consequently as the input to ld). Although I understand that I need to create a cross-compiler (which I will do as soon as I have time), I still don't really understand why the lack of one affects ld in this particular manner. No one has really explained that as far as I can see.
Top three reasons why my OS project died:
Too much overtime at work
Got married
My brain got stuck in an infinite loop while trying to design the memory manager
Even though nasm allows you to compile for PE-format, ld on cygwin will still bomb because its set to only support PE. You can either create a barebones gcc and ld for the desired output format you want or you can use a simple hack with make.
I set the output format in my linker script to "PE-i386" and then assemble my nasm code as gnuwin32 and C code as PE format (.EXE). I then use objcopy to convert it to a .bin file and it works perfectly. You can get objcopy to output whatever format you want: be it elf, binary, coff, etc.