28 Apr
2018
28 Apr
'18
7:43 p.m.
Hi,
I released uClibc-ng 1.0.30 today.
Many thanks to Dave Flogeras who pushed me to my limits to
get the annyoing dlclose() issue fixed.
Short summary:
748422473 (HEAD -> master, tag: v1.0.30, origin/master, origin/HEAD,
github/master) bump for release 1.0.30
3f100edcc mention Tile architecture
14be0795f libdl: first execute all destructors, then munmap library
132decd2a libdl: calculate the length for second parameter of
munmap.
04a676f3c linuxthreads: implement pthread_condattr_{s,g}etclock()
d86bd3529 libdl: end must be bigger than start
8d7723d1c libdl: remove gcc warnings
d89de5cba libiconv: remove function, which is not available w/o
libiconv a4 macros
35105679b libdl: fix problem with unmapping
eb560ac79 libdl: better checking and logging for ctors/dtors
744e199bb libdl: remove dead code
0c8cc6e7e libdl: remove LDSO_NO_CLEANUP
07dfe7c86 libdl: cleanup old inline changelog
aaf1b2f56 Revert "libdl: fix dlclose() issue"
343fb004d common/sendfile.c: bugfix can't support offset is NULL
2d8a38e1a Revert "common/sendfile.c: bugfix can't support offset is
NULL"
ad6c75c47 lseek.c: bugfix ltp lseek01.c
b00fd230e common/sendfile.c: bugfix can't support offset is NULL
f42d18f06 or1k: add F_{DUPFD_CLOEXEC, SETPIPE_SZ, GETPIPE_SZ}
161d237ad use __NR_newfstatat only for modern Linux architectures
91e21d251 hppa: fix runtime issues
8be3a69f1 csky: support bsd-setjmp and bsd-_setjmp.
bf4c2d242 libdl: fix dlclose() issue
5bdc2b4de Revert "Revert "libdl: fix size parameter when unmap
library in dlclose""
490e84f5e tile: add basic support for tilegx
6e627523e sparc32: Add nop before __startcontext to stop unwinding
01e9f2f20 utils: fix compile of msgfmt/msgmerge
c03cce8f7 fenv: only allow for ppc e500
best regards
Waldemar
29 Apr
29 Apr
9:31 a.m.
On 4/28/18 3:43 PM, Waldemar Brodkorb wrote:
Hi,
I released uClibc-ng 1.0.30 today.
Many thanks to Dave Flogeras who pushed me to my limits to
get the annyoing dlclose() issue fixed.
I have not been successfully able to update uclibc-ng past 1.0.26 on
Gentoo because of various issues. I was hoping 1.0.30 would fix these,
but its even worse. So far I've tested amd64 and i686. On amd64 I'm
getting a situation where /etc/ld.so.cache is not being respected.
Gentoo places libstdc++.so at
/usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0. ld.so.conf looks like
the following
/usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0
/lib
/usr/lib
/usr/local/lib
There is no problem compiling c++ however, it can't link at runtime:
# echo "int main() { return 0; }" > test.cpp
# g++ -o test test.cpp
# ./test
/root/test: can't load library 'libstdc++.so.6'
# LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0 ./test
#
So I'm in the situation where in order to build a gentoo system using
uclibc-ng on amd64, I must pass LD_LIBRARY_PATH env var to emerge, not
to mention any other executables consuming libstdc++. This effects
packages like gmp, eudev and other critical core packages. Its
important to note that I do not have this issue with i686. I'll try to
test arm and ppc later.
A lot of the linking code has been touched. I could do a git bisect but
I don't have the time to dedicate to this. Any clue on the fix?
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : basile(a)freeharbor.net
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
10:52 a.m.
Hi Anthony,
Anthony G. Basile wrote,
On 4/28/18 3:43 PM, Waldemar Brodkorb wrote:
I am not sure any change in uClibc-ng is related to this issue.
Could it be a configuration change I introduced while trying to get
icu4c compilation fixed:
@@ -121,21 +121,19 @@
SUPPORT_LD_DEBUG_EARLY
UCLIBC_HAS_CTYPE_UNSAFE
UCLIBC_HAS_LOCALE
- UCLIBC_HAS_SSP_COMPAT
+ LDSO_SAFE_RUNPATH
)
# These are forced on
defs_y=(
- COMPAT_ATEXIT
DO_C99_MATH
DO_XSI_MATH
FORCE_SHAREABLE_TEXT_SEGMENTS
LDSO_GNU_HASH_SUPPORT
- LDSO_PRELINK_SUPPORT
LDSO_PRELOAD_FILE_SUPPORT
+ LDSO_RUNPATH
LDSO_RUNPATH_OF_EXECUTABLE
LDSO_STANDALONE_SUPPORT
Either LDSO_SAFE_RUNPATH or LDSO_RUNPATH might change the behaviour
of ld.so.
Why I have these symlinks in my Gentoo amd64 system:
ls -la /usr/lib/libstdc++.so*
lrwxrwxrwx 1 root root 51 Jan 28 14:58 /usr/lib/libstdc++.so ->
./gcc/x86_64-gentoo-linux-uclibc/7.2.0/libstdc++.so
lrwxrwxrwx 1 root root 53 Jan 28 14:58 /usr/lib/libstdc++.so.6 ->
./gcc/x86_64-gentoo-linux-uclibc/7.2.0/libstdc++.so.6
lrwxrwxrwx 1 root root 58 Jan 28 14:58 /usr/lib/libstdc++.so.6.0.24
-> ./gcc/x86_64-gentoo-linux-uclibc/7.2.0/libstdc++.so.6.0.24
wbx@tin ~ $
May be I added them when having issues. :(
When the uClibc-ng ldconfig has issues, may be this commit is
the culprit?
2a3bb4daf5778c5875674cd26a3c75b3d460a042
All other ldso changes where dlclose() related.
best regards
Waldemar
Hi,
I released uClibc-ng 1.0.30 today.
Many thanks to Dave Flogeras who pushed me to my limits to
get the annyoing dlclose() issue fixed.
I have not been successfully able to update uclibc-ng past 1.0.26 on
Gentoo because of various issues. I was hoping 1.0.30 would fix these,
but its even worse. So far I've tested amd64 and i686. On amd64 I'm
getting a situation where /etc/ld.so.cache is not being respected.
Gentoo places libstdc++.so at
/usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0. ld.so.conf looks like
the following
/usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0
/lib
/usr/lib
/usr/local/lib
There is no problem compiling c++ however, it can't link at runtime:
# echo "int main() { return 0; }" > test.cpp
# g++ -o test test.cpp
# ./test
/root/test: can't load library 'libstdc++.so.6'
# LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0 ./test
#
So I'm in the situation where in order to build a gentoo system using
uclibc-ng on amd64, I must pass LD_LIBRARY_PATH env var to emerge, not
to mention any other executables consuming libstdc++. This effects
packages like gmp, eudev and other critical core packages. Its
important to note that I do not have this issue with i686. I'll try to
test arm and ppc later.
A lot of the linking code has been touched. I could do a git bisect but
I don't have the time to dedicate to this. Any clue on the fix?
11:09 a.m.
On 4/29/18 6:52 AM, Waldemar Brodkorb wrote:
Why I have these symlinks in my Gentoo amd64 system:
ls -la /usr/lib/libstdc++.so*
lrwxrwxrwx 1 root root 51 Jan 28 14:58 /usr/lib/libstdc++.so ->
./gcc/x86_64-gentoo-linux-uclibc/7.2.0/libstdc++.so
lrwxrwxrwx 1 root root 53 Jan 28 14:58 /usr/lib/libstdc++.so.6 ->
./gcc/x86_64-gentoo-linux-uclibc/7.2.0/libstdc++.so.6
lrwxrwxrwx 1 root root 58 Jan 28 14:58 /usr/lib/libstdc++.so.6.0.24
-> ./gcc/x86_64-gentoo-linux-uclibc/7.2.0/libstdc++.so.6.0.24
wbx@tin ~ $
These sym links are wrong and we can't really live with them because of
how we build stuff in Gentoo. We have to be able to use ld.so.conf.
This problem is worst with libstdc++.so, but there are numerous packages
that will break unless ld.so.conf works.
May be I added them when having issues. :(
When the uClibc-ng ldconfig has issues, may be this commit is
the culprit?
2a3bb4daf5778c5875674cd26a3c75b3d460a042
All other ldso changes where dlclose() related.
best regards
Waldemar
I can look at that. If possible, can you periodically test against
stock stage3's obtained at the following. Those are the stage3's I
maintain. The are all built on native hardware.
https://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64…
https://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3-i686-uc…
https://distfiles.gentoo.org/experimental/arm/uclibc/
https://distfiles.gentoo.org/experimental/ppc/uclibc/
https://distfiles.gentoo.org/experimental/mips/uclibc/mips32r2/
https://distfiles.gentoo.org/experimental/mips/uclibc/mipsel3/
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : basile(a)freeharbor.net
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
2399
days inactive
2400
days old
3 comments
2 participants
participants (2)
-
Anthony G. Basile -
Waldemar Brodkorb