OSDev.org

Candy did quite some work on researching how-to build a cross-compiler for the x86_64 target. Thanks for that (since I consider the whole cross-compiler page to be my "baby" ).

Now, I'm a bit confused about that target thing - is it correct that binutils / GCC don't support a "plain" ELF target for x86_64, but insist on a "linux" target? (Since that's probably where your problems with the C++ compilation come from...)

Solar wrote: Candy did quite some work on researching how-to build a cross-compiler for the x86_64 target. Thanks for that (since I consider the whole cross-compiler page to be my "baby" ).

Now, I'm a bit confused about that target thing - is it correct that binutils / GCC don't support a "plain" ELF target for x86_64, but insist on a "linux" target? (Since that's probably where your problems with the C++ compilation come from...)

Yes, exactly.

As for the compilation, I set the target to x86_64-linux on my own pc, and after some 10 - 15 hours compiling it complained there was no x86_64-pc-linux-ar. *duh* so now it's recompiling with all available resources to create one for x86_64-pc-linux, with only C.

I'm going to try to hack the sources to come up with the fourth nonexistant of i686-pc-linux, x86_64-pc-linux and i686-elf (so I'm trying to make x86_64-elf). The easy solution has been tried, didn't work.

As for the compiler itself, I'll be happy when I get a C compiler (won't need c++ for a while... but for helping you with pro-pos it's kind of necessary).

-edit

Have got a working one! Just keep-going .

the compiler tries to do libs no matter what you do, so use -k to keep going, then install with -k as well, and use the installed binary.

Note, I've added sections to the page about the useful/uselessness of --disable-shared, info about canadian cross, and some final hints on the x86_64 compiler I've now got

I reworked the page... this is getting bigger than I thought.

I also removed references to --disable-shared, as they're just confusing now until we write up the section about bootstrapping).

Candy, please double-check the changes I made to the x86_64 and Canadian Cross sections. I haven't tried this stuff, so I might be wrong.

Solar wrote: I reworked the page... this is getting bigger than I thought.

Might be an idea to split it up into multiple pages? Perhaps making some (or all) of the special things (x86-64, canadian cross) subpages?

I also removed references to --disable-shared, as they're just confusing now until we write up the section about bootstrapping).

No, that's not true. If you read my note carefully, you can not move the compiled binaries on your own system (to a different dir f.ex.) if you use dynamic linking. You cannot move them to a different system (at all) if you use static linking. The option IS useful, considering the amount of people that compile in one place and then use in a different one.

Candy, please double-check the changes I made to the x86_64 and Canadian Cross sections. I haven't tried this stuff, so I might be wrong.

You were right about those things.

Note however, that exactly because of that static/dynamic stuff I don't distribute my binaries, even though I'm inclined to do so. I run them on my P120 laptop, whereas I compiled them on a P4-2600 box for speed. This meant I had to do dynamic linking, and that meant that the directory could not be changed. Since the P4 box is not mine (it's my shell @ internet server actually) I cannot compile to /usr/cross, so I'm forced to put it in /home/candy/gcc/cross on my laptop too. Now, for me that doesn't really matter, but I don't see anybody else actually doing that .

I'll try to get a decent compilation to /usr/cross with dynamic linking up & stripped, and then I'll distribute it via my site. Until then, you'll have to DIY.

Candy wrote: Might be an idea to split it up into multiple pages? Perhaps making some (or all) of the special things (x86-64, canadian cross) subpages?

I hope that the issue (of x86_64-elf not being supported) is a temporary one, which would make most of that subchapter go away.

If you read my note carefully, you can not move the compiled binaries on your own system (to a different dir f.ex.) if you use dynamic linking.

Erm... you can move the binaries (and the shared libs) allright; you just have to make sure the libraries are in the library search path - set LD_LIBRARYPATH if need be. (I'm testing this right now but am pretty sure.)

You cannot move them to a different system (at all) if you use static linking.

I haven't tested this, but find it hard to believe. The very idea of static linking is to make the executable independent of the system, isn't it?

Solar wrote:

If you read my note carefully, you can not move the compiled binaries on your own system (to a different dir f.ex.) if you use dynamic linking.

Erm... you can move the binaries (and the shared libs) allright; you just have to make sure the libraries are in the library search path - set LD_LIBRARYPATH if need be. (I'm testing this right now but am pretty sure.)

uhm... the point is that you do not use the standard libraries but the new ones, even though they have the same name. The way this is handled is by including the entire path in the header (yes, I checked that with hexdump), so if you move it the path is incorrect and there's a damn good chance it'll use one of the normal ones, that do not support 64-bit code (for instance). If they're both x86 that doesn't matter.

You cannot move them to a different system (at all) if you use static linking.

I haven't tested this, but find it hard to believe. The very idea of static linking is to make the executable independent of the system, isn't it?

Well, yes. It's independant of the shared libraries that you would normally need to run the program. That is to say, you can run it on all computers and you don't have to worry about the libraries. You do have to worry about instruction set presence though. So, it doesn't make it really independant of the system, it just makes it independant of the libraries. I'd love the GCC people adding a new thing, which makes it include its own libraries statically but the default libs dynamically... that'd rip out the entire reason I have to make it dynamic (with all the consequeces that has again).

Candy wrote:

Solar wrote: I haven't tested this, but find it hard to believe. The very idea of static linking is to make the executable independent of the system, isn't it?

Well, yes. It's independant of the shared libraries that you would normally need to run the program. That is to say, you can run it on all computers and you don't have to worry about the libraries. You do have to worry about instruction set presence though. So, it doesn't make it really independant of the system, it just makes it independant of the libraries. I'd love the GCC people adding a new thing, which makes it include its own libraries statically but the default libs dynamically... that'd rip out the entire reason I have to make it dynamic (with all the consequeces that has again).

This whole Canadian Cross stuff gives me headaches. :-\ ;D

I got the thing with dynamic linking right now (I think), but the static linking still confuses me.

The instruction set doesn't matter for static vs. dynamic linking, or does it? I mean, the executable itself (statically linked or not) is fully dependent on the instruction set, and can only be run on a CPU with that instruction set.

How could an executable be moved to a different machine just because it's linked dynamically? ???

Candy wrote: This meant I had to do dynamic linking, and that meant that the directory could not be changed. Since the P4 box is not mine (it's my shell @ internet server actually) I cannot compile to /usr/cross, so I'm forced to put it in /home/candy/gcc/cross on my laptop too. Now, for me that doesn't really matter, but I don't see anybody else actually doing that .

Hum... you could do with some trickery. Look up GCC configure options like --with-as=... and see if they might help. (I'm still fuzzy about this.)

Solar wrote: This whole Canadian Cross stuff gives me headaches. :-\ ;D

It took me 3 weeks to get a compiling version, can't say it's easy

I got the thing with dynamic linking right now (I think), but the static linking still confuses me.

The instruction set doesn't matter for static vs. dynamic linking, or does it? I mean, the executable itself (statically linked or not) is fully dependent on the instruction set, and can only be run on a CPU with that instruction set.

No, that's not the principal difference. The most obvious difference _is_ in place, if somebody decided to speed up his/her computer by compiling glibc or stdlib or whatever with -march=pentium4, then linking to those files will produce a p4-only executable no matter what options you specify otherwise. That's what the problem is with static linking on a fake canadian cross. Doing so on a true canadian cross will link with the recompiled glibc so that's no problem.

My entire point with the fake cross is that it's a lot easier to do (no sh*tload of compiling) but that it's heavily limited, and this is one of the points where it fails to be completely as flexible.

How could an executable be moved to a different machine just because it's linked dynamically? ???

Because it then links to the other computers libraries, which are made for that computer. If you do not link it dynamically, you limit it to the subset of computers that can run both the libc and the executable itself. If either is "optimized" for ppro or higher, I couldn't run it. Since I can control one, but not the other, don't include the other to make it copyable to all computers that fit your destination.

Hum... you could do with some trickery. Look up GCC configure options like --with-as=... and see if they might help. (I'm still fuzzy about this.)

That's not the problem. Still, I think that if you move the libraries elsewhere and tell LD to look in those dirs *FIRST* it'd work too. If it found the default dirs first however, you'd be screwed.

Both to bump this thread and because just about everybody has something to do with it:

GCC 3.4 is out! This means that /PROBABLY/ the cross-compiler is simplified, and probably most of your gcc specific parts are broken again. It's actually available (it was launched 20-4 but not available, I checked) at ftp://ftp.gnu.org/gnu/gcc.

Sorry if this is against forum rules, but I think most people will be happy to use the newer version.