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,
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
On Wed, Oct 25, 2017 at 8:15 PM, Waldemar Brodkorb wbx@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
Hi Alex, Alex Potapenko wrote,
On Wed, Oct 25, 2017 at 8:15 PM, Waldemar Brodkorb wbx@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 enabledwhich 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
-
Alex Potapenko -
Waldemar Brodkorb