Re: problems with gnu make and stdout with uclibc nptl
2010/4/12 Timo Teräs : > 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
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
> -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 > wrote: > > On Wed, Apr 7, 2010 at 11:20 PM, Bernhard Reutner-Fischer > > 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
On Thu, Apr 8, 2010 at 8:40 AM, Natanael Copa wrote: > On Wed, Apr 7, 2010 at 11:20 PM, Bernhard Reutner-Fischer > 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 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 Wed, Apr 7, 2010 at 11:20 PM, Bernhard Reutner-Fischer 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 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 07, 2010 at 11:04:54AM +0200, Natanael Copa wrote: >On Sun, Apr 4, 2010 at 4:42 PM, Austin Foxley 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 Wed, Apr 7, 2010 at 3:30 PM, Natanael Copa 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
> 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 11:34 AM, Natanael Copa wrote: > On Wed, Apr 7, 2010 at 11:04 AM, Natanael Copa > wrote: >> On Sun, Apr 4, 2010 at 4:42 PM, Austin Foxley 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
On Wed, Apr 7, 2010 at 11:04 AM, Natanael Copa wrote: > On Sun, Apr 4, 2010 at 4:42 PM, Austin Foxley 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 Sun, Apr 4, 2010 at 4:42 PM, Austin Foxley 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
_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 wrote: > On Sun, Apr 4, 2010 at 4:42 PM, Austin Foxley 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 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
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
problems with gnu make and stdout with uclibc nptl
Hi, I'm trying to rebuild all alpinelinux packages against uclibc-nptl. This is native x86 compile. When i built gcc the build script[1] failed after a while (20mins something) with: make: write error when i entered the build dir and ran 'make' manually, it continued and completed the build. When I tried catch the error message by modifying the buildscript to: make 2>errors.txt it completed. I decided to move on with the other packages, with my newly built nptl toolchain. Now when i build ghostscript package[2] i get this: In file included from ./base/gp_unix.c:17: ./base/pipe_.h:39: warning: function declaration isn't a prototype ./obj/gconfig.c:188: warning: no previous prototype for 'gs_lib_register_device ' /usr/lib/gcc/i486-alpine-linux-uclibc/4.4.3/../../../libjasper.so: warning: the use of `tmpnam' is dangerous, better use `mkstemp' make: write error This made me curious and I grepped for "write error" in the gnu make sources[3] and found this: void close_stdout (void) { int prev_fail = ferror (stdout); int fclose_fail = fclose (stdout); if (prev_fail || fclose_fail) { if (fclose_fail) error (NILF, _("write error: %s"), strerror (errno)); else error (NILF, _("write error")); exit (EXIT_FAILURE); } } 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? Thanks! [1] http://git.alpinelinux.org/cgit/aports/tree/main/gcc/APKBUILD [2] http://git.alpinelinux.org/cgit/aports/tree/main/ghostscript/APKBUILD [3] http://cvs.savannah.gnu.org/viewvc/make/misc.c?revision=1.80&root=make&view=markup -- Natanael Copa ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc