ld Is Now A Cross Link-Editor
Ali Bahrami Wednesday March 19, 2008
Until yesterday, ld, the Solaris link-editor, was a native linker. This means that it was only able to link objects for the same machine that the linker was running on. To link sparc objects required the use of of a sparc machine, and x86 objects required an x86 system.
With the integration of
into Solaris Nevada build 87, the Solaris ld became a cross link-editor. Now, ld running on any type of hardware can link objects for any of the systems Solaris supports. This is currently sparc and x86, but there are people playing with OpenSolaris on other hardware too, so who knows what we might end up with?
6671255 link-editor should support cross linking
The user interface to this new capability is a simple extension of ld's traditional behavior. Traditionally, ld establishes the class (whether the object is 32 or 64-bit) of the object being generated by examining the first ELF object processed from the command line. In the case where an object is being built solely from an archive library or a mapfile, the -64 command line option is available to explicitly override this default. We have extended this to also determine the machine type of the object to produce:
Of course, it's a rare program that doesn't link against at least one system library. You're going to need libc, if nothing else. To do a successful cross-link, you'll need to have an image of the root filesystem for a system of the target type. There are many ways to do this. For testing purposes, I used a sparc and x86 system, using NFS to allow each system to see the root filesystem of the other.
Even though we now have a cross link-editor, we expect that the vast majority of links will be native, for the machine running the linker. We decided to pursue cross linking anyway, for two reasons:
A cross link-editor is a significant step, but is of little use unless you also have a cross-compiler and assembler. The GNU gcc compiler can be built as a cross compiler, and that should be very helpful for OpenSolaris ports. However, the Sun Studio compilers are native compilers, so it will still be awhile before I can use my amd64 desktop to build a sparc version of Solaris as part of work at Sun. We've taken a first step. It will be interesting to see what follows.
I believe that an error was made in the implementation of "-z target=..."
What's the error? It's inconsistent.
should be either:
b) i86pc (or i386/amd64, if that is more appropriate)
and NOT "x86", as that does not exist on Solaris. Anywhere.
The all-encompassing platform for "x86" and "x64" is i86pc.
Just like it wouldn't make sense to have "-z target=sparcv8plusvis".
Can this please be fixed?
Pretty please with sugar on top.
This bothers me so much, I'm even prepared to put in the work myself, if you'll sponsor me.
I certainly hope this is the worst mistake I've made... :-)
I chose x86 because that is the all-encompassing token used by the C preprocessor. __x86 is defined for either 32 or 64-bits, while __i386 is defined for 32-bits only and __amd64 for 64-bits. So while I see your point with i86pc (the value returned by uname), I'm not really convinced that x86 is a worse choice for this linker option than i86pc.
So my counter arguments are (1) Widely understood term (2) Has compiler affinity, (3) Neither PSARC nor my Solaris savy code reviewers had an issue, (4) The -ztarget option is unlikely to see significant use anyway, as the linker usually figures out the machine from the first object.
If I've failed to convince you, please feel free to email me (I believe you can derive the address based on my name and the usual @Sun.COM) and we'll work it out. Thanks for your interest.
| Avoiding LD_LIBRARY_PATH|| Cost Of ELF Symbol Hashing|