OSDev.org

Before anyone starts redirecting me to the wiki, I have read that, honest. I have read numerous resources on how to do this, and while I can get it to compile, I cannot get it to 'work'.

I want to build binutils with at least pe-x86_64 support. To accomplish this, I decided to '--enable-targets=pe-x86-64'. This worked, compiled, and I could even use ld to link. What it did not have however, is a "--susystem" option.

Confused as I was, I tried numerous variations like replacing the dash with an underscore, and even building for all targets. This is my current configure script: This does compile, and once installed it also runs. It has an amazing amount of targets... but I cannot use '--subsystem' on ld.

I finally tried to make a binutils that exclusively targets pe-x86_64, using --target=pe-x86_64. This worked and I was able to use --subsystem.

This is not what I want to do though, I do not want pe-x86_64 to be my default target. I want to replace my current linker with the cross-enabled one, and thus I only want pe-x86_64 as an option. What am I doing wrong here? How do I build this?

The "correct" way of doing things, which most people - including me - would recommend, is to make one toolchain for each target.
I know this is a bad answer, but you might want to reconsider...

As said above, you should use a single target as per toolchain.

Some targets have special requirements for kernel development, and building "rare" ones is not for the faint of heart. You should know the options to pass as per target, the Wiki for example includes the ones for i386. I'm not completely sure, but I think your problem with --subsystem is caused by the fact that PE files work with them, but most formats don't (at least in that way). If you read (and have the look to find) information about the internals of Windows NT, you'll discover that an app environment at runtime is defined by its "subsystem". Resume: --subsystem works with PE almost only.

As a side (but important note): DO NOT EVER build a toolchain for everything. Remember the high-portability of GNU products. GCC and binutils have a incredible amount of targets (as you already said). It will take both too much disk space and build time.

If your OS supports multiple formats, build a toolchain specific as per everyone. Also you could try making a toolchain specific for your OS (See the wiki for more info).

I've know readed a bit about ld in MinGW, and it seems that I was correct. --subsystem is ONLY for PE, and specially the "fastest" OS ever invented, the loved-by-none but used-by-all-newbies Windows!!!

KemyLand wrote:Remember the high-portability of GNU products. GCC and binutils have a incredible amount of targets (as you already said). It will take both too much disk space and build time.

And attempts to reuse toolchains makes both noobs and pros do really really stupid things with their toolchain.

Why is building a universal toolchain considered bad practise? It it the most convenient approach, only need to update 1 package to update all your toolchains,and it'll take less space on your hard drive...

At the moment I am using one only targeted at pe-x86-64 (although binutils likes to dump in some extra trash in the supported targets list for some reason). What I would like to know though is how to make one for multiple targets work properly?

Also, I would like to point out, that '--subsystem' is present on some targets for my current build, just not the pe-x86-64 one.

KemyLand wrote:Remember the high-portability of GNU products. GCC and binutils have a incredible amount of targets (as you already said). It will take both too much disk space and build time.

I doubt the disk space and build time still justify nowadays, considering all the trouble and mess involved, how cheap an 2TB disk is, and how infrequent you rebuild the entire toolchain.

Binero wrote:What I would like to know though is how to make one for multiple targets work properly?

You may be able to reuse one single binutils, however as your own OS is not contribute to the mainstream GCC(or llvm), no one can test it and it may break for your OS when you update the host toolchain, you build a cross-compiler just to prevent that from happening.

bluemoon wrote:

KemyLand wrote:Remember the high-portability of GNU products. GCC and binutils have a incredible amount of targets (as you already said). It will take both too much disk space and build time.

I doubt the disk space and build time still justify nowadays, considering all the trouble and mess involved, how cheap an 2TB disk is, and how infrequent you rebuild the entire toolchain.

I have 100GB limit left on my computer (out of 500), and no money to even think about an upgrade. I still don't think this is a real reason to me though. My real problem is I want to use a single tool, there is no *point* in having the same tool twice. Splitting them up makes building harder and more complex, and it isn't automatically packaged by my package manager.

Binero wrote:there is no *point* in having the same tool twice.

There are valid points. Read the wiki posted by Combuster: [wiki]Why_do_I_need_a_Cross_Compiler%3F[/wiki].

bluemoon wrote:

Binero wrote:there is no *point* in having the same tool twice.

There are valid points. Read the wiki posted by Combuster: [wiki]Why_do_I_need_a_Cross_Compiler%3F[/wiki].

The only 'points' I see in there are gcc related. I am not using gcc, and I have no intention of doing so. I only want a cross-binutils, or even more specificly, a cross-ld.

The only 'points' I see in there are gcc related.

Looks like the oldest item in the book went missing from the most relevant pages:

The wiki, on MinGW wrote:4. Linker claims to support ELF, but says "PE operations on non PE file" if you try to use ELF.

The worst part of the gnu-efi hack is also played on binutils, and not gcc.

Combuster wrote:

The only 'points' I see in there are gcc related.

Looks like the oldest item in the book went missing from the most relevant pages:

The wiki, on MinGW wrote:4. Linker claims to support ELF, but says "PE operations on non PE file" if you try to use ELF.

The worst part of the gnu-efi hack is also played on binutils, and not gcc.

Is that relevant on a Linux environment?

Also it seems like no one really knows how to properly compile binutils? o.O

Binero wrote:Why is building a universal toolchain considered bad practise? It it the most convenient approach, only need to update 1 package to update all your toolchains,and it'll take less space on your hard drive...

Because it doesn't work that way. This is not supported by binutils and gcc! You might be able to make a target that supports a few other targets, but it doesn't scale. This is not a question of properly, the proper way is to have a toolchain for each target. That's how it is designed.

Contrast how clang supports many targets in a single executable using --target. That's how they designed it. These are two different designs. Bad things happen if you treat binutils and gcc this way.

sortie wrote:

Binero wrote:Why is building a universal toolchain considered bad practise? It it the most convenient approach, only need to update 1 package to update all your toolchains,and it'll take less space on your hard drive...

Because it doesn't work that way. This is not supported by binutils and gcc! You might be able to make a target that supports a few other targets, but it doesn't scale. This is not a question of properly, the proper way is to have a toolchain for each target. That's how it is designed.

Contrast how clang supports many targets in a single executable using --target. That's how they designed it. These are two different designs. Bad things happen if you treat binutils and gcc this way.

Do you mean lld, or can clang link too these days?