Making The GCC Cross-Compiler

[abraker95]

You can install Linux in a Virtual Machine

I'm trying to avoid that because I'm running everything of a flash drive. Repartitioning it would be a pain.

[iansjack]

What's repartitioning got to do with running a Virtual Machine?

[Mikemk]

Here's a hint:

wiki.png (2.83 KiB) Viewed 3669 times

[Mikemk]

Been waiting a while to use that.

[abraker95]

What's repartitioning got to do with running a Virtual Machine?

Oops! Had something else on my mind at time of writing and seemed right at the moment, especially when in a hurry. Yea, I may actually consider a virtual machine, but I would really prefer not to use up the remaining space on my flash drive.

Here's a hint:

I know to search before asking, and I'm asking because nothing that I searched up works.

[dozniak]

Well unless I'm setting the PATH wrong, that method didn't work.

Have you verified that cygwin1.dll indeed resides where you pointed your PATH?

[abraker95]

Yes, unless the wrong PATH is set. I know there is 1 PATH in Cygwin (I set it), and 2 PATHs in Windows (Global & Local, I set local). I ran gcc in cmd and it id tell me that cygwin1.dll is missing, so I added cygwin/bin to Windows local PATH and it disappeared. However, it still tells me that it can't open the shared object file even after setting PATH in cygwin and I double checked that I did set it ($PATH).

[Mikemk]

Try running it from the cygwin shell.

[abraker95]

I did that after building the cross-compiler. Cmd opens the Cygwin shell anyway when I try to compile the sources in gcc.

[abraker95]

I played around with it some more, and here are how things are going starting with no PATH set and avoiding cygwin altogether:

Running from cmd it says that cygwin1.dll is not found. Going to the environment variables, I add G:\cygwin\bin locally and globally. It for some reason still doesn't want to see cygwin1.dll. However, copying cygwin1.dll to the system32 folder solves that problem, but gives me the "cannot open object file" error.
I don't know where gcc is looking for the object file, but I did get another way to this error too. Now removing cygwin1.dll from system32 folder, I decided to try a different approach. In cmd I a made a variable: set PATH="G:\cygwin\bin" and the cygwin1.dll error went away, and it went on giving me the "cannot open object file" error.

I'm not sure it has to do with environment variable entirely or partially, but I get the feeling it has something to do with gcc setting its path it searches for during build time. Is that the case?
I'd hate to rebuild gcc from scratch, but I might need to. What is the recommended version of gcc I should grab?

[Mikemk]

I'm not sure it has to do with environment variable entirely or partially, but I get the feeling it has something to do with gcc setting its path it searches for during build time. Is that the case?

I think it has something to do with the mix of unix-style and c:\ style paths.
I get the same errors from windows command prompt, and it works just fine from the MinGW MSYS prompt.

Code: Select all

cd /l/Documents/os # insert your path here
export PATH=$PATH:/usr/local/cross/bin
x86_64-elf-gcc ...
x86_64-elf-ld ...

Should be same for cygwin.

I'd hate to rebuild gcc from scratch, but I might need to. What is the recommended version of gcc I should grab?

I use gcc 4.7.2 with binutils 2.23.1, but that won't build under cygwin. It works under mingw, though.

[abraker95]

I'll try out MinGW's msys, but how come cygwin is giving such issues?

[Mikemk]

I'll try out MinGW's msys, but how come cygwin is giving such issues?

I have no idea.

[sortie]

Cygwin is trying to be a compatible Unix system under a foreign system as Windows, which is at many levels deeply incompatible for better or worse (often worse). As such, it's a second class citizen. MinGW tries to much more directly embrace Windows (hence the Minimal part) which results in a faster toolchain that integrates better with Windows.

Alternatively, you may well wish to try a real Unix system under which the toolchain will be more consistent and integrate better.

[TorakTu]

I'm trying to build the GCC Cross-Compiler, following the wiki. I got as far as
../binutils-2.23.2/configure --target=$TARGET --prefix=$PREFIX --disable-nls

Running this with Cygwin, it gave me this error:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot open output file confest.exe: Permission denied
*** The command 'gcc -o confest -g -O2 confest.c' failed.
*** You must set the environment variable CC to a working compiler.
rm: cannot remove 'conftest.exe': Permission Denied
rm: cannot remove 'a.exe': Permission Denied

I did some research and learned that it has to do something with Win7's file sharing, but I still failed to find a solution. Do not suggest Ubuntu, I don't have an available machine to install it right now.

I ran into this exact problem. You cannot run any of these Cygwin commands from a command prompt in windows. If you want to use the Cygwin GCC you must use the Cygwin window that comes with it. With a lot of googleing, with even DJGPP, I soon found out the same exact story of not being able to use it under a 64Bit windows. I then tried WinGW and it will work under the command prompt under windows 7 x64 Bit. So my suggestion is do what I did and use WinGW instead. If your on a 32Bit machine, both MinGW and DJGPP work just fine. Cygwin still needs it's own window because it runs in a simulated Linux environment as was mentioned in a previous posting earlier. If you try to get the MinGW LD linker to work under windows 7 x64, you'll need to use objcopy to strip it down to BIN, IF that is your goal. Otherwise, it will compile EXE just fine. You might need to set the linker to i386PE mode. ( Its why MinGW can be a choice in the downloading of the Code::Blocks IDE. )

Keep in mind, everything is command line, I don't use an IDE. This was all done by trial and error and googleing this information. So I am sure someone here knows a better way. If not, try this out and see if it works for you.