Binary files and GCC

Brynet-Inc · Post by **Brynet-Inc** » Tue Nov 06, 2007 10:24 am

Didn't you read my post? You need to setup a cross-compiler..

Look at the Wiki article I posted...

AJ · Post by AJ » Tue Nov 06, 2007 11:23 am

XCHG wrote:By the way, I just looked at the output object file that GCC produced and it is clearly a Win32 PE file.

Firstly, I would suggest reading Brynets post. Secondly, I think that the reason for that is you still have the MinGW version of GCC somewhere in your PATH environment variable. As Cygwin includes your Windows PATH variable in the Bash PATH variable, you are using the wrong version of GCC.

Cheers,
Adam

XCHG · Post by **XCHG** » Wed Nov 07, 2007 11:18 am

Brynet-Inc wrote:Didn't you read my post? You need to setup a cross-compiler..

Look at the Wiki article I posted...

Well I already have looked at the Wiki link that you provided but to me it is useless. I have installed GCC utilities in Windows and my whole OS Development environment is in Windows. In that article, it is assumed that my OS Development environment is in *nix. I don't need that really

What I want to know is for someone to tell me, since I have not programmed a working project in C before, what I have to do step by step to get GCC to give me a flat binary output. I am asking a straightforward question and I am expecting an answer as straightforward as that. Not like "First you download Cygwin and then you control the temperature of the sun with that. Well that is useless so what you have to do is to download this package and that which are basically useless. So you will have to start from scratch. Oh by the way, GCC won't produce flat binary files. I'm sorry!"

To make this clearer:

1) I only have Cygwin's port of GCC and no other C compiler.
2) I do have

gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

3) I do have

GNU objcopy 2.17.50 20060817

Brynet-Inc · Post by **Brynet-Inc** » Wed Nov 07, 2007 2:06 pm

You need to setup a cross compiler to output binary files, or at least make the tools like objdump/objcopy aware of them!

The GCC/binutils shipped with MinGW and Cygwin is heavily modified and only handles PE executables..

How can we be more straightforward? setup a cross-compiler... the instructions are on the Wiki.

XCHG · Post by **XCHG** » Wed Nov 07, 2007 2:44 pm

