[ Solved ] Windows 7 x64 ( Cross Compiler ) NO Libs

[Kortath]

There is in fact much evidence indicating that GCC is useful for OS creation.

Please, share the evidence that this works under windows 7 64-Bit. Doing all this under 32-Bit is easy with DJGPP, but under 64 Bit I have not seen anyone else use GCC for OS Creation. My decision was not "hasty" it was out of not being able to find any other way. So If I am forced to go back to coding in 32-Bit, I will stick with what I know, and that is DJGPP. It plain and simply works. Is this decision the right thing to do ? Most here would probably say it isn't. But there are no tutorials that are helpful in this regard. Because when I follow them to the T.. they do not work under windows 7 64Bit. And the tutorials I have seen, and there are many, all mention DJGPP as the compiler, even though it itself doesn't work under Windows 7 64Bit.

I also recommend that the original poster fix their linker script. They could perhaps start by putting the COMMON section somewhere. Not doing things like that is an excellent source of gigantic binaries.

Adding COMMON is something I will have to look into. I hadn't seen a good tutorial on the linker script customizations that have COMMON in it. Thanks for the tip.


EDIT UPDATE : COMMON.. Thanks for pointing this out. I tried this with DJGPP and it compiles no problem. Since I was able to know what to look for, I did a search for common linker.ld and found out that it goes into the .bss section. Again, thank you.

[Kortath]

OK here is my dilemma.

It's become very apparent that there is a war between people whom use DJGPP and GCC ( Cross Compiler ). From what I have personally experienced thus far is that DJGPP works and keeps the code clean and tight. No bloated Zeros no extra libraries. GCC on the other hand, as has been pointed out to me on this thread and also on many many pages, shows that it has problems when it comes to optimizations. When I use -Ofast, it compiled my code and it worked. And this is under Windows 7 64-Bit. The other optimizations did not work.

OK so I thought, maybe if I compile GCC under win32 ( win7 ) and tried to compile, I would see what would happen. Result with as little code as possible and still have something show up on screen :

DJGPP : 4.1K in size for the kernel.bin file.
GCC : 7.3K in size for the kernel.bin file meaning it added zeros all over it. Although I don't think this is too much, but after some of the comments on this thread, now I am starting to think otherwise. GCC has something wrong with it. ( And this is with -Ofast switch though, the other switches or other ways do not work, they bloated the kernel to over a meg in size and it just wouldn't boot. Also, this again is proven in many pages that the optimizations in GCC do not work on their own website for the 4.8.x versions. )

It is why I made the choice that if I can't get this to work under windows 7 64Bit, then I might as well stick with what I know works and has worked for years, and that is DJGPP. Some say I will see problems down the line, but for years of my doing this, I have not found any nor have I seen any proof of this. I want to do the recommended thing here, but I'm not seeing what you all are seeing. And the tutorials that I have read even on the osdever website mentioned GJGPP when under windows. Which again apparently I am seeing a hidden war here.

EDIT UPDATE : On a side note, the ones whom have shown that GCC works for their OS, are not using windows. They are using Linux. That is the only indication I have seen that GCC is successful for OS creation. And as was pointed out in this thread, that by using DJGPP I will see problems down the line, but from what I am also reading on this very thread is that by using GCC this problem exists when using this under windows also. So I am not seeing the difference. DJGPP is tighter and it works.

[Kortath]

The last post I made shows how large the file sizes were when I compiled my scaled down code to the bare basics. My last post also shows my frustration with all of this. So here I wanted to share with you what I have. Maybe you can spot my errors for me and we can solve this. I really want to use the standard compiler GCC that everyone recommends so that I can use my 64-Bit Windows 7 to work on my basic OS. But I guess it would be hard for you to share with me your knowledge if I can't share with you my code. Maybe you can help me understand where I am going wrong here. So I have scaled down my code to some basics and shoved all my DEFs / FUNCTIONs into one file for simplicity sake. Normally I split my files up and its more organized. But to keep things simple, I am doing it this way for this thread's purpose.

