Project

General

Profile

Bug #6204

Fix for #5935 breaks build

Added by Alexander Kolbasov over 4 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2015-09-04
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

It turns out that the fix for "5935 libavl should be a public interface" breaks the full build. The problem shows in tcpdump:

ld: fatal: file /lib/libavl.so.1: version 'ILLUMOS_1.0' does not exist:
required by file /root/imd-platform/build/proto//usr/lib/libvarpd.so.1
ld: fatal: file /lib/libavl.so.1: version 'ILLUMOS_1.0' does not exist:
required by file /root/imd-platform/build/proto//usr/lib/libidmap.so.1
ld: fatal: file processing errors. No output written to tcpdump
collect2: ld returned 1 exit status

ldd /root/imd-platform/build/proto//usr/lib/libidmap.so.1
libc.so.1 => /lib/libc.so.1
libavl.so.1 => /lib/libavl.so.1
libavl.so.1 (ILLUMOS_1.0) => (version not found)
libnsl.so.1 => /lib/libnsl.so.1
libnvpair.so.1 => /lib/libnvpair.so.1
libuutil.so.1 => /lib/libuutil.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libm.so.2 => /lib/libm.so.2

ldd /root/imd-platform/build/proto//usr/lib/libvarpd.so.1
libc.so.1 => /lib/libc.so.1
libavl.so.1 => /lib/libavl.so.1
libavl.so.1 (ILLUMOS_1.0) => (version not found)
libumem.so.1 => /lib/libumem.so.1
libidspace.so.1 => /usr/lib/libidspace.so.1
libnvpair.so.1 => /lib/libnvpair.so.1
libmd5.so.1 => /lib/libmd5.so.1
librename.so.1 => /usr/lib/librename.so.1
libbunyan.so.1 => /usr/lib/libbunyan.so.1
libnsl.so.1 => /lib/libnsl.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libm.so.2 => /lib/libm.so.2

The problem is that due to #6184 several libraries are used from the host rather than the photo area. As a result, we get this build failure.

History

#1

Updated by Robert Mustacchi over 4 years ago

So tcpdump is not built as part of illumos. So I'm having trouble understanding how this failure is occurring. Are you building against a proto area, something else? In addition, a stock ldd from a proto area will generally be meaningless as invoked, because you need to refer to libraries in the proto area.

#2

Updated by Igor Kozhukhov over 4 years ago

take a look : elfdump -d <lib>
you can try take a look RPATH
by original RPATH - we are using crle for searching shared libs at /lib:/usr/lib as default and by ldd you can see you try to use /lib/libavl.so.1 instead of from proto.

#3

Updated by Yuri Pankov over 4 years ago

  • Status changed from New to Feedback
#4

Updated by Yuri Pankov about 3 years ago

  • Status changed from Feedback to Closed

feedback timeout.

Also available in: Atom PDF