For me (who hasn't programmed a working project in C before), they are not straightforward enough

However, I appreciate your help.

frank · Post by **frank** » Wed Nov 07, 2007 3:59 pm

XCHG wrote:For me (who hasn't programmed a working project in C before), they are not straightforward enough However, I appreciate your help.

If you follow the instructions for producing a Cross Compiler word for word then you will get what you want. The instructions work in cygwin just fine. In fact I think they are pretty much written for cygwin. Now go though the instructions step by step. If you encounter any problems or need any help just ask, but at least try.

Solar · Post by **Solar** » Thu Nov 08, 2007 1:03 am

XCHG wrote:Well I already have looked at the Wiki link that you provided but to me it is useless. I have installed GCC utilities in Windows and my whole OS Development environment is in Windows. In that article, it is assumed that my OS Development environment is in *nix.

As frank already pointed out, the GCC Cross-Compiler tutorial in the Wiki was written for Cygwin users.

XCHG wrote: Then when I try to link the "c1.o" and make a flat binary file, I get this error:
Code: Select all
C:\c>ld -T link.ld c1.o -o c1.bin
ld: cannot perform PE operations on non PE output file 'c1.bin'.
Could anybody tell me what I am doing wrong, please?

In the Wiki, I wrote: Why an OS developer should build a cross-compiler

Creating a dedicated (cross-) compiler for your OS development work can save you many headaches. If...

...your system compiler drags in references to alloca() or other OS-dependent things,

...Cygwin complains about "PE operation on non-PE file",

...

XCHG · Post by **XCHG** » Thu Nov 08, 2007 4:53 am

Solar,

I have already read those but I don't see what your point is and how it is connected to my problem. Anyway...

Code: Select all

root@vandadpc ~
$ export PREFIX=/usr/cross

root@vandadpc ~
$ export TARGET=i586-elf

root@vandadpc ~
$ cd /usr/src

root@vandadpc /usr/src
$ mkdir build-binutils build-gcc

root@vandadpc /usr/src
$ cd /usr/src/build-binutils

root@vandadpc /usr/src/build-binutils
$ ../binutils-2.16.1/configure --target=$TARGET --prefix=$PREFIX --disable-nls
creating cache ./config.cache
checking host system type... i686-pc-cygwin
checking target system type... i586-pc-elf
checking build system type... i686-pc-cygwin
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for gnatbind... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... tail +16c $$f1 > tmp-foo1; tail
+16c $$f2 > tmp-foo2; cmp tmp-foo1 tmp-foo2
checking for correct version of gmp.h... no
checking for bison... no
checking for bison... no
checking for byacc... no
checking for yacc... no
checking for gm4... no
checking for gnum4... no
checking for m4... no
checking for flex... no
checking for flex... no
checking for lex... no
checking for makeinfo... makeinfo
checking for i686-pc-cygwin-ar... no
checking for ar... ar
checking for i686-pc-cygwin-as... no
checking for as... as
checking for i686-pc-cygwin-dlltool... no
checking for dlltool... dlltool
checking for i686-pc-cygwin-ld... /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../
i686-pc-cygwin/bin/ld.exe
checking for i686-pc-cygwin-nm... no
checking for nm... nm
checking for i686-pc-cygwin-ranlib... no
checking for ranlib... ranlib
checking for i686-pc-cygwin-windres... no
checking for windres... windres
checking for i686-pc-cygwin-objcopy... no
checking for objcopy... objcopy
checking for i686-pc-cygwin-objdump... no
checking for objdump... objdump
checking for i586-elf-ar... no
checking for i586-elf-as... no
checking for i586-elf-dlltool... no
checking for i586-elf-ld... no
checking for i586-elf-nm... no
checking for i586-elf-ranlib... no
checking for i586-elf-windres... no
checking whether to enable maintainer-specific portions of Makefiles... no
checking if symbolic links between directories work... ../binutils-2.16.1/config
ure: line 4866: cmp: command not found
no
../binutils-2.16.1/configure: line 4962: cmp: command not found
updating cache ./config.cache
creating ./config.status
creating Makefile

root@vandadpc /usr/src/build-binutils
$ make all
MAKE Version 5.2  Copyright (c) 1987, 1998 Inprise Corp.
Error makefile 187: Command syntax error
Error makefile 191: Command syntax error
Fatal makefile 10203: No terminator specified for in-line file operator

root@vandadpc /usr/src/build-binutils
$

Seems like I have not downloaded some of the packages. The problem before was that I was not running the Cygwin's shell and instead was doing all the commands in Windows' CMD.

Solar · Post by **Solar** » Thu Nov 08, 2007 6:00 am

XCHG wrote:Solar,

I have already read those but I don't see what your point is and how it is connected to my problem.

Have you read Brynet-Inc.'s post? Both MingW and Cygwin are targeted at creating Windows executables, with all kinds of problems attached when you try to output flat binary, or ELF.

A couple of years (!) ago, we (back at MT at that time) stopped explaining the way around all the footfalls of various Windows compilers, and settled on strongly recommending the Cygwin / cross-compiler approach. All in all, it did work out. The tutorial has been proven correct dozens of times over. I still occassionally build a cross-compiler just to check it still works as advertised.

That being said, I would recommend you deinstall Cygwin (and MingW or whatever you had installed beforehand), and start over with a default Cygwin installation, with only GCC being added to the default packages. That should really suffice.

Brynet-Inc · Post by **Brynet-Inc** » Thu Nov 08, 2007 6:47 am

XCHG wrote:MAKE Version 5.2 Copyright (c) 1987, 1998 Inprise Corp.

Sanitize your environment variables!!

And be sure to obtain the source tarballs from their "official" locations...

http://ftp.gnu.org/gnu/binutils/binutils-2.18.tar.gz
http://ftp.gnu.org/gnu/gcc/

Solar · Post by **Solar** » Thu Nov 08, 2007 7:00 am

Brynet-Inc wrote:
XCHG wrote:MAKE Version 5.2 Copyright (c) 1987, 1998 Inprise Corp.

YIKES! I missed that one... with an environment like that, you can't be at all sure what tools ./configure drags to your doorstep... check Cygwin's PATH, and throw out everything that doesn't belong. Then use "set" to have a look at your environment, and again throw away any crud from other, unrelated environments...

XCHG · Post by **XCHG** » Sat Nov 10, 2007 11:40 am

Um thanks guys for trying to help me. I really appreciate it. The problem is that most of the things you say are like "bla bla bla" to me. I, as have already said, am not a C programmer and I have no idea why I should be doing all these to output a simple binary file

I have already downloaded the core files that you guys pointed out, bin utils and GCC and whatnot. I followed the instructions and I got the same errors as before. However, the only thing that would help me is to give me a step-by-step instruction from where you download the Cygwin's setup file to what packages you download, what you will do after that and etc. Again, I understand this could take a long time for someone to write and if nobody is willing to help, then I'm fine with it

NOT.

Brynet-Inc · Post by **Brynet-Inc** » Sat Nov 10, 2007 12:30 pm

Why are you skipping large portions of what we've said? and what does programming in C have to do with cleaning up your environment variables?

How have you gotten this far in life?

Re-read this topic, think about what was said.. it's definitely not rocket science, many have been able to follow the cross-compiler Wiki article without issues.

XCHG · Post by **XCHG** » Sat Nov 10, 2007 2:03 pm

Perhaps because I am not used to having, quote, 16,272 files in 977 folders for a simple compiler just to output an even more plain binary file. Now you may argue that GCC is not a "simple" compiler but to me, based on what I want it to do, it is.

Brynet-Inc · Post by **Brynet-Inc** » Sat Nov 10, 2007 6:06 pm

But you're ignoring what GCC and binutils are... a suite of portable software development utilities.

That means there is support code for various different operating systems, architectures and binary files... did you expect a single executable would handle them all at once?

MinGW and Cygwin developers clearly never considered anyone would want "flat binaries", COFF/PE is probably all they targeted..

Solutions? Setup an environment without conflicting variables, and then retarget binutils/GCC!

(Borland make is not going to like a GNU generated Makefile.. get the picture? )

Good luck.