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
[PATCH] i386/bits/syscalls.h: let *_NCS allow non-constant syscalls
Fixes NPTL build on x86. --- libc/sysdeps/linux/i386/bits/syscalls.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/libc/sysdeps/linux/i386/bits/syscalls.h b/libc/sysdeps/linux/i386/bits/syscalls.h index 0427d91..9184bd6 100644 --- a/libc/sysdeps/linux/i386/bits/syscalls.h +++ b/libc/sysdeps/linux/i386/bits/syscalls.h @@ -23,7 +23,7 @@ "int$0x80\n\t" \ RESTOREARGS_##nr\ : "=a" (resultvar) \ - : "i" (name) ASMFMT_##nr(args) : "memory", "cc" \ + : "g" (name) ASMFMT_##nr(args) : "memory", "cc" \ ); \ (int) resultvar; \ }) -- 1.7.0.4 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] i386/bits/syscalls.h: let *_NCS allow non-constant syscalls
On 04/09/2010 06:08 AM, Natanael Copa wrote: > Fixes NPTL build on x86. Thanks, I noticed this broke with the last merge, but I hadn't figured out what constraint it was whining about yet. -Austin ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
uClibc-0.9.31 symbol table oddities
So, I recently test compiled the new uClibc-0.9.31, and compared its symbol table to the old 0.9.30.3. There were lots of changes, most of which are fine. However, I noticed a couple oddities: __res_state (added) __resp (added) These seem to be added as part of a scheme to allow _res to be sanely emulated in presence of threading. But my build is not threaded -- so they are a waste. capset (removed) Removing this is the correct thing for me, since my kernel doesn't support capabilities. But why is capget still in? ll_tzname_UNKNOWN (added) ll_tzname_UTC (added) Looks like someone forgot to add some "static" keywords. These data items are mentioned in no header. Even their data type is only defined in the .c file that creates them [libc/misc/time/time.c]. posix_fadvise64 (added) This doesn't belong in my system since both LFS and Advanced Realtime are configured out. Furthermore, while looking at the file that creates this symbol [libc/sysdeps/linux/i386/posix_fadvise64.S], I noticed some careless #ifdef use which causes it to be assembled as a single "ret" instruction in the case that no fadvise syscalls are available and UCLIBC_HAS_STUBS is not set. The result is a function that returns garbage. - On a related note, is there ABI breakage in 0.9.31 aside from dropped symbols? I now use uClibc as my host, so rolling over to 0.9.31 would be easier if the new library can support tools compiled with the old. (But I have plans to cope if it's not, and have no regrets for choosing that problem over glibc's symbol versioning bloat.) Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: uClibc-0.9.31 symbol table oddities
Michael Deutschmann wrote: On a related note, is there ABI breakage in 0.9.31 aside from dropped symbols? Yes, ABI is broken regarding to signal handling. struct sigaction fields were reordered at 885f507317b6c8576ba2e298c2249d27ea6f8404. sigset_t size was also changed in 35ae1599438a15568818bf09b493d7b49039d452. - Timo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: uClibc-0.9.31 symbol table oddities
On 4/9/2010 4:49 PM, Michael Deutschmann wrote: > So, I recently test compiled the new uClibc-0.9.31, and compared its > symbol table to the old 0.9.30.3. There were lots of changes, most of > which are fine. However, I noticed a couple oddities: > > __res_state (added) > __resp (added) > These seem to be added as part of a scheme to allow _res to be > sanely emulated in presence of threading. But my build is not threaded > -- so they are a waste. > > capset (removed) > Removing this is the correct thing for me, since my kernel > doesn't support capabilities. But why is capget still in? > > ll_tzname_UNKNOWN (added) > ll_tzname_UTC (added) > Looks like someone forgot to add some "static" keywords. These > data items are mentioned in no header. Even their data type is only > defined in the .c file that creates them [libc/misc/time/time.c]. > > posix_fadvise64 (added) > This doesn't belong in my system since both LFS and Advanced > Realtime are configured out. > Furthermore, while looking at the file that creates this symbol > [libc/sysdeps/linux/i386/posix_fadvise64.S], I noticed some careless > #ifdef use which causes it to be assembled as a single "ret" instruction > in the case that no fadvise syscalls are available and UCLIBC_HAS_STUBS > is not set. The result is a function that returns garbage. > > - > Hi Michael, you analysis is really interesting, hopefully some patches will come soon. I'll try to do my part. > On a related note, is there ABI breakage in 0.9.31 aside from dropped > symbols? > no that I know. cheers, carmelo > I now use uClibc as my host, so rolling over to 0.9.31 would be easier if > the new library can support tools compiled with the old. (But I have plans > to cope if it's not, and have no regrets for choosing that problem over > glibc's symbol versioning bloat.) > > Michael Deutschmann > ___ > 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: Possible regression from timeout commit for resolv.conf
On Tuesday 06 April 2010 15:31, Kevin Day wrote: > On 4/6/10, Denys Vlasenko wrote: > > On Friday 02 April 2010 00:21, Kevin Day wrote: > > > I am using the NPTL branch on x86, which works perfectly fine (in > > > fact, better than any other stable release since 0.9.28) > > > The commit number is: cca45baf8353d1e338d232f5bdb2d1d6b357f1da > > > > > (http://git.uclibc.org/uClibc/commit/?h=nptl&id=cca45baf8353d1e338d232f5bdb2d1d6b357f1da) > > > > > > With the addition of the commit, the program claws-mail fails to > > > respond to SMTP servers and throws an annoyingly useless error. > > > At first glance I assumed that this to be a claws-mail problem. > > > > > > You did not provide any symptoms. *How* does it fail? > > Claws Mail returns the following message: > ** IMAP error on (null): connection refused > > This happens during any attempt to connect via domain name. Looks like DNS lookup failure. Can you try replacing uint8_t __resolv_timeout; uint8_t __resolv_attempts; by uint8_t __resolv_timeout = RES_TIMEOUT; uint8_t __resolv_attempts = RES_DFLRETRY; in uClibc/libc/inet/resolv.c ? > I can manually run nslookup for the mail server, copy that address and > manually use the ip address to connect to the mail server with > claws-mail. > > Just to be sure, I also tried both cases with the firewall off with > same results. > > In the claws-mail-3.7.5 source code, line 1102 of src/imap.c, they have: > imap_handle_error(NULL, r); > > I seem to have written "SMPT" by accident in the message, what I meant was > IMAP. > The problem is both with sending and receiving. -- vda ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: uClibc-0.9.31 symbol table oddities
On Fri, 9 Apr 2010, Carmelo AMOROSO wrote:
> Hi Michael,
> you analysis is really interesting, hopefully some patches will come soon.
> I'll try to do my part.
I can help out a bit myself. Appended is a patch to make capget
consistent with capset, and stop the namespace pollution from the time
module.
It's not run tested (it will be awhile before I get around to crossing
over, and even then that will be with several other local patches), but I
have verified it compiles and produces saner looking nm output.
That leaves the __res* issue, and the posix_fadvise64 issue.
Michael Deutschmann
diff -durpN uClibc-0.9.31/libc/misc/time/time.c
uClibc-0.9.31-symclean/libc/misc/time/time.c
--- uClibc-0.9.31/libc/misc/time/time.c 2010-04-02 08:34:27.0 -0700
+++ uClibc-0.9.31-symclean/libc/misc/time/time.c2010-04-09
14:44:26.0 -0700
@@ -604,11 +604,11 @@ typedef struct ll_tzname_item {
} ll_tzname_item_t;
/* Structures form a list "UTC" -> "???" -> "tzname1" -> "tzname2"... */
-struct {
+static struct {
struct ll_tzname_item *next;
char tzname[4];
} ll_tzname_UNKNOWN = { NULL, "???" };
-const struct {
+static const struct {
struct ll_tzname_item *next;
char tzname[4];
} ll_tzname_UTC = { (void*)&ll_tzname_UNKNOWN, "UTC" };
diff -durpN uClibc-0.9.31/libc/sysdeps/linux/common/capget.c
uClibc-0.9.31-symclean/libc/sysdeps/linux/common/capget.c
--- uClibc-0.9.31/libc/sysdeps/linux/common/capget.c2010-04-02
08:34:27.0 -0700
+++ uClibc-0.9.31-symclean/libc/sysdeps/linux/common/capget.c 2010-04-09
14:43:37.0 -0700
@@ -11,7 +11,7 @@
int capget(void *header, void *data);
#ifdef __NR_capget
_syscall2(int, capget, void *, header, void *, data)
-#else
+#elif defined __UCLIBC_HAS_STUBS__
int capget(void *header, void *data)
{
__set_errno(ENOSYS);
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
