illumos gate

Webrev: http://cr.illumos.org/~webrev/andy_js/7550/

Before fix:

# ldd /usr/bin/ld
        libld.so =>      (file not found)
        libelf.so.1 =>   /usr/bin/../../lib/libelf.so.1
        libc.so.1 =>     /usr/bin/../../lib/libc.so.1
        libm.so.2 =>     /lib/libm.so.2

After fix:

# ldd /usr/bin/ld
        libld.so.4 =>    /usr/bin/../../lib/libld.so.4
        libelf.so.1 =>   /usr/bin/../../lib/libelf.so.1
        libc.so.1 =>     /usr/bin/../../lib/libc.so.1
        liblddbg.so.4 =>         /lib/liblddbg.so.4
        libm.so.2 =>     /lib/libm.so.2

Andrew Stormont wrote:

Before fix:

[...]

After fix:

[...]

please show: elfdump -d /usr/bin/ld
and - where is your /usr/bin/ld come from?
what package?
what is your build env based on?
very strange to see this issue - you have broken build env if your installed ld to build host couldn't found dependencies

If you want to know what caused this it's simple: it linked against a copy of libld without a SONAME. If the symlink had been in place this wouldn't have happened.

Andrew Stormont wrote:

If you want to know what caused this it's simple: it linked against a copy of libld without a SONAME. If the symlink had been in place this wouldn't have happened.

why i need to do it?
could you please show issue with original build env based on illumos-gate - where we have this issue?

You probably don't need it.

Have you seen how joyent build SmartOS? They have a strap/proto split. I'm doing something very similar. In my case there's also a linker in the strap area (which I referred to in my email). The linker in the strap area contains un-versioned (as in no SONAME) libraries, because this is what 'dmake native-proto' produces, and part of where the problem comes from. The build is erroneously picking up these libraries and that's why the linker that gets produced is busted. Installing the symlinks into the proto area isolates against this happening.

i know about smartos build env and they have a lot of issues and try to work on resolve it.
they try to fix his issues by providing files/links to his image - but it is not good way for resolve issues and it's hack.
my -1 for ld with ld libs links to strap-proto/final-proto - it is big mistake.
you can copy final ld with ld libs to strap-proto and it will work because ld is using $ORIGIN in RPATH and will use his libs in first place. BUT, ld from STRAP-PROTO will use incorrect libc - from build host.
have to understand it - based on SECFLAG implementation - you have to build build dependencies for LD first -> build LD with libs -> and use updated LD with updated libs for final illumos build - it is my goal and i don't understand issue what you try to resolve by ld libs links to final PROTO or STRAP-PROTO - sgs/ld build is fine to be isolated - your hack can break it.

In the case of a cross build you want the host version of libc to be used. These tools are part of the toolchain, and as such are supposed to run on the build host.

I'm not sure any of this is relevant though. You are -1'ing a change different from the one I've proposed.