Project

General

Profile

Bug #7550

sgs components are building against libraries outside of the proto area

Added by Andrew Stormont over 2 years ago. Updated over 2 years ago.

Status:
In Progress
Priority:
Normal
Category:
-
Start date:
2016-11-08
Due date:
% Done:

0%

Estimated time:
Difficulty:
Bite-size
Tags:
needs-triage

Description

because some dev symlinks aren't being created.

History

#2

Updated by Andrew Stormont over 2 years ago

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
#3

Updated by Igor Kozhukhov over 2 years ago

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

#4

Updated by Andrew Stormont over 2 years ago

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.

#5

Updated by Igor Kozhukhov over 2 years ago

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?

#6

Updated by Andrew Stormont over 2 years ago

You probably don't need it.

#7

Updated by Andrew Stormont over 2 years ago

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.

#8

Updated by Igor Kozhukhov over 2 years ago

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.

#9

Updated by Andrew Stormont over 2 years ago

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.

#10

Updated by Andrew Stormont over 2 years ago

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

Also available in: Atom PDF