Compiler : DJGPP
Assembler : NASM or YASM ( Both work )
Environment : Windows 7 32-Bit ( DJGPP doesn't work under 64 Bit windows )

When compiled using DJGPP the file size is 4.1K. Also, I do not want to call any libraries that I have not made myself.

NOTE : When using NASM or YASM, I can use elf or coff and the behavior is the same. No change.

compile.bat

Code: Select all

nasm -f elf -o start.o start.asm

gcc -ffreestanding -c -o kernel.o kernel.c

ld -T linker.ld --oformat binary -o kernel32.sys start.o kernel.o

pause

functions.h

Code: Select all

#define BLACK         0x0
#define LIGHTRED      0xC

#define VIDEO_MEM_80x25_03 0xb8000

void clear(unsigned int bcolor, unsigned int fcolor);

unsigned int printf(char *message, unsigned int col, unsigned int row, unsigned int bcolor, unsigned int fcolor);

void bscreen(void);

void clear(unsigned int bcolor, unsigned int fcolor)
{
   char *vidmem = (char *) VIDEO_MEM_80x25_03;
   unsigned int i=0;
   while(i < (80*25*2))
   {
      vidmem[i]=' ';
      i++;
      vidmem[i]=fcolor + (bcolor * 16);
      i++;
   }
}

unsigned int printf(char *message, unsigned int col, unsigned int row, unsigned int bcolor, unsigned int fcolor)
{
   char *vidmem = (char *) VIDEO_MEM_80x25_03;
   unsigned int i=0;

   i=(row*80*2) + (col*2);

   while(*message!=0)
   {
      if(*message=='\n')
      {
         row++;
         i=(row*80*2);
         *message++;
      } else {
         vidmem[i]=*message;
         *message++;
         i++;
         vidmem[i]=fcolor + (bcolor * 16);
         i++;
      }
   }
   return 1;
}

void bscreen(void)
{
   printf("Welcome to TOS 32-Bit - 2013", 12, 8, BLACK, LIGHTRED);
   printf("This was made in C.",24,10, BLACK, LIGHTRED);
}

kernel.c

Code: Select all

#include "functions.h"

void main(void)
{
   clear(BLACK,BLACK);
   bscreen();
}

linker.ld

Code: Select all

OUTPUT_FORMAT("binary")

SECTIONS
{
  .text 0x100000 :
  {
      code = .;
      _code = .;
      __code = .;
      *(.text)
      *(.rodata*)
      . = ALIGN(4096);
  }
  .data :
  {
      data = .;
      _data = .;
      __data = .;
     *(.data)
     . = ALIGN(4096);
  }
  .bss :
  {
     bss = .;
     _bss = .;
     __bss = .;
     *(COMMON)
     *(.bss)
     . = ALIGN(4096);
  }
  end = .;
  _end = .;
  __end = .;
}

NOTE : If you want to compile this for GCC, you must remove the _ ( underscores ) for main. It will not compile under GCC correctly if they are there. It is only needed for DJGPP.

start.asm

Code: Select all

global start
extern _main

[BITS 32]

start:
call _main

cli
hlt

EXTERN code, bss, end

ALIGN 4
mboot:
   dd mboot
   dd code
   dd bss
   dd end
   dd start

SECTION .text

Here is a picture of it running :

[gerryg400]

Kortath, I built your code with my cross-compiler. My cross-compiler runs under windows, linux and mac and produces identical results on all 3. I have tested this thoroughly.

I had to make some small changes because I use gas instead of your assembler but the GCC compiled code is identical.

I used -O2 and the resultant binary is exactly 500 bytes long. -Ofast increased the binary to 556 bytes.

I changed your linker script slightly to produce an ELF file. The resultant ELF file was 5395 bytes.

Your OS (the ELF version) ran fine in VMWare loaded by grub.

[Kortath]

Kortath, I built your code with my cross-compiler. My cross-compiler runs under windows, linux and mac and produces identical results on all 3. I have tested this thoroughly.

I had to make some small changes because I use gas instead of your assembler but the GCC compiled code is identical.

I used -O2 and the resultant binary is exactly 500 bytes long. -Ofast increased the binary to 556 bytes.

I changed your linker script slightly to produce an ELF file. The resultant ELF file was 5395 bytes.

Your OS (the ELF version) ran fine in VMWare loaded by grub.

Are you using Windows 7 64-Bit ?

Could you show me the linker script so I can see what changes you made ?

I am not using grub, I am using my own boot loader. But should still do the same thing.

Can you show me a tutorial on how you made your cross compiler work and what versions of all the source code and its dependencies you used ?

I checked out the OSDev wiki tutorial on how to make a cross compiler and that is how I compiled my GCC version. I followed the tutorial and I tried both GCC 4.8.0 and GCC 4.8.1 and both failed according to using the optimization switches that was suggested on this thread. I need a working cross compiler for windows 7 64-Bit.

[gerryg400]

Are you using Windows 7 64-Bit ?

I used Mac to build your code. But I have tested my compiler on Windows 7 64-bit using Cygwin.

Could you show me the linker script so I can see what changes you made ?

I'm at a different machine right now, but I'll do that later.

Can you show me a tutorial on how you made your cross compiler work and what versions of all the source code and its dependencies you used ?

I don't have a tutorial. I used GCC 4.7.3. I can guarantee that switching to 4.8.x by itself will not increase the binary to 4k or 7k or whatever.

I checked out the OSDev wiki tutorial on how to make a cross compiler and that is how I compiled my GCC version. I followed the tutorial and I tried both GCC 4.8.0 and GCC 4.8.1 and both failed according to using the optimization switches that was suggested on this thread. I need a working cross compiler for windows 7 64-Bit.

I don't understand. What do you mean by "failed according to using the optimization switches that was suggested on this thread" ?

The point of my post was that your kernel is tiny. It is 500 byes (not 4k or 7k) and so neither of your compilers is doing what you wanted it to do. You need to look a bit harder at your problem and not blame your tools.

[Kortath]

Are you using Windows 7 64-Bit ?

I used Mac to build your code. But I have tested my compiler on Windows 7 64-bit using Cygwin.

Could you show me the linker script so I can see what changes you made ?

I'm at a different machine right now, but I'll do that later.

Can you show me a tutorial on how you made your cross compiler work and what versions of all the source code and its dependencies you used ?

I don't have a tutorial. I used GCC 4.7.3. I can guarantee that switching to 4.8.x by itself will not increase the binary to 4k or 7k or whatever.

I checked out the OSDev wiki tutorial on how to make a cross compiler and that is how I compiled my GCC version. I followed the tutorial and I tried both GCC 4.8.0 and GCC 4.8.1 and both failed according to using the optimization switches that was suggested on this thread. I need a working cross compiler for windows 7 64-Bit.

I don't understand. What do you mean by "failed according to using the optimization switches that was suggested on this thread" ?

The point of my post was that your kernel is tiny. It is 500 byes (not 4k or 7k) and so neither of your compilers is doing what you wanted it to do. You need to look a bit harder at your problem and not blame your tools.

Well then what is the problem ? You haven't shown me anything. Your talking but not showing any proof or explanation of what your talking about. The cygwin doesn't compile OS raw binary code under windows 7 64 Bit because of the PE error it gives. I have tried it. So please explain HOW you did it. That makes no sense. GCC should be able to be ran without needing a unix like environment like cygwin. That is the whole point of my wanting to make a cross compiler that works under windows 7 64-Bit. And I would like to see your compiled kernel.bin file working. I have not seen a compiler yet that can compile it that small. 500 Bytes ? Seriously ? My functions that I have for it will take up more room then that. So please, explain the steps of how you did it. If your not doing any of this under Windows 7 64-Bit then your input doesn't help me at all. I'm not on a MAC.


And if you read this thread, you will see that there are comments made that something was wrong with GCC because of the very fact that I couldn't use any optimization switches or get the code to boot without using -Ofast. Everything works fine with DJGPP. But GCC has issues. THAT is why I "blame the tools" as you put it. It's not my code, as your stating my code is fine. So its not something that "I need to look harder at". Your contradicting yourself.

[gerryg400]

You haven't shown me anything. Your talking but not showing any proof or explanation of what your talking about.

Here's proof that I took the time to compile and run your OS. You should be at least grateful someone is taking the time to try to help you.

[gerryg400]

Well then what is the problem ?

The problem is your understanding of the tools. I believe that combuster is correct and that your linker script causes your binary to be a size that you don't expect.

Read very carefully. The amount of code in your kernel is about 500bytes. There is no data in your kernel. There is something else making up the extra size of your files. It is not code. It is not related to optimisation. It is not related to libraries. It is not related to the difference between GCC and some other compiler.

Further you are not observing a problem with the tools.

In your linker script you have ALIGN directives and you create some linker variables. Do you think it's possible that they have something to do with the size of your file ?

Also in your linker script you don't have a '*' after the ".text" in "*(.text)". Is it possible that that has something to do with the size of the file ? Is there some difference between your 2 compilers in this regard ?

NOTE: I don't have your tools available so I cannot say what your problem is. However, I am pretty confident that your problem is not caused by a bug in GCC.

[gerryg400]

The cygwin doesn't compile OS raw binary code under windows 7 64 Bit because of the PE error it gives.

Of course that is true. That's why it's recommended to build a cross-compiler using the Cygwin version of GCC and build your operating system using the cross-compiler.

[gerryg400]

I have not seen a compiler yet that can compile it that small. 500 Bytes ? Seriously ? My functions that I have for it will take up more room then that.

Here's your kernel, compiled with GCC - 327 bytes of code and 84 bytes of string data.

Code: Select all

Disassembly of section .text:

00100000 <start>:
  100000:	eb 0e                	jmp    100010 <over_multiboot_header>
  100002:	66 90                	xchg   %ax,%ax
  100004:	02 b0 ad 1b 03 00    	add    0x31bad(%eax),%dh
  10000a:	00 00                	add    %al,(%eax)
  10000c:	fb                   	sti    
  10000d:	4f                   	dec    %edi
  10000e:	52                   	push   %edx
  10000f:	e4 e8                	in     $0xe8,%al

00100010 <over_multiboot_header>:
  100010:	e8 0b 01 00 00       	call   100120 <main>
  100015:	fa                   	cli    
  100016:	f4                   	hlt    
  100017:	66 90                	xchg   %ax,%ax
  100019:	66 90                	xchg   %ax,%ax
  10001b:	66 90                	xchg   %ax,%ax
  10001d:	66 90                	xchg   %ax,%ax
  10001f:	90                   	nop

00100020 <clear>:
  100020:	0f b6 54 24 04       	movzbl 0x4(%esp),%edx
  100025:	31 c0                	xor    %eax,%eax
  100027:	c1 e2 04             	shl    $0x4,%edx
  10002a:	02 54 24 08          	add    0x8(%esp),%dl
  10002e:	66 90                	xchg   %ax,%ax
  100030:	c6 80 00 80 0b 00 20 	movb   $0x20,0xb8000(%eax)
  100037:	88 90 01 80 0b 00    	mov    %dl,0xb8001(%eax)
  10003d:	83 c0 02             	add    $0x2,%eax
  100040:	3d a0 0f 00 00       	cmp    $0xfa0,%eax
  100045:	75 e9                	jne    100030 <clear+0x10>
  100047:	f3 c3                	repz ret 
  100049:	8d b4 26 00 00 00 00 	lea    0x0(%esi,%eiz,1),%esi

00100050 <printf>:
  100050:	56                   	push   %esi
  100051:	53                   	push   %ebx
  100052:	0f b6 44 24 18       	movzbl 0x18(%esp),%eax
  100057:	8b 5c 24 14          	mov    0x14(%esp),%ebx
  10005b:	8b 4c 24 0c          	mov    0xc(%esp),%ecx
  10005f:	c1 e0 04             	shl    $0x4,%eax
  100062:	89 c6                	mov    %eax,%esi
  100064:	0f b6 44 24 1c       	movzbl 0x1c(%esp),%eax
  100069:	8d 14 9b             	lea    (%ebx,%ebx,4),%edx
  10006c:	83 c1 01             	add    $0x1,%ecx
  10006f:	c1 e2 04             	shl    $0x4,%edx
  100072:	03 54 24 10          	add    0x10(%esp),%edx
  100076:	01 c6                	add    %eax,%esi
  100078:	01 d2                	add    %edx,%edx
  10007a:	eb 18                	jmp    100094 <printf+0x44>
  10007c:	8d 74 26 00          	lea    0x0(%esi,%eiz,1),%esi
  100080:	88 82 00 80 0b 00    	mov    %al,0xb8000(%edx)
  100086:	89 f0                	mov    %esi,%eax
  100088:	88 82 01 80 0b 00    	mov    %al,0xb8001(%edx)
  10008e:	83 c2 02             	add    $0x2,%edx
  100091:	83 c1 01             	add    $0x1,%ecx
  100094:	0f b6 41 ff          	movzbl -0x1(%ecx),%eax
  100098:	84 c0                	test   %al,%al
  10009a:	74 14                	je     1000b0 <printf+0x60>
  10009c:	3c 0a                	cmp    $0xa,%al
  10009e:	75 e0                	jne    100080 <printf+0x30>
  1000a0:	83 c3 01             	add    $0x1,%ebx
  1000a3:	8d 14 9b             	lea    (%ebx,%ebx,4),%edx
  1000a6:	c1 e2 05             	shl    $0x5,%edx
  1000a9:	eb e6                	jmp    100091 <printf+0x41>
  1000ab:	90                   	nop
  1000ac:	8d 74 26 00          	lea    0x0(%esi,%eiz,1),%esi
  1000b0:	b8 01 00 00 00       	mov    $0x1,%eax
  1000b5:	5b                   	pop    %ebx
  1000b6:	5e                   	pop    %esi
  1000b7:	c3                   	ret    
  1000b8:	90                   	nop
  1000b9:	8d b4 26 00 00 00 00 	lea    0x0(%esi,%eiz,1),%esi

001000c0 <bscreen>:
  1000c0:	83 ec 14             	sub    $0x14,%esp
  1000c3:	c7 44 24 10 0c 00 00 	movl   $0xc,0x10(%esp)
  1000ca:	00 
  1000cb:	c7 44 24 0c 00 00 00 	movl   $0x0,0xc(%esp)
  1000d2:	00 
  1000d3:	c7 44 24 08 08 00 00 	movl   $0x8,0x8(%esp)
  1000da:	00 
  1000db:	c7 44 24 04 0c 00 00 	movl   $0xc,0x4(%esp)
  1000e2:	00 
  1000e3:	c7 04 24 47 01 10 00 	movl   $0x100147,(%esp)
  1000ea:	e8 61 ff ff ff       	call   100050 <printf>
  1000ef:	c7 44 24 10 0c 00 00 	movl   $0xc,0x10(%esp)
  1000f6:	00 
  1000f7:	c7 44 24 0c 00 00 00 	movl   $0x0,0xc(%esp)
  1000fe:	00 
  1000ff:	c7 44 24 08 0a 00 00 	movl   $0xa,0x8(%esp)
  100106:	00 
  100107:	c7 44 24 04 18 00 00 	movl   $0x18,0x4(%esp)
  10010e:	00 
  10010f:	c7 04 24 64 01 10 00 	movl   $0x100164,(%esp)
  100116:	e8 35 ff ff ff       	call   100050 <printf>
  10011b:	83 c4 14             	add    $0x14,%esp
  10011e:	c3                   	ret    
  10011f:	90                   	nop

00100120 <main>:
  100120:	31 c0                	xor    %eax,%eax
  100122:	8d b6 00 00 00 00    	lea    0x0(%esi),%esi
  100128:	c6 80 00 80 0b 00 20 	movb   $0x20,0xb8000(%eax)
  10012f:	c6 80 01 80 0b 00 00 	movb   $0x0,0xb8001(%eax)
  100136:	83 c0 02             	add    $0x2,%eax
  100139:	3d a0 0f 00 00       	cmp    $0xfa0,%eax
  10013e:	75 e8                	jne    100128 <main+0x8>
  100140:	e8 7b ff ff ff       	call   1000c0 <bscreen>
  100145:	f3 c3                	repz ret 

Disassembly of section .rodata.str1.1:

00100147 <.rodata.str1.1>:
  100147:	57                   	push   %edi
  100148:	65                   	gs
  100149:	6c                   	insb   (%dx),%es:(%edi)
  10014a:	63 6f 6d             	arpl   %bp,0x6d(%edi)
  10014d:	65 20 74 6f 20       	and    %dh,%gs:0x20(%edi,%ebp,2)
  100152:	54                   	push   %esp
  100153:	4f                   	dec    %edi
  100154:	53                   	push   %ebx
  100155:	20 33                	and    %dh,(%ebx)
  100157:	32 2d 42 69 74 20    	xor    0x20746942,%ch
  10015d:	2d 20 32 30 31       	sub    $0x31303220,%eax
  100162:	33 00                	xor    (%eax),%eax

Disassembly of section .rodata.str1.4:

00100164 <.rodata.str1.4>:
  100164:	54                   	push   %esp
  100165:	68 69 73 20 77       	push   $0x77207369
  10016a:	61                   	popa   
  10016b:	73 20                	jae    10018d <main+0x6d>
  10016d:	6d                   	insl   (%dx),%es:(%edi)
  10016e:	61                   	popa   
  10016f:	64 65 20 69 6e       	fs and %ch,%fs:%gs:0x6e(%ecx)
  100174:	20 43 20             	and    %al,0x20(%ebx)
  100177:	62 79 20             	bound  %edi,0x20(%ecx)
  10017a:	67                   	addr16
  10017b:	65                   	gs
  10017c:	72 72                	jb     1001f0 <main+0xd0>
  10017e:	79 67                	jns    1001e7 <main+0xc7>
  100180:	20 61 73             	and    %ah,0x73(%ecx)
  100183:	20 72 65             	and    %dh,0x65(%edx)
  100186:	71 75                	jno    1001fd <main+0xdd>
  100188:	65                   	gs
  100189:	73 74                	jae    1001ff <main+0xdf>
  10018b:	65 64 20 62 79       	gs and %ah,%fs:%gs:0x79(%edx)
  100190:	20 4b 6f             	and    %cl,0x6f(%ebx)
  100193:	72 74                	jb     100209 <main+0xe9>
  100195:	61                   	popa   
  100196:	74 68                	je     100200 <main+0xe0>
  100198:	2e 00 00             	add    %al,%cs:(%eax)

[Kortath]

You haven't shown me anything. Your talking but not showing any proof or explanation of what your talking about.

Here's proof that I took the time to compile and run your OS. You should be at least grateful someone is taking the time to try to help you.

Well then what is the problem ?

The problem is your understanding of the tools. I believe that combuster is correct and that your linker script causes your binary to be a size that you don't expect.

Read very carefully. The amount of code in your kernel is about 500bytes. There is no data in your kernel. There is something else making up the extra size of your files. It is not code. It is not related to optimisation. It is not related to libraries. It is not related to the difference between GCC and some other compiler.

Further you are not observing a problem with the tools.

In your linker script you have ALIGN directives and you create some linker variables. Do you think it's possible that they have something to do with the size of your file ?

Also in your linker script you don't have a '*' after the ".text" in "*(.text)". Is it possible that that has something to do with the size of the file ? Is there some difference between your 2 compilers in this regard ?

NOTE: I don't have your tools available so I cannot say what your problem is. However, I am pretty confident that your problem is not caused by a bug in GCC.

Combuster was telling me it needed COMMON. So It was already taken care of as I mentioned in an earlier post. The align is not the problem. And I did try out the * behind the .text and it doesn't work. The compilation fails. In fact I got my info about the linker script from tutorials on OSDev Wiki and it doesn't show that asterisk to be there. Even the bare bones tutorial doesn't show it there.

http://wiki.osdev.org/Bare_Bones

So how did you get it to compile if you added that ?

The topic of this thread shows that I am using 64Bit windows 7. I'm not in a MAC. And if you think I'm ungrateful, then obviously you don't know me. I am VERY grateful. But I see a lot of fakes on this forum. People who say things but never show proof of anything. They just want to give people a hard time. So I'm not gullible when someone says something .. especially when I tested it out on my own already. You said you did this under cygwin.. but cygwin can't compile an OS. Why ? Because of the PE error. Although, keep in mind, I am talking about Windows 7 64Bit. Your doing all this on a MAC and showing your picture of this on a MAC. You could have did all this in assembly and it would come to 500 bytes. But with a linker it would come to about 4 K. Why ? Because this is done in C and I set the align to be 4096.. Hence.. 4K file size. The 4.8.x GCC versions didn't compile that small. So yes the align does have something to do with it. I WILL however give the 4.7.x version you mentioned a try.

Are you using Windows 7 64-Bit ?

I used Mac to build your code. But I have tested my compiler on Windows 7 64-bit using Cygwin.

The cygwin doesn't compile OS raw binary code under windows 7 64 Bit because of the PE error it gives.

Of course that is true. That's why it's recommended to build a cross-compiler using the Cygwin version of GCC and build your operating system using the cross-compiler.

You said you compiled my code in a MAC and then in the next line you did it under Cygwin in win7 64-Bit. This is why I was wanting to see proof of this. Thanks for the clarification.

EDIT UPDATE : I forgot to mention, cygwin wouldn't compile the code from the OSDev wiki tutorial on Cross Compilers. It always gave errors. So again, if you can show how to do this successfully under windows 7 64-Bit, then you would definitely have my gratitude. At least MinGW64 worked with the MSYS Unix environment. Even though it compiled it badly.

[gerryg400]

EDIT UPDATE : I forgot to mention, cygwin wouldn't compile the code from the OSDev wiki tutorial on Cross Compilers. It always gave errors. So again, if you can show how to do this successfully under windows 7 64-Bit, then you would definitely have my gratitude. At least MinGW64 worked with the MSYS Unix environment. Even though it compiled it badly.

I've never tried that tutorial. I'll try it today on a Win7-64 machine.

[Kortath]

EDIT UPDATE : I forgot to mention, cygwin wouldn't compile the code from the OSDev wiki tutorial on Cross Compilers. It always gave errors. So again, if you can show how to do this successfully under windows 7 64-Bit, then you would definitely have my gratitude. At least MinGW64 worked with the MSYS Unix environment. Even though it compiled it badly.

I've never tried that tutorial. I'll try it today on a Win7-64 machine.

Writing on a forum is rough, because people can interpret your text in a direction that was never intended and then a whole argument can take place. I just want to let you know, thanks for the help your trying to offer. I hope our further discussions take us in the right direction in solving this.

I am curious though, if you successfully got a Cross Compiler working and didn't follow the OSDev wiki, what tutorial did you follow ? Got a link ?

[gerryg400]

I just now followed the wiki and compiled Binutils 2.23.1 and GCC 4.8.1 under Cygwin on Windows 7-64. I haven't tried to compile your code yet. I'm busy right now. Here's what I ran. It's not identical to the wiki but it's very close. It took about 8 mins to build. I'll test it later.

Code: Select all

#!/bin/sh

export BUILDROOT=$(PWD)/..
export PREFIX=$BUILDROOT/cross-tools/
export TARGET=i386-elf

export BINUTILS_VER=2.23.1
export GCC_VER=4.8.1
export GMP_VER=5.0.2
export MPC_VER=0.9
export MPFR_VER=2.4.2

#rm -rf $PREFIX
#mkdir -p $PREFIX

# Delete old binutils build first
#rm -rf binutils-build-$TARGET
#rm -rf binutils-$BINUTILS_VER

tar -jxf binutils-$BINUTILS_VER.tar.bz2

mkdir binutils-build-$TARGET
cd binutils-build-$TARGET
../binutils-$BINUTILS_VER/configure --target=$TARGET --prefix=$PREFIX --disable-nls
make -j 4 all
make install
cd ..

# Clean up
#rm -rf binutils-build-$TARGET
#rm -rf binutils-$BINUTILS_VER

# Delete old gcc build first
rm -rf gcc-build-$TARGET
rm -rf gcc-$GCC_VER

tar -jxf gcc-$GCC_VER.tar.bz2

tar -jxf gmp-$GMP_VER.tar.bz2
mv gmp-$GMP_VER gmp
mv gmp gcc-$GCC_VER

tar -xf mpc-$MPC_VER.tar.gz
mv mpc-$MPC_VER mpc
mv mpc gcc-$GCC_VER

tar -jxf mpfr-$MPFR_VER.tar.bz2
mv mpfr-$MPFR_VER mpfr
mv mpfr gcc-$GCC_VER

mkdir gcc-build-$TARGET
cd gcc-build-$TARGET
../gcc-$GCC_VER/configure --target=$TARGET --prefix=$PREFIX --disable-nls --enable-languages=c,c++ --without-headers
make -j 4 all-gcc
make install-gcc
make -j 4 all-target-libgcc
make install-target-libgcc
cd ..

# Clean up
#rm -rf gcc-build-$TARGET
#rm -rf gcc-$GCC_VER