RE: problems with gnu make and stdout with uclibc nptl
-Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Natanael Copa Sent: den 9 april 2010 10:08 To: Bernhard Reutner-Fischer Cc: uclibc@uclibc.org Subject: Re: problems with gnu make and stdout with uclibc nptl On Thu, Apr 8, 2010 at 8:40 AM, Natanael Copa natanael.c...@gmail.com wrote: On Wed, Apr 7, 2010 at 11:20 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Does it still happen if you build master with LT_OLD and O0 (i.e. DODEBUG set)? Enabling runtime assertions did give an interesting result: make: libc/stdio/_stdio.c: 326: _stdio_validate_FILE: Assertion `stream-__modeflags == (0x0020U|0x0010U)' failed. The problem comes from 885f507317b6c8576ba2e298c2249d27ea6f8404 which breaks ABI compat and the gnu make i used was built against previous uclibc headers things went wrong. I think it would be nice if the MAJOR_VERSION changed every time the ABI changed as it gives people who does not do firmware style upgrades (i.e package managers) a chance to do clean upgrades. I think this alone is more than good enough reason to let next release be 1.x in stead of 0.9.32. (It still leaves 0.9.31 release as non-upgradeable) thanks! -- Natanael Copa Unless it has changed in the last years, there are no expressed guarantees regarding API and ABI stability for the 0.x.y releases of uClibc. AFAIK the stable API/ABI is intended for the 1.0.0 release. And with the upcoming integration of the NPTL support, I do not see this as the right time to go to 1.0.0 and lock down the API/ABI... //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
Peter Kjellerstedt wrote: Unless it has changed in the last years, there are no expressed guarantees regarding API and ABI stability for the 0.x.y releases of uClibc. AFAIK the stable API/ABI is intended for the 1.0.0 release. And with the upcoming integration of the NPTL support, I do not see this as the right time to go to 1.0.0 and lock down the API/ABI... Could the uclibc project then start using appropriate soname, so we can install multiple versions of the library if needed (e.g. when doing package based upgrade). # objdump -p /lib/libuClibc-0.9.30.1.so |grep SONAME SONAME libc.so.0 Would indicate that all 0.x are compatible. Basically, soname should be 0.x.y if all 0.x.y.z are supposed to be ABI compatible. Currently it seems that link.so and linkm.so macros explicitly set soname according to $(2). define link.so $(Q)$(INSTALL) -d $(dir $@) $(Q)$(RM) $@ $...@.$(2) $(dir $@)$(1) @$(disp_ld) $(Q)$(CC) $(LDFLAGS-$(notdir $@)) -Wl,-soname=$(notdir $@).$(2) \ $(NOSTDLIB_CFLAGS) -o $(dir $@)$(1) $(START_FILE-$(notdir $@)) \ -Wl,--whole-archive $(firstword $^) -Wl,--no-whole-archive \ $(LIBS-$(notdir $@)) $(LIBGCC) $(END_FILE-$(notdir $@)) $(Q)$(LN) -sf $(1) $...@.$(2) $(Q)$(LN) -sf $(1) $@ endef Those get called like: ./libc/Makefile.in: $(call linkm.so,$(libc_FULL_NAME),$(MAJOR_VERSION)) And that's defined like: Rules.mak:MAJOR_VERSION := 0 Resulting in above mentioned soname, which is completely broken regarding to how shared object ABI compatibility should be handled. Please fix soname. Thanks, Timo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
2010/4/12 Timo Teräs timo.te...@iki.fi: Peter Kjellerstedt wrote: Unless it has changed in the last years, there are no expressed guarantees regarding API and ABI stability for the 0.x.y releases of uClibc. AFAIK the stable API/ABI is intended for the 1.0.0 release. And with the upcoming integration of the NPTL support, I do not see this as the right time to go to 1.0.0 and lock down the API/ABI... fair enough ... Please fix soname. +1 -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
On Thu, Apr 8, 2010 at 8:40 AM, Natanael Copa natanael.c...@gmail.com wrote: On Wed, Apr 7, 2010 at 11:20 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Does it still happen if you build master with LT_OLD and O0 (i.e. DODEBUG set)? Enabling runtime assertions did give an interesting result: make: libc/stdio/_stdio.c: 326: _stdio_validate_FILE: Assertion `stream-__modeflags == (0x0020U|0x0010U)' failed. The problem comes from 885f507317b6c8576ba2e298c2249d27ea6f8404 which breaks ABI compat and the gnu make i used was built against previous uclibc headers things went wrong. I think it would be nice if the MAJOR_VERSION changed every time the ABI changed as it gives people who does not do firmware style upgrades (i.e package managers) a chance to do clean upgrades. I think this alone is more than good enough reason to let next release be 1.x in stead of 0.9.32. (It still leaves 0.9.31 release as non-upgradeable) thanks! -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
On Wed, Apr 7, 2010 at 11:20 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Wed, Apr 07, 2010 at 11:04:54AM +0200, Natanael Copa wrote: On Sun, Apr 4, 2010 at 4:42 PM, Austin Foxley aust...@cetoncorp.com wrote: On 04/03/2010 11:13 AM, Natanael Copa wrote: which means that stdout ends up with the error indicator set for some reason. I suspect this is a bug in uclibc-nptl. Interestingly enough, redirecting stdout to a file made the build complete. Any ideas on how to trace this down? Does this happen with the 0.9.31-rc? There aren't too many major differences in the stdio code between master and nptl. Ok, I tried with 0.9.31 and LINUXTHREADS_NEW and yes, same thing happens there. you should use LT_OLD on i386 but anyway. No. Due to bug #329 and #371 which are non-trivial to fix (and they caused asterisk go nuts with some load) we switched to .new, which has worked pretty ok (with a few patches). anyway, .new has issues to so the goal is getting nptl working. Does it still happen if you build master with LT_OLD and O0 (i.e. DODEBUG set)? Yes, and more important, it happenes on NPTL. (btw.. Gnu make does not link to libpthread) Which version of the compiler are you using? gcc (GCC) 4.4.3 -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
On Wed, Apr 7, 2010 at 11:20 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Does it still happen if you build master with LT_OLD and O0 (i.e. DODEBUG set)? Enabling runtime assertions did give an interesting result: make: libc/stdio/_stdio.c: 326: _stdio_validate_FILE: Assertion `stream-__modeflags == (0x0020U|0x0010U)' failed. -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
On Sun, Apr 4, 2010 at 4:42 PM, Austin Foxley aust...@cetoncorp.com wrote: On 04/03/2010 11:13 AM, Natanael Copa wrote: which means that stdout ends up with the error indicator set for some reason. I suspect this is a bug in uclibc-nptl. Interestingly enough, redirecting stdout to a file made the build complete. Any ideas on how to trace this down? Does this happen with the 0.9.31-rc? There aren't too many major differences in the stdio code between master and nptl. I tried to compile the 0.9.31 with linuxthreads(new) but i got into https://bugs.busybox.net/show_bug.cgi?id=1495 so i dont know. sorry. -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
_res is moved to .bss section with hidden attribute in 0.9.31. I get around this issue by removing attribute_hidden. libc/inet/resolv.c /*struct __res_state _res __attribute__((section (.bss))) attribute_hidden;*/ struct __res_state _res __attribute__((section (.bss))); On Wed, Apr 7, 2010 at 3:26 PM, Natanael Copa natanael.c...@gmail.com wrote: On Sun, Apr 4, 2010 at 4:42 PM, Austin Foxley aust...@cetoncorp.com wrote: On 04/03/2010 11:13 AM, Natanael Copa wrote: which means that stdout ends up with the error indicator set for some reason. I suspect this is a bug in uclibc-nptl. Interestingly enough, redirecting stdout to a file made the build complete. Any ideas on how to trace this down? Does this happen with the 0.9.31-rc? There aren't too many major differences in the stdio code between master and nptl. I tried to compile the 0.9.31 with linuxthreads(new) but i got into https://bugs.busybox.net/show_bug.cgi?id=1495 so i dont know. sorry. -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
On Sun, Apr 4, 2010 at 4:42 PM, Austin Foxley aust...@cetoncorp.com wrote: On 04/03/2010 11:13 AM, Natanael Copa wrote: which means that stdout ends up with the error indicator set for some reason. I suspect this is a bug in uclibc-nptl. Interestingly enough, redirecting stdout to a file made the build complete. Any ideas on how to trace this down? Does this happen with the 0.9.31-rc? There aren't too many major differences in the stdio code between master and nptl. Ok, I tried with 0.9.31 and LINUXTHREADS_NEW and yes, same thing happens there. -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
On Wed, Apr 7, 2010 at 11:04 AM, Natanael Copa natanael.c...@gmail.com wrote: On Sun, Apr 4, 2010 at 4:42 PM, Austin Foxley aust...@cetoncorp.com wrote: On 04/03/2010 11:13 AM, Natanael Copa wrote: which means that stdout ends up with the error indicator set for some reason. I suspect this is a bug in uclibc-nptl. Interestingly enough, redirecting stdout to a file made the build complete. Any ideas on how to trace this down? Does this happen with the 0.9.31-rc? There aren't too many major differences in the stdio code between master and nptl. Ok, I tried with 0.9.31 and LINUXTHREADS_NEW and yes, same thing happens there. FWIW, it happens with make -j12 and not with -j1. it start to smell like a race in Makefiles -nc -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
On Wed, Apr 7, 2010 at 11:34 AM, Natanael Copa natanael.c...@gmail.com wrote: On Wed, Apr 7, 2010 at 11:04 AM, Natanael Copa natanael.c...@gmail.com wrote: On Sun, Apr 4, 2010 at 4:42 PM, Austin Foxley aust...@cetoncorp.com wrote: On 04/03/2010 11:13 AM, Natanael Copa wrote: which means that stdout ends up with the error indicator set for some reason. I suspect this is a bug in uclibc-nptl. Interestingly enough, redirecting stdout to a file made the build complete. Any ideas on how to trace this down? Does this happen with the 0.9.31-rc? There aren't too many major differences in the stdio code between master and nptl. Ok, I tried with 0.9.31 and LINUXTHREADS_NEW and yes, same thing happens there. FWIW, it happens with make -j12 and not with -j1. it start to smell like a race in Makefiles Ok, I had 2 problems. One was that parallel builds does not work. Things didnt build in my 0.9.30.x environment. I have solved that now. But I still get write error in the 0.9.31 and nptl environments. So I suppose I need to start bisect? scares me since i belive there are other broken stuff along the way.. Other ideas how to dig this? -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
But I still get write error in the 0.9.31 and nptl environments. So I suppose I need to start bisect? scares me since i belive there are other broken stuff along the way.. feels like im talking to myself... I started bisect first commit that actually builds is 85ae389a56a20f0313001dcc4336eeaa6dcabf92 (master~473, Feb 13 11:11:35 2009) I building ghostscript with LD_LIBRARY_PATH pointing to that build ends up with write error too so its atleast a year old bug. Let me see if i can dig deeper with some manualy patching -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
On Wed, Apr 7, 2010 at 3:30 PM, Natanael Copa natanael.c...@gmail.com wrote:
Let me see if i can dig deeper with some manualy patching
Ok, I have a rough estimate where the bug was introduced: between
3e8067a62725780222fa90f2945f1d5599a5cdd6 and
1a21daadde12abfbb148b0bf07b26fbb56aa410a
Last working commit was b133fe1cac9f99b63ea56daf92caa1423b1289d0 after
that things start to go bad.
The next commit, 3e8067a62725780222fa90f2945f1d5599a5cdd6 the
buildscript for ghostscript does not even start. I get /bin/sh: symbol
'getopt': can't resolve symbol in lib '/bin/sh'. The following 30
commits didnt even let me start building ghostscript, even if uclibc
got built. I got things like broken gcc from configure script and
similar. First commit after, that actually let me build ghostscript,
but ends up with this mysterious Write error was
1a21daadde12abfbb148b0bf07b26fbb56aa410a
That is 30 commits. I could not get any closer than that, sorry.
So bug was introduced in some of the commits below. any ideas?
1a21daadde12abfbb148b0bf07b26fbb56aa410a rpc: ifdef out
xdrrec_{get,put}long if int32 == long, otherwise use xdrrec_{ge
t,put}int32 + trivial transform. eliminate warnings. des: small
shrink + eliminate a warning
7c640bbb18a519ed003d5fa80bad96eb204ed693 add
libc_hidden_proto(__cmsg_nxthdr) for mips
d763ce093b09afacb87498c2db21d6ce3df72a4f fix improperly hidden fputc_unlocked
32167ca3b6a36c0922bea30b2c44e78ccd5290ae fix improperly hidden
fwprintf. make two data objects static.
7357e8836f7c742602f59cc8f2b97382634c59b8 shring sugnal-relared stuff a
bit. BTW why constant memset is not inlined by gc
c?
35ae1599438a15568818bf09b493d7b49039d452 reduce sigset_t size for 128
bytes to 64 bits:
d4cb8007c785edaaba9f707bc83d6a33f562a059 Make
__UCLIBC_HAVE_ASM_CFI_DIRECTIVES__ visible in case the arch supports
this
feature. SH4 will use this in some aseembly files for the NPTL
implementation. Add now safely on trunk.
28075836bdd3771e55f97ee66f4d5d53d6c0e8d9 - make isascii visible again
TODO: *_l() should go
151b127c3a8678f491e0ec977eaa38e952b2e7bd This patch fixes locale-mbwc
test failures when __UCLIBC_HAS_LOCALE__ is disabl
ed and __UCLIBC_HAS_WCHAR__ is enabled. The only locale available when
__UCLIBC_HAS_LOCALE__ is disabled is the C locale
, the others locale are skipped.
f1358210f659767a87869e48de89299e84515ae9 - remove fstatfs() and
statfs() related headers upon request
20cff295659e9bd1bee2c316ee17a53cad693ea2 - revert 24148:24151
d8ea341e64250c2f4636c559562e8904037eda74 libc/string: need additional
work to remove libc_hidden_proto's properly
873228f50b0a83833e0f498010ffe3dcc75a9258 - hide locks
5fefc2d24a19675e9b7cce654ec06022de2738ba - remove some bloat that was
added in r23660 and subsequent r23698. The sbrk
lock is only needed for LT.old
9d6d4ac6476107b42a9bdca8e794fdb309aeca28 - hide some time related relocs
841a3b472edefdade4435128d1b47b2dee25841e Make wcsxfrm visible also
when LOCALE support is disabled.
c9209d6f901c82cf0cd10d4ee17402cb7f9234ce - hide __libc_{f,}statfs.
Thanks to Peter S. Mazinger for mentioning this fact.
0b5983eaf4562a3e4b4a4136004a8349828eb6d9 - cosmetic tidy up of clean target
ba1303003dae2f44e5b342304925ec52b173e01e - cosmetic tidy up of clean target
4a7ac42c310546504f0453459348d0ed75e35873 - make sure isspace() is
exported. Thanks to Skinkie for noticing.
e737aa03ea2db5e29fab981737a93e2ba65b5766 - Fix thumb2 PIE (Joseph S.
Myers) This patch fixes position-independent exec
utables (PIEs) for Thumb-2. In Thumb assembly, instructions reading
pc give a value 4 greater than the address of t
he instruction, rather than 8 greater as in ARM mode, so the offset
to the GOT needs to have the right offset. (The T
humb-1 code already gets this right; it's the code shared by ARM and
Thumb-2 that needs fixing.)
97807b8291e7e5f35a12ab0307d8e56377eb24f4 - fix args (untested)
cf29148c9a9387a4a173dd56c7ae0fdd4418fad7 signal ops: avoid calls
through PLT for __sigXXX ops linuxthreads.old/manager:
pointless style fixes, no code changes
1e950c61e51838680f35317669376e40d69bc6c6 libc-symbols: improve
comments and make macros a bit more readable. no code cha
nges
c33ce133b9da9236fffd19d72d6b4d2ca63bfa2a fix some unneeded PLT references
04b163798f550730faed41fa2cbe949cb00c07a2 fix make utils build
failure in ldconfig (undefined reference to 'getopt')
63b94a1fdf758f61a98cbadbc3621ec1fdc9b0ab fix make install with relative PREFIX
bbf84bb108beca2e014e93e76371b8fdb3336bf3 fix ioperm build problems
caused by libc_hidden_proto removal
ae49d141f41d0f641de63105e11a475e990cd4d0 fix apparent typo (unnoticed
for long time, probably because it didn't affect
little endian arches)
3e8067a62725780222fa90f2945f1d5599a5cdd6 deal with TODOs left over
from libc_hidden_proto removal (fixes build with loc
ale enabled)
--
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
On Wed, Apr 07, 2010 at 11:04:54AM +0200, Natanael Copa wrote: On Sun, Apr 4, 2010 at 4:42 PM, Austin Foxley aust...@cetoncorp.com wrote: On 04/03/2010 11:13 AM, Natanael Copa wrote: which means that stdout ends up with the error indicator set for some reason. I suspect this is a bug in uclibc-nptl. Interestingly enough, redirecting stdout to a file made the build complete. Any ideas on how to trace this down? Does this happen with the 0.9.31-rc? There aren't too many major differences in the stdio code between master and nptl. Ok, I tried with 0.9.31 and LINUXTHREADS_NEW and yes, same thing happens there. you should use LT_OLD on i386 but anyway. Does it still happen if you build master with LT_OLD and O0 (i.e. DODEBUG set)? Which version of the compiler are you using? ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problems with gnu make and stdout with uclibc nptl
On 04/03/2010 11:13 AM, Natanael Copa wrote: which means that stdout ends up with the error indicator set for some reason. I suspect this is a bug in uclibc-nptl. Interestingly enough, redirecting stdout to a file made the build complete. Any ideas on how to trace this down? Does this happen with the 0.9.31-rc? There aren't too many major differences in the stdio code between master and nptl. -Austin ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
