Native build of binutils/gcc

[mariuszp]

This question may seem very simple but I cannot find information about this on the wiki and the answer is probably stupidly obvious, sorry.

I've got a C library, and a cross-compiler to my OS (x86_64-glidix). The --prefix I use is /glidix (the exec-prefix for binutils and gcc is /usr, so I can access them without modifying the PATH). Porting libraries is obviously very easy (e.g. the ones that GCC depends on): I just have to give them the prefix and simply install; they'll be in the cross-compiler search path.

But how do I configure binutils and GCC to actually do native builds for my OS? I don't want to install the Glidix executables on my Linux system for obvious reasons... so what configuration options am I supposed to use, and which files shall I copy and where to, on the filesystem that Glidix runs on?

I hope the question is understandable...

[no92]

I'm a tiny little bit confused by your question. I'll try my best to ask specific questions to get some information.

1st: What's 'x86_64-glidix'? Is it a renamed 'x86_64-elf' or what?
2nd: Why don't you want to install your OS-Specific toolchain on your machine? It doesn't conflict with any other gcc or binutils install ...
3rd: Have you already taken a look at the OS Specific Toolchain wiki page?

[gerryg400]

You need something like this..

Code: Select all

../binutils-$BINUTILS_VER/configure --target=x86_64-glidix --prefix=/usr --with-sysroot=/ --with-build-sysroot=~/build-sysroot --host=x86_64-glidix
DESTDIR=~/build-sysroot make all
DESTDIR=~/build-sysroot make install

Note that ~/build-sysroot is the folder that contains the root file system that you are building for your OS. That is to say that everything under ~/build-sysroot will be installed onto your OS's root file system on the target machine eventually.

[mariuszp]

I'm a tiny little bit confused by your question. I'll try my best to ask specific questions to get some information.

1st: What's 'x86_64-glidix'? Is it a renamed 'x86_64-elf' or what?
2nd: Why don't you want to install your OS-Specific toolchain on your machine? It doesn't conflict with any other gcc or binutils install ...
3rd: Have you already taken a look at the OS Specific Toolchain wiki page?

x86_64-glidix is the OS specific toolchain. That is installed on my machine (so the GCC that makes executable for my OS is x86_64-glidix-gcc). I was asking about how I would use that cross-compiler to build itself to run ON my OS, as well as TARGET my OS. I think the other user just answered my question, so thanks to him (sorry, I can't look at what your username was while typing this).

[sortie]

Hi mariuszp. Congratulations on getting this far!

I've ported a lot of software to my OS, including a fully functional gcc and binutils toolchain. I've written, or contributed to, a bunch of wiki articles on this matter that should be relevant.

http://wiki.osdev.org/OS_Specific_Toolchain - This was already linked and I gather you already have one, might as well check you are up to date with recent changes.
http://wiki.osdev.org/Hosted_GCC_Cross-Compiler - You say you already have a libc, so it sounds like you're already setting up your cross-compiler in this matter, but you probably want to doublecheck.
http://wiki.osdev.org/Cross-Porting_Software - This is the important tutorial I want to make sure you've seen. It documents how to reliably cross-compile third party software the *right* way. From your original post, I get the impression you're doing this entirely wrong. You are meant to set --prefix to the location on your OS where it will be installed, it has nothing to do with your local build machine. After building, set DESTDIR in the make install step to add a second prefix for the purpose of installation. This is useful for package management, but also for cross-compilation where you want to install into your system root.

I don't think you know exactly what a exec-prefix is. A package installs often both machine independent files (man pages, images, documentation, headers, ...) and machine dependent files (programs, libraries, ...). You might want to install those in different places, such as on systems where multiple architectures can co-exist peacefully. Then you can --prefix=/usr -exec-prefix=/usr/x88_64 and get /usr/include/foo.h and /usr/x86_64/lib/libfoo.a.

I'm not entirely sure if you use sysroots and whether you understand their use. They're crucial for proper cross-compilation and you should use them.

If you are a bit curious how sysroots and such should be used:
http://wiki.osdev.org/Meaty_Skeleton - This is my template operating system and uses a sysroot.

As for your original question, to cross-compile a native compiler (binutils, gcc) for your OS, you follow the instructions in Cross-Porting Software. However, you want to use a sysroot while building binutils and gcc, but you don't want the packages to remember that sysroot after installation. Use --with-build-sysroot=/home/you/youros/sysroot and --with-sysroot=/. That effectively disables the system root after installation. I don't think I've yet written a wiki article on a native gcc, but it's basically to combine OS Specific Toolchain with Cross-Porting Software and this paragraph.

I hope that helped, let me know if you have further question.

[BrightLight]

I've ported a lot of software to my OS, including a fully functional gcc and binutils toolchain.

Please have mercy to those who wish to port anything to their OS

[Peterbjornx]

http://wiki.osdev.org/Cross-Porting_Software - This is the important tutorial I want to make sure you've seen. It documents how to reliably cross-compile third party software the *right* way. From your original post, I get the impression you're doing this entirely wrong. You are meant to set --prefix to the location on your OS where it will be installed, it has nothing to do with your local build machine. After building, set DESTDIR in the make install step to add a second prefix for the purpose of installation. This is useful for package management, but also for cross-compilation where you want to install into your system root.
I'm not entirely sure if you use sysroots and whether you understand their use. They're crucial for proper cross-compilation and you should use them.

If you are a bit curious how sysroots and such should be used:
http://wiki.osdev.org/Meaty_Skeleton - This is my template operating system and uses a sysroot.

Since when do these resources exist? I couldn't find anything when I was working on this and am still left with a very messy cross compilation system.

[sortie]

Meaty Skeleton is a year old. Cross-Porting Software is some months old. I basically created the articles to show how to cross-compile operating systems and ports properly. I know what you mean by a messy cross compile system, it took me a while to get to these recommendations. Be sure to let me know if you have further questions or desire further wiki articles on similar subjects.

Porting is half making your cross scripts more intelligent and robust at setting up the environment so it plays by the rules, and half fixing the bullshit that third party software does so they also play by the rules.