24 Oct
2017
24 Oct
'17
4:15 p.m.
Hi,
I've upgraded Optware-ng uClibc-ng from 1.0.15 to 1.0.26 a while ago. It
called for recompilation of most of the packages, but this issue seems to
be resolved now. The issue I'd like to report is that when the linker
(ld-uClibc.so.0) is built, UCLIBC_RUNTIME_PREFIX seems to evaluate to "/",
even though RUNTIME_PREFIX is set to "/opt" (see attached config). I had to
resort to patching uClibc-ng sources (
https://github.com/Optware/Optware-ng/blob/master/sources/buildroot-armeabi…,
%OPTWARE_TARGET_PREFIX% is replaced with "/opt") to get this fixed. It
wasn't so with 1.0.15, setting RUNTIME_PREFIX to "/opt" made linker look
for libs only in "/opt/lib", "/opt/usr/lib", etc., and not in
"/lib" and
such. Is this change intended, or is it a bug?
Thanks,
Alex
P.S. Another thing I noticed that you may want to know. Looking
at ldso/ldso/dl-elf.c, this line seems to be wrong:
UCLIBC_RUNTIME_PREFIX "usr"
LDSO_MULTILIB_DIR,
since LDSO_MULTILIB_DIR defaults to "lib" -- not "/lib", so I'm
guessing
you want it this way:
UCLIBC_RUNTIME_PREFIX "usr/"
LDSO_MULTILIB_DIR,
25 Oct
25 Oct
5:15 p.m.
Hi Alex,
Alex Potapenko wrote,
Hi,
I've upgraded Optware-ng uClibc-ng from 1.0.15 to 1.0.26 a while ago. It called
for recompilation of most of the packages, but this issue seems to be resolved
now. The issue I'd like to report is that when the linker (ld-uClibc.so.0) is
built, UCLIBC_RUNTIME_PREFIX seems to evaluate to "/", even
though RUNTIME_PREFIX is set to "/opt" (see attached config). I had to resort
to patching uClibc-ng sources (https://github.com/Optware/Optware-ng/blob/
master/sources/buildroot-armeabi-ng/uclibc-ng-patches/010-ldso.patch,
%OPTWARE_TARGET_PREFIX% is replaced with "/opt") to get this fixed. It
wasn't
so with 1.0.15, setting RUNTIME_PREFIX to "/opt" made linker look for libs
only
in "/opt/lib", "/opt/usr/lib", etc., and not in "/lib" and
such. Is this change
intended, or is it a bug?
I think it is not intented. Do you see in which commit the
regression was introduced?
I don't remember any change in this area.
May be a side effect of all-in-one libc.so changeset?
best regards
Waldemar
9:18 p.m.
On Wed, Oct 25, 2017 at 8:15 PM, Waldemar Brodkorb <wbx(a)uclibc-ng.org>
wrote:
I think it is not intented. Do you see in which commit
the
regression was introduced?
I don't remember any change in this area.
After waisting an hour or so, I realized that build system I was using set
RUNTIME_PREFIX from command line, so it's not uClibc-ng issue. Sorry for
false-alarm.
The MULTILIB_DIR issue, however, is valid. One can see line similar to the
following when opening the built linker with nano ("/" runtime prefix,
default MULTILIB_DIR="lib"):
^@$ORIGIN^@.^@/lib/:/usrlib/^@/lib:/usr/lib:/usr/X11R6/lib^@ld-uClibc.so.1^@Standalone
execution is not enabled
which after using the attached patch changes to valid
^@$ORIGIN^@.^@/lib/:/usr/lib/^@/lib:/usr/lib:/usr/X11R6/lib^@ld-uClibc.so.1^@Standalone
execution is not enabled
--
Best regards,
Alex Potapenko
3 Nov
3 Nov
7:21 p.m.
Hi Alex,
Alex Potapenko wrote,
On Wed, Oct 25, 2017 at 8:15 PM, Waldemar Brodkorb
<wbx(a)uclibc-ng.org> wrote:
I think it is not intented. Do you see in which commit the
regression was introduced?
I don't remember any change in this area.
After waisting an hour or so, I realized that build system I was using set
RUNTIME_PREFIX from command line, so it's not uClibc-ng issue. Sorry for
false-alarm.
The MULTILIB_DIR issue, however, is valid. One can see line similar to the
following when opening the built linker with nano ("/" runtime prefix, default
MULTILIB_DIR="lib"):
^@$ORIGIN^@.^@/lib/:/usrlib/^@/lib:/usr/lib:/usr/X11R6/lib^@ld-uClibc.so.1^
@Standalone execution is not enabled
which after using the attached patch changes to valid
^@$ORIGIN^@.^@/lib/:/usr/lib/^@/lib:/usr/lib:/usr/X11R6/lib^@ld-uClibc.so.1
^@Standalone execution is not enabled
Thanks, applied and pushed,
Waldemar
2387
days inactive
2397
days old
3 comments
2 participants
participants (2)
-
Alex Potapenko -
Waldemar Brodkorb