Mkisofs usage help

[StartOS]

Ok. I will use a cross compiler.
Can someone point me to a ready binary for windows or share theirs?
I am a newbie in OS Development and don't quite understand what to in the GCC cross compiler tutorial.

[Bender]

Ok. I will use a cross compiler.
Can someone point me to a ready binary for windows or share theirs?
I am a newbie in OS Development and don't quite understand what to in the GCC cross compiler tutorial.

That's bad again, firstly it's quite possible that the "pre compiled" compiler may not integrate well with your environment, secondly building a cross compiler it teaches you a lot of things you will need in your later stages and thirdly, it makes you familiar with your environment.

The tutorial is very verbose, detailed and well written. Some of best people on this forum have worked on it. Read it carefully step by step, and you should be able to get a working cross compiler.

[StartOS]

The tutorial is very verbose, detailed and well written. Some of best people on this forum have worked on it. Read it carefully step by step, and you should be able to get a working cross compiler.

It is just not written as a series of steps. And I am a real begginer. I never before did low-level programming I just did make some useful windowed programs like a text editor, basic mail client.
Everything that is written in this tutorial is totally new for me. I didn't use cygwin and do not even know how build a regular compiler not talking about a cross-compiler.
I tried using ghost-i686-elf-tools from http://wiki.osdev.org/GCC_Cross-Compile ... Toolchains, but it requires some dll for the dependencies listed in http://www.ghostkernel.org/documentation/toolchain.
Can someone explain how this stuff works or just give a link to an newb-friendly tutorial?

[FallenAvatar]

And I am a real begginer.

http://wiki.osdev.org/Beginner_Mistakes

- Monk

[iansjack]

TBH, I think you would find life a lot easier if you used Linux (maybe installed in a Virtual Machine) rather than Windows for OS development. Not saying that it can't be done in Windows but it does make life more difficult.

I know it sounds harsh, but if you can't follow the instructions to create a cross-compiler then you are going to find OS development very challenging. So I would stick with it as a very good introduction to the tools that you need to use.

[KemyLand]

I tried using ghost-i686-elf-tools from http://wiki.osdev.org/GCC_Cross-Compile ... Toolchains, but it requires some dll for the dependencies listed in http://www.ghostkernel.org/documentation/toolchain

How the **** did this reached there. The Ghost Kernel is one of max's projects. You should not use it! Don't misunderstand me; max is an excellent developer, but precompiled binaries are the hell on Earth.

This will be a somewhat lengthy post. I'll try to explain you what does the wiki perfectly explains. If this doesn't solutions the problem, I don't know what will.. I'll try to explain you the basics of cross-compilation, using the wiki . Before proceding, remember to read all the post before doing anything, specially the caveats at the end.

First of, why do you/I need a cross-compiler?

You need to use a cross-compiler unless you are developing on your own operating system. The compiler must know the correct target platform (CPU, operating system), otherwise you will run into trouble. If you use the compiler that comes with your system, then the compiler won't know it is compiling something else entirely. Some tutorials suggest using your system compiler and passing a lot of problematic options to the compiler. This will certainly give you a lot of problems in the future and the solution is build a cross-compiler.

First of all, get the lastest GCC sources. Extract them somewhere . Do the same with the lastest binutils sources. Do not mix both extracted folders!

The wiki says that you'll now need to "decide" your [link=http://wiki.osdev.org/Target_Triplet]Target Triplet[/link]. Let's just use i686-elf for this guide. Now, let's prepare for the build! This either can or cannot is a damn hard part for Cygwin/MinGW users. You'll have to get through your GNU on Windows environment. You'll need the following packages:

• GCC
• G++
• GNU Make
• GNU Bison
• GNU Flex
• GNU Diffutils

The wiki says you must also download GMP/MPFR/MPC. Do not! They're GCC's math/who knows what else supporting libraries. In my experience, GCC Make process tends to blindly miss these packages' folders once extracted on GCC's source folder. This is not any good, as compilation will simply fail with a frustrating make: ** error 1 **-like message. But we still need the libraries! There is a pretty clever and uniform solution to this problem. Assuming you extracted GCC to a directory named gcc-src, run these commands:

Code: Select all

cd gcc-src
./contrib/download_prerequisites

