OSDev.org

Hi everybody,

I've just started up a new Debian package repository on my server, to share with everybody the cross-compilers I've been building. I figure the lower the barrier of entry to having a working cross-compiler, the more people will do it. I've tested these packages working with Debian GNU/Linux Stable, but should work with any distro of Debian (Testing, Unstable), and might even work with Ubuntu (but no guarantees).

The repository is located at http://helium.fooproject.net/debian/
To use it, add the following line to your /etc/apt/sources.list The repository currently contains only two package: one is a cross-compiler that will run on a Debian i386 system and produce i586-elf executables, and another targetting i586-elf and running on the amd64 host. I'm working on expanding this to contain both more target platforms and more host platforms, but progress is slow. Send me a PM or an Email (or leave a message below) if you want anything in particular, and I'll do my best.

Naming of the packages is thus: osdev-crosscompiler-$TARGET, for example, osdev-crosscompiler-i586-elf. Normal Debian package repository magic will ensure you have the package for the right type of host system (once I get around to building them).

Eventually I hope to have targets for i586-elf, x86_64-elf, powerpc-elf, and whatever anybody else suggests. I hope to have host packages for i386, amd64, powerpc, plus whatever else anybody suggests. To "suggest" a package (host/target combination), send me a PM. Bribes of cookies and/or money will get things done quicker.

Each package puts it's files in /usr/cross/$TARGET, so you can have multiple cross-compilers co-existing on the one system. In addition, Debian magical trickery automatically installs all the right stuff in the $PATH, so it'll compile stuff right out of the box. Each package will contain compilers for C and C++, plus the matching binutils.

It's pretty proof-of-concept right now, so try it out, break it, complain, and so on. It *shouldn't* break your system, but I still wouldn't use it on a production server. No warranty given.

There is now a wiki page, currently located at http://wiki.osdev.org/User:Jackscott/GC ... bian_Linux.

Have fun.

Looks nifty, I'm going to try it out on my Xubuntu box (backing up my TBOS32 files first, of course) and see how it reacts to ubuntu

Once I figure out how to set one up without using any terminal commands I'd be willing to set up a mirror on fawkessoft.com. I got nothing else to do with the bandwidth...

If it's at all possible, I would like to see a mach-o capable compiler and linker, but I don't think the normal binutils supports it.

Edit: Hmm, I could run any commands needed locally...
Edit 2.0: I think I'm ready, all I need are the files to host and then we can see...

Thanks muchly to Firestryke31, there is now an official primary mirror of the repository. Use the following line in your /etc/apt/sources.list:
This site is much faster than my home server, at speeds in excess of 150KiB/s (probably a lot more, but that's the max my connection goes).

Yay! I'm useful!

Brilliant! This'll make setting up any new Debian-based OSDev environments much simpler - it's just another addition to the list when I install the first set of packages.

For all wondering, the cross-compilers work on Ubuntu - I just gave them a go on one of my Ubuntu 8.10 servers.

Perhaps I can provide some Windows cross-compilers I've built?

From experience, cygwin built tools don't like being moved to a different box.

I never mentioned Cygwin. But about that, I remember AlexExtreme distributing his Cygwin cross-compiler in a separate package some time ago. I have no idea if it worked properly when installed on a new machine but I really can't see why it wouldn't as long as all environment variables are set accordingly by the installer. All my cross-compilers are natively compiled.

Hi everybody,

Another mirror has been set up on the Pedigree project's web server. To use it, add this line to your /etc/apt/sources.list:

You might want to consider editing your original post to add a list of all of the mirrors so that someone that might be interested doesn't have to read the thread to find a suitable mirror.

Also, my server is located in the US. This might be something that a user might be interested in (selecting the closest mirror).

For Debian cross compilers, emdebian.org does the job
Enjoy!

Let's start providing community maintained toolsets for OSDev. For those people already providing this, I'd like it if we got together standardize this stuff. We'd want to get our toolchains as similar as possible across platforms. The required to support platforms would be: Debian/Ubuntu, Fedora/CentOS, and Windows XP/Vista/7. I'd be open to Mac and BSD support if there really was a need.

I'd of course host the stuff on the site here (as repos for linux distros), mirrors would be welcome. I'd also like to get the build process automated/scripted as much as possible so the tool chains are regularly updated.

For Windows...what is working best for those of you doing development from that platform? Should we look at packaging everything up into an installer/msi or just have a zip archive available for download.

gas and gcc support. We need to standardize the options. No C++. What else? I'm think x86-syntax gas from now on, dropping nasm, masm, etc.

Part of the reason (besides making OSDev easier to start) is to standardize the tutorials/wiki articles going forward. So do we want to use "make" or shell/batch scripts for builds? Do we have a standard OS project structure, etc. Really open to suggestions here.

chase wrote:Let's start providing community maintained toolsets for OSDev. For those people already providing this, I'd like it if we got together standardize this stuff. We'd want to get our toolchains as similar as possible across platforms. The required to support platforms would be: Debian/Ubuntu, Fedora/CentOS, and Windows XP/Vista/7. I'd be open to Mac and BSD support if there really was a need.

I'd of course host the stuff on the site here (as repos for linux distros), mirrors would be welcome. I'd also like to get the build process automated/scripted as much as possible so the tool chains are regularly updated.

For Windows...what is working best for those of you doing development from that platform? Should we look at packaging everything up into an installer/msi or just have a zip archive available for download.

gas and gcc support. We need to standardize the options. No C++. What else? I'm think x86-syntax gas from now on, dropping nasm, masm, etc.

Part of the reason (besides making OSDev easier to start) is to standardize the tutorials/wiki articles going forward. So do we want to use "make" or shell/batch scripts for builds? Do we have a standard OS project structure, etc. Really open to suggestions here.

Great suggestion here chase. I've got a pretty decent Makefile (requires GNU Make) that will download binutils, gcc-core, and gcc-g++, configure, and compile them all to an i686-elf target. That has been tested on both OS X and Linux.

I develop primarily in OS X these days so I can make binaries available for that platform. I also have a debian server at home that I can build packages on and provide a mirror from.

I think it's a good idea as well. This is one thing we really need: a directed effort toward making starting out in osdev less about patching together ancient tutorials and, more importantly, less about asking the same simple question over and over.

I think in terms of Linux, we should focus on source-based installation instead of support for a specific distro. Anyone intelligent enough to osdev can definitely install gcc/binutils/make via their package manager, so they can at the very least type make in an unpacked tarball. The things needed for osdev also generally have few dependencies, so that shouldn't be a problem. Not to mention that if all that is needed is a build script that downloads its own files, we could probably host those scripts on this site somewhere (perhaps even as wiki pages), instead of borrowing server space (and time, if binaries are built) from members.

I would also vote for having a semi-standardized OS project structure, if only to have standard makefiles that can be downloaded to work essentially OOTB.

I'm not so sure about whether to choose x86 gas over nasm and similar, just because I personally, and as far as I can tell, quite a few others, don't like the AT&T syntax it uses. Maybe if we use gas, but exclusively with Intel syntax (which is supported in versions 2.10+)? I'm fine with using gcc as "the" compiler, but we should definitely stick to c99 and try to avoid GNU extensions, just for portability.