Just go, take a drink, and GCC will automatically download, unpack, and correctly place the necessary dependencies for you. Note that you need wget for this to even work.

We're ready! Let's start by creating some pretty folders (this is mandatory!). If you're still in gcc-src, run this:

Code: Select all

cd ..
mkdir gcc-bld
mkdir binutils-bld

The following commands must be ran exactly as shown or compilation will fail, and you'll have to start over from zero!
Just to be sure, take this religiously . If, by some reason, your terminal session is closed (power outage, etc..), you must refollow the following paragraph again.

We need to do some exports. This will allow the build system to understand where you want to build the cross-compiler. Never mind to avoid this step! We'll export three variables, first of all, $PREFIX. It is where your cross-compiler will be installed. Reserve a folder somewhere in your system for this. Let's say it's $HOME/cross (change this to your needs). Let's export it!:

Code: Select all

export PREFIX="$HOME/cross"

Now, another variable, $TARGET. It defines what platform your cross-compiler will compile for. I have said you that in this guide we'ld use i686-elf, that is, it will target Pentium Pro or newer processors.

Code: Select all

export TARGET="i686-elf"

The third variable will be exported later, but it's still important. It's actually $PATH. We'll redefine it so that we can call i686-elf-* from outside $PREFIX.

We are fully prepared, it's compile time! Run this exactly exactly as shown! We'll compile binutils first. Assuming you're still where I left you, do this. (Note: this assumes binutils sources are in a directory called binutils-src. In real world, it probably won't. Just modify the script to use the correct paths ):

Code: Select all

cd binutils-bld
../binutils-src/configure --target=$TARGET --prefix="$PREFIX" --with-sysroot --disable-nls --disable-werror
make
make install

This should run perfectly. If a minimal error occurs, the build will fail. In such a case, just post us the lastest lines before to the abort. Just for completeness, I'll explain each of the options. The first two are pretty trivial. --with-sysroot will force the build system to create a new /usr-like environment inside $PREFIX. This will help GCC later on. --disable-nls will disable Native Language Support. That is, if you're German for example, you'll get messages in English, not German. This is optional, but makes compilation faster and prints messages we (the forum people ) can understand.

It's time for GCC, finally! Run:

Code: Select all

cd ../gcc-bld
../gcc-src/configure --target=$TARGET --prefix="$PREFIX" --disable-nls --enable-languages=c,c++ --without-headers
make all-gcc all-target-libgcc
make install-gcc install-target-libgcc

This will take a long time, usually 2 or 3 times more than binutils . GCC's build is much more propense to disasters, so be aware for any errors! Again, I'll explain the flags. The first three are the same than for binutils. --enable-languages is pretty trivial; it creates compilers for C and C++. --without-headers alerts GCC that there won't be any runtime C(++) standard support library for the target. These commands also build libgcc, a library that GCC can generate calls to without any way to avoid it!. All GCC-compiled programs will be linked with libgcc. It implements some software-computed features that the target hardware is unable to handle, such as 64-bit division in i686-elf.

Once done, you'll have your fresh, just baked cross-compiler ready for the go. We'll just modify $PATH so that it can be accessed from anywhere:

Code: Select all

export PATH="$PREFIX/bin:$PATH"

Run the above snippet every time you open MinGW (or is there a .bashrc in MinGW ?)

I'll just post a few more caveats and exit:

1. Use tar to extract the archives. Don't use a Windows-specific tool. It may change Unix-newlines ("\n") to stupid Windows-newlines ("\n\r"). This is not any good, as compilation can get pretty messy really fast.
2. Don't stop the compilation (either voluntarily or not), neither close your MinGW terminal! It may be very difficult to recover from this, as you'll have to start from zero!.
3. Follow what the people on this forum say you. Don't persist on using "easy" prebuilt-compilers. They'll cause you lots of problems.
4. If you have the oportunity, install (either as dual-boot or single OS) a Linux distribution. If you really like OSDev, this will help you a lot!

[StartOS]

Very Big Thanks KemyLand!
Now I understand what I have to do.

[StartOS]

Oh no!!!
I get:
Makefile:743: recipe for target 'ar.exe' failed
make[4]: *** [ar.exe] Error 1
make[4]: Leaving directory '/cygdrive/c/Users/ABC/Documents/0Hack/XCompiler/binutils-bld/binutils'
Makefile:974: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/cygdrive/c/Users/ABC/Documents/0Hack/XCompiler/binutils-bld/binutils'
Makefile:625: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/cygdrive/c/Users/ABC/Documents/0Hack/XCompiler/binutils-bld/binutils'
Makefile recipe for target 'all-binutils' failed
make[1]: *** [all-binutils] Error 2
make[1]: Leaving directory '/cygdrive/c/Users/ABC/Documents/0Hack/XCompiler/binutils-bld'
Makefile:835: recipe for target 'all' failed
make: *** [all] Error 2

[iansjack]

I still think that you would find life easier if you stopped messing about with Windows and CygWin and used Linux to do your development. But perhaps you enjoy a challenge.

[no92]

I still think that you would find life easier if you stopped messing about with Windows and CygWin and used Linux to do your development. But perhaps you enjoy a challenge.

Incoming "Windows vs. Linux" war?

But seriously, using Windows for OSdev makes your life even harder. This isn't a necessity; you can use Linux instead. It's a shame that the most popular Desktop OS in the world doesn't have a single compiler that runs in the native environment and is capable of producing ELF-binaries. The Unix-environments for Windows lead often to issues, for example when using Makefiles.

Some prejudgments against Linux and what's wrong with them:
- hard to install: obviously wrong, it's as easy as Windows and OS X, thanks to GUI installers (for several years now)
- hard to use: most distros offer a GUI; Terminals aren't hard to use, and when OSdeving on Windows, you use them, too! (probably for more than a decade)
- no software: by searching a little you'll find something that suits your needs. In my 2.5 years of using Linux I've never had any issues with software I couldn't replace.
- no games: Thanks to Valve, since the Steam client port 2 years ago there are a lot of games (including AAA titles) that run on Linux; 54 out of my 68 games run on Linux. Note: I'm buying games regardless of the OS they run on, as I have a decent iMac with Windows.

[Bender]

....and if you want Windows alongside Linux, you can run it inside a VM or dual boot.

[iansjack]

I'm not making any recommendations about Linux as a general purpose Operating System, and certainly don't intend to start a Linux/Windows flame war. There are other forums for such discussions. (I actually use Windows, Linux, and OS X in about equal measures.) I'm only commenting on its suitability for this particular purpose - OS development.

Even if it were hard to install/configure (which it isn't) that would be irrelevant. Let's face it, if you can't manage a mature OS like Linux then your chances of managing your own immature OS are pretty minimal. If for no other reason, Linux is ideal for OS development because it is the environment assumed by most of the better tutorials/guides. This is a case in point; the OP is having difficulty creating a cross-compiler. If they used Linux they should have no problem following the step-by-step instructions in this Wiki. There is a far better selection of free development tools available for the Linux platform than there is for Windows. And the "natural" executable file format for Linux is one that ties in nicely with the use of Grub as a boot-loader. (This latter seems to be the root of the OP's problems.)

None of these are insurmountable in Windows but, unless you are very familiar with the tools you are using, they require more work than in Linux. OS development is hard enough without putting additional obstacles in your way. Anyway, I've made the point twice in this thread so I'll try to refrain from making it again.

[KemyLand]

I pulled out my hair when reading the most recent replies. Wasted my 15 minutes writing that guide, then NT + the subnormal of MinGW fucks it up .

Linux/Unix/*BSD/your T.V. is a better development platform than Windows. Let's remember Windows is a General-purpose OS, but "optimized" for non-developer end users. If some compiler works well in there, it's MSVC(++).

This is also GNU's fault both for creating Unix-dependent software (what I can call non-portable software), and being extremist in Free Software, to the point as to claiming that because Windows NT is not free software, porting software to it "violates" the user's freedoms. That's just ironical. The main project that supports free software is opposed to give its users the freedom to use their software were they want. BSD people at least understand what they're talking about . GNU justifies all this with the false fact that GNU Software is only intended to run on a GNU system (compile that on BSD, or even Sortix 0.9 if you like ).

[iansjack]

If the FSF made that claim it would certainly be a problem. Do you have a link for such a claim? As far as I can see there is nothing to prevent people from porting GNU software to Windows (other than the fact that it is not a particularly easy excercise).

As to chastising them because they target their tools at Unix-like OSs, that is just crazy.