Binutils and bloat
This may be stretching into off-topic, but I think it fits here since most people here care about bloat and are using a mostly-GNU toolchain. Binutils-2.28 came out two months ago, but I've put off moving to it because I noticed that executables are bloated compared to 2.27. Usually it's minor, but in one case (the "as" program in binutils itself), the executable more than doubles in size. I've reported the bug, and the underlying cause is understood now, but I can't get them to fix it. (It's closed binutils bug #21448). Basically, between 2.27 and 2.28 someone noticed that if you violate the const-ness of a symbol imported from an ELF shared library, no segfault occurs. This is because (at least in recent binutils) such symbols are "copy reloc"ed to a spot in the executable's BSS region, avoiding the need for as many relocations at run time. Since the entire BSS remains writable, this means that const doesn't do much of anything from within a shared library. They decided this was a "security flaw", and rewrote 2.28 to place such copy symbols in a separate section covered by relro. This section, like BSS, is all zeros. But unlike BSS, all those zeros take up actual space in the file. Due to the way paging works, the bloat is difficult to fix without giving up this alleged "security" or bloating RAM use. On my system GNU "as" is ~240k of real code that references a ~430k constant table from the "libopcodes" library, so bloat is severe. I personally don't see how the lack of segfaults constitues any security problem worth this level of bloat. You could as much call it a flaw that .rodata isn't usually made no-execute at a hardware level. Hopefully, people here can either come up with some subtle reason the binutils people are in fact right, or knock some sense into them for me (Note that I've already patched away the odious behavior for myself.) Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Possible bug in random name generation for mkostemp and friends
On Sat, 2 Feb 2013, "Anthony G. Basile" wrote: > Even though 'value' is declared static it is never initialized. Isn't > this a problem? In C, statics are implicitly initialized to all-bits-zero. While I only know this offhand to be standards-required for static data declared at toplevel, there's no way under the Unix assembler/linker paradigm to specify that a non-stack variable is truly uninitialized. Adding a '= 0;' might be a style recommendation. However, in past people often avoided that due to lazy compilers that would then put the object in the data section, wasting space in the final executable file. I also understand at one point GCC was deliberately so stupid in order to accomodate a common hack to do what, today, we do with the "_edata" linker-generated symbol. Current GCC seems to be smart, though. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
The "__libc_select" symbol
Recently, I've been pouring through uClibc's symbol table looking for cruft to remove. I suppose you could call it a New Year resolution I've found a few things that are totally useless, and a number of things that are basically a private interface for libpthread to use (which still shouldn't be bloating *my* table as I've configured out threads). While enumerating the latter type of symbol, I've come across something that might be a bug in threading. Most of them are aliases of other libc functions prefixed by "__libc_", placed there so that linuxthreads.old can wrap them. (NPTL seems to rely instead on code embedded into the main uClibc dso, and I'm not sure just how "new" linuxthreads is coping...) "__libc_select" appears at first glance to be such a symbol. However, I can't find any reference to it in any of the threading libraries. Has perhaps linuxthreads.old been broken all along, in that "cancellation" does not take place on a call to select()? Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Un-hidden function relocs
Mike Frysinger wrote, regarding the minimal linux syscall patches: > to check for this, you can run `readelf -r` on the libc.so file and > look at all the function relocs. the only ones in that list you should > see are malloc related (malloc/free/calloc/etc...). if you see other > symbols, they're most likely missing the libc_hidden stuff. I have nothing to do with those patches. (I don't trust the stability of dentry-based Linux kernels, so I run 2.0.40 and all this minimal syscall stuff is kind of irrelevant for me) However, out of curiousity I ran readelf -r on my own uClibc executable, and I found more than just malloc-related functions. Besides 114 ".rel.dyn" entries and the malloc-related ".rel.plt"s, there were the following: __errno_location __h_errno_location __unix_grantpt _dl_app_init_array _dl_app_fini_array My version of uClibc is heavily patched from 0.9.33.2, but these functions don't relate to my changes. Although "__unix_grantpt" is probably wrong because I'm the only one exercising the "old PTYs available and new PTYs never available" code path. The other four could be normal. The "*_location" ones are probably for libpthread to override (but I've configured threads out). The "_dl_app_*" ones have no local definition and are definitely there for override by ldso. On a related note: It appears the reason malloc and friends are exceptions to the general rule is to support applications that want to wholly replace the malloc engine with a custom one. But that feature is not often used. It would be nice if there was a configuration option to not treat malloc specially, and also to make brk() and sbrk() invisible. I don't think those two functions were ever part of the original POSIX 1992, and they are obsolete in the more recent standards. It could save a few bytes. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: incorrect print -1 using %hhd
On Tue, 27 Mar 2012, Mike Frysinger wrote: > On Tuesday 27 March 2012 10:28:29 Andrew Rybchenko wrote: > > Is it known issue that uClibc 0.9.32 incorrectly prints -1 using > > %hhd (and %hhi) specifier? The following program: > please file a bug No need, this is bug #1783. It was closed as fixed-in-the-next-release when I reported it against 0.9.31, but somehow the fix hasn't percolated into any release version of uClibc yet. The fix is really simple. Just change the cast from "(char)" to "(signed char)" in libc/stdio/_load_inttype.c . The bug was introduced not by any change in the sourcecode itself, but because the Makefiles started specifying -funsigned-char everywhere. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Horrible GCC 4.7.0 optimizer bug
Thought I should give you guys a warning. GCC 4.7.0 miscompiles uClibc 0.9.33 really badly; almost every significant program segfaults quickly. I've traced down the problem and it is definitely a GCC bug; the uClibc source isn't doing anything wrong. The problem rests in sbrk(). GCC misoptimizes: >oldbrk = __curbrk; >if (brk (oldbrk + increment) < 0) > return (void *) -1; >return oldbrk; into: >if (brk (__curbrk + increment) < 0) > return (void *) -1; >return __curbrk; Since brk() alters __curbrk, the result is a dysfunctional malloc subsystem. Adding a volatile tag to __curbrk (remember to make it "void * volatile", not "volatile void *") supresses the problem. Although it does make me nervous to have an optimizer problem this bad in my compiler... I've checked, and none of the magical things uClibc does with __attribute__ are necessary for the bug to appear. I've reported a simplified case to GCC's bug tracker as #52734. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] prevent retries on fclose/fflush after write errors
On Wed, 14 Mar 2012, Rich Felker wrote: > It was cited in "Worse is Better", yes, but I don't entirely believe > the anecdote. SA_RESTART semantics are no harder to implement; it's > just a matter of whether you save the address of the syscall > instruction or the instruction immediately after it when invoking a > signal handler. Usually the address instruction immediately after will already be on the stack, or some sort of task structure, as part of the normal syscall process that would be followed in the absence of signals. Now, adjusting the saved instruction pointer would not be hard in machine code. Generally, the saved user IP is sitting somewhere in the kernel stack a predictable distance above the return address for the kernel function implementing the call, like a hidden extra argument. But access to such context isn't something C compilers are good at, and the stack offset and syscall opcode length must be customized for each processor family. The ancient worse-is-better Unix programmers probably decided to just foreclose on syscalls doing anything to the userspace registers (aside from the one used to return results). This made the assembly glue joining a CPU-agnostic C kernel to a specific machine as simple as possible, and made EINTR the only acceptable way. > It can be solved (albeit in an ugly way) by having the signal handler > re-arm the alarm with exponential falloff in delay (in case the system > is so loaded that it can't return from the signal handler before > another timer expiration happens). Yuck. That's a lousy quality of implemantion, and isn't even adequate for probing whether a system implements EINTR. > Even if your approach is preferable to users, I don't think it's > conformant, since POSIX specifies the EINTR error for fgetc. Since all That may be just tolerance for a lazy stdio that doesn't work any harder than it needs to. Certainly no one disputes a stdio is *allowed* to treat EINTR same as EIO. The question is whether it *must*. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] prevent retries on fclose/fflush after write errors
On Wed, 14 Mar 2012, Mike Frysinger wrote: > we already provide the helper TEMP_FAILURE_RETRY() for people who want > this, so that should be sufficient for those who want to opt in to that > behavior. TEMP_FAILURE_RETRY can't wrap stdio functions. stdio features a sticky error flag, expressly so that one can attempt a series of reads or writes and only check for errors once at the end. So once a read/write is blocked by EINTR, it will stay blocked until you explicitly do a clearerr(). Adding clearerr() to an otherwise TEMP_FAILURE_RETRY-like loop will not work sanely. See the discussion in glibc's manual (a node I mostly wrote) for details: http://www.gnu.org/software/libc/manual/html_node/Error-Recovery.html Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] prevent retries on fclose/fflush after write errors
On Tue, 13 Mar 2012, Rich Felker wrote:
> I would consider this a flaw in the standard since it largely prevents
> using EINTR in any useful way.
EINTR wasn't invented to be useful, it was invented because it was easier
to implement in pre-sigaction() SysV kernels than SA_RESTART semantics.
Known as the "PCLSR problem", it is an often cited example of the "Worse
is Better" design philosophy at work.
> I was assuming the old standard idiom of installing a do-nothing signal
> handler (without SA_RESTART) for SIGALRM so that fgets would return with
> an error and the program could proceed.
That's a broken idiom, since if the signal should arrive just one opcode
before the read syscall begins, it will be ignored. If you need reliable
signal interruption, you must use sigsuspend() or longjmp out of the
handler.
It's also the only possible use of a cleared SA_RESTART, so it's crazy not
to set the flag all the time. That we have a SA_RESTART flag at all, is
just a measure so that old SysV programs abusing the design flaw break
occasionally instead of often.
One historical note:
Circa 2000, I was actively reading glibc's bugs list and trying to help
out. Someone posted a bug report ("libc/1174" in the old GNATS system)
citing this very issue, and I suggested a patch to restart after EINTR
within stdio -- since any deliberate use of interruption would involve a
race condition.
Ulrich Drepper denied it, on the grounds that:
) But this is not correct. You must be able to set an alarm() and
) terminate a blocked fwrite() code. This is required and tested by all
) kinds of standard test suites.
Although that exchange eventually had one productive result -- the node
"Error Recovery" in the glibc manual, which I basically wrote.
Sounds like in the intervening decade, glibc may have come around to my
thinking
Michael Deutschmann
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] Fix mq_{send, receive, timedreceive} for , non-ADVANCED_REALTIME
On Tue, 11 Jan 2011, Bernhard Reutner-Fischer wrote: > On Tue, Dec 28, 2010 at 10:00:21AM -0600, Steven J. Magnani wrote: > >Disable compilation of librt files that depend on ADVANCED_REALTIME. > >On microblaze, which does not have ADVANCED_REALTIME, 0.9.32-rc1 builds fail > >with > That falls under SUSv4 audit. Postponed since mq requires > ADVANCED_REALTIME, really. I'd disagee there. That REALTIME && !ADVANCED_REALTIME fails to compile in stock 0.9.32-rc1 is a showstopper. I would also consider this setting rather common. Nothing on my system uses librt, so there is no point (other than supressing this bug) in turning on ADVANCED_REALTIME. Yet I'm compelled to turn on REALTIME because this setting also controls a few vital functions (nanosleep and sched_*) in the libc itself. That said, it looks like the original patch is not a valid answer, since the files that break due to this bug are still vital to provide the API promised by REALTIME. A better short-term hack would be to do: #include #undef __UCLIBC_HAS_ADVANCED_REALTIME #define __UCLIBC_HAS_ADVANCED_REALTIME 1 at the start of the relevant files, as all that is needed is valid prototypes for certain "advanced" functions. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: release? (Was: Re: bison and m4 with uclibs linuxthreads (new): error: field '_sp' has incomplete type)
On Mon, 29 Nov 2010, Natanael Copa wrote: > Switching to NPTL will break ABI. Not an issue for me, as I don't use threads. We can still configure them out, right? Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: release? (Was: Re: bison and m4 with uclibs linuxthreads (new): error: field '_sp' has incomplete type)
Is this going to be an ABI-breaking release? (I'm prepared either way. My 0.9.30.3 to 0.9.31 rollover went just fine.) Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] Assertion `iter->cur.wc == 0' failed.
On Sun, 21 Nov 2010, Rob Landley wrote:
> Still trying to build Linux From Scratch 6.7 packages against the last uClibc
> stable release, and I hit this strange assertion breaking "shadow" build:
>
> # find man -name Makefile.in -exec sed -i 's/groups\.1 / /' {} \;
> find: mbuiter.h: 171: mbuiter_multi_next: Assertion `iter->cur.wc == 0'
> failed.
>
> [...]
> Does anyone have an opinion on this?
Sounds like my bug #1471, which I reported over 7 months ago. It is a
disobedience to the standards that prevents tar from completing its
self-check. A simple testcase is included with the report.
Basically, mbrtowc() is required to set the wchar_t pointed to by its first
argument in every non-error case. uClibc forgets to do this when the input
multibyte string is "". And gnulib has oddly aggressive consistency checks.
Michael Deutschmann
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 1/2] bits/socket.h: add SOCK_CLOEXEC and SOCK_NONBLOCK support
On Tue, 1 Jun 2010, Vladimir Zapolskiy wrote: > + SOCK_CLOEXEC = 0200, /* Atomically set close-on-exec flag for the > + SOCK_NONBLOCK = 04000 /* Atomically mark descriptor(s) as That is not correct in general. The values vary between architectures. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Apparently, glibc's static linking support is deprecated?
On Wed, 12 May 2010, Rob Landley wrote: > Ulrich Drepper, the glibc maintainer, has gone crazy and believes that You mean he wasn't already? ;) > static linking should never be used for anything: > > http://people.redhat.com/drepper/no_static_linking.html That's ironic, considering that one of *my* annoyances last I dealt with glibc, was that it would not honour --disable-static. Since I had no use for debug or profile, this doubled my compilation time. In fairness to him, though, he lives in a different world. Glibc has maximal backwards compatiblity, so a shared build against an early glibc version is nearly as good as static (within the glibc fold...). > (Somebody should tell him about execute in place support, about dynamic > linking dirtying per-process physical pages, These are characteristics of ELF, not shared libraries in general. It's quite possible to have a form of shared libraries that still uses absolute linking. You just have to agree in advance on what address space belongs to the librar(ies) and to the executable. A jumptable is still needed if you want freedom to recompile the shared library without recompiling dependent executables. But if you're building an immutable system, you could even dispense with that. (This would be like oldschool overlays, with the "library" being an executable that passes control to "executables" that are really overlays against itself.) Alternative approaches are not nearly as convienient to program for as standard ELF. Linux originally used a system like this (libc.so.4 / a.out), but this was abandoned for good reason. Nonetheless, its important to remember that "bloated static" and "full blown dynamic linking" are not the only possibilities. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] nptl: proper soname handling
On Sun, 2 May 2010, Timo wrote: > And yes, it's not full solution. Deep library wise dependencies can be > temporarily broken. The problem is that just one level of shared library other than the C library, is sufficient to break side-by-side execution based *only* on C library soname changes. That means using, for example, bash linked against libncurses, is enough to cause trouble. > And yes, we do need stable API for uclibc at some point. No we don't. When it comes to C library design, pick any two: 1. Long term ABI compatibility 2. Conformance to standards, which change from time to time 3. Avoidance of bloat libc.so.4 and libc.so.5 chose #1 and #3. Glibc chose #1 and #2, via linker magic that wasn't available for the previous libcs. uClibc is for those who want #2 and #3. (Or want to exclude features from the "standard" build, forcing #1 to be abandoned.) Don't get me wrong; official side-by-side support would indeed be useful. But just changing the soname *will not give you that*. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] nptl: proper soname handling
On Mon, 26 Apr 2010, Rob Landley wrote: > > Build a customized ld-uclibc.so.0, from the previous uClibc source, that > > looks in a different place for shared libraries and ignores the > > /etc/ld.so.* files. Install it under a different filename. > > Or just build it that way in the first place... That means yielding the plain /lib and /usr/lib locations forever to the first uClibc that claims them. In turn, you'll get a lot of pain dealing with packages that build new libraries and don't understand that, since they are building against /lib/NEW/libc.so.0, they need to install their libfoo.so.1 as /usr/lib/NEW/libfoo.so.1. Instead, they'll overwrite /usr/lib/libfoo.so.1, making the new library invisible to freshly compiled applications, while breaking old executables. It's better to hack old excutables into looking in /lib/OLD and /usr/lib/OLD so that the new ABI can seize the traditional locations. Once you begin changeover, you will no longer be compiling old-API libraries, so the nonstandard paths do not cause trouble. > > Write a utility to modify the INTERP filename specified in an executable > > Try "probably only feasible if". The longer-length case is doable. Append the longer interpreter filename to the end of the executable, then change the segment header to point at it. The old ld.so name becomes dead space in the file. This can be automated. However, *I'm* going to lazily just use a temporary interpreter filename that fits in the original spot. It would break most self-extracting archives. However, the concept of a uClibc SFX file is rather silly when you think about it, anyway. > Don't forget that pretty much every other shared library (zlib, ncurses, > openssl, etc) also links against libc, so you have to move those to the > alternate position and rebuild them too. You need to move them all, but not recompile them. I'm well aware of this factor, and it is itself the reason I don't think changing the uClibc soname alone will do much good. You also need to extend ldso & ldconfig to give the same respect to the previous soname, that they presently grant to libc.so.5 and libc.so.6. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] nptl: proper soname handling
On Thu, 22 Apr 2010, Timo wrote: > This really is configuration management issue, and doable inside a single > distribution. I don't understand what "configuration management" means. Perhaps this is why I don't quite get you and Natanael... Basically, my point is that in general, changing the soname is only of value to enable side-by-side. But in the case of the C library itself, changing the soname is far from sufficent, because there is no easy way to modify the sonames of every dependent shared library (ncurses, readline, bfd) so as to avoid collision. The distinction between libc.so.6 (Glibc) and libc.so.0 just barely works, and only because of special magic in ldconfig. If you want to support a libc.so.0 to "libc.so.0.1" rollover in the same way, you'll need to also add LIB_ELF_LIBC0_1 to ldso/include/dl-defs.h, and then ring the changes through ld.so and ldconfig. (Seeing as uClibc fans usually compile everything locally, and only need side-by-side at the moment of rollover, I'd add a single "LIB_ELF_OLD_UC" flags, and provide a utility to mark every binary on a system as "OLD" to ld.so and ldconfig. Rather than an endless LIB_ELF_LIBC0_1, LIB_ELF_LIBC0_2, ... until the type field overflows This would suffice so long as every old-ABI program gets recompiled before the next ABI break) It occurs to me that what you might want is not side-by-side, but self-identification of executables. So that if you run into some old forgotten binaries, you can guess what version of uClibc they were meant for. But that can be dealt with in other ways, such as the "ABI tag" note that glibc uses. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] nptl: proper soname handling
On Thu, 22 Apr 2010, Natanael Copa wrote: > Do you have any better suggestions how to upgrade a running system? First, build the new uClibc, but don't install it yet. Build a customized ld-uclibc.so.0, from the previous uClibc source, that looks in a different place for shared libraries and ignores the /etc/ld.so.* files. Install it under a different filename. Write a utility to modify the INTERP filename specified in an executable from "/lib/ld-uclibc.so.0" to the filename of the special ld.so. (This is much simpler if the temporary ld.so filename is the same length as the original.) Hardlink the existing shared libraries into the alternate position, then hack every existing installed executable in this way. Then, delete all the old libraries in /usr/lib and the include files. The shared libraries will be preserved by the hardlink, while everything else is dispensible. The system should still work for everything except compilation. Now, install the new uClibc. Unless the ABI is so thoroughly broken as to invalidate the old specs or libgcc.a, you should now be able to compile new binaries. I intend to do something like this for my 0.9.30.3 to 0.9.31 rollover, but I haven't finished writing the necessary utilities yet. ---- Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] nptl: proper soname handling
On Tue, 20 Apr 2010, Natanael Copa wrote: > Since sublevel releases are not ABI compatible we need to adjust > the soname to include the sublevel version. I see two reasons that this would be pointless. First, you'd need more than a more precise statement of the uClibc source version, because with uClibc, a single version of the source can produce many different ABI-incompatible libc.so.0 files. Second, sonames don't really help with the C library, because every other shared library on a system is linked to the C library. The differences in the C library often distort the ABI of these other libraries. It's very complicated to keep appropriate versions side-by-side because the soname of the other shared libraries does not change. In the case where the C library change doesn't outright break the other shared libraries, changing the soname makes it worse because an application can end up loading two different C libraries at once -- one through it's own DT_NEEDED, and one through the DT_NEEDED on another shared library. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: 0.9.32 plans/TODOs
On Fri, 2 Apr 2010, Bernhard Reutner-Fischer wrote: > - -std=gnu89 (before merge/after/not ?) I fear that certain folks > will wince if we (we're well in 2010 at the time of this writing and > C99 is the dominating standard for the majority that i'm aware of) > drop it, yes? I've been there. For awhile I was trapped at GCC 2.95.3 because further versions required an upgrade to a GLIBC version that was too bloated. It was really annoying, all the programs I had to patch because of programmers who use C++-style declarations-after-statements. Notably, GNU coreutils has been such a package for a long time now. But now, I've found uClibc and all is sweetness and light, with GCC 4.4.3. Thus, I think dropping support for C89 shouldn't be a problem, unless we are talking about some specific feature GCC added after declarations-after-statements-in-straight-C. Anyone who doesn't have this feature *knows* they have a problem. On a related note, dropping C89 support implies dropping support for all GCC 2.x versions, since their C99 support is deficient. So if you're going to break GCC 2 anyway, this offers a chance to simplify the headers by removing special cases for old GCC. Michael Deutschmann ___ 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
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: bison and m4 with uclibs linuxthreads (new): error: field '_sp' has incomplete type
On Tue, 30 Mar 2010, Natanael Copa wrote: > and with m4-1.4.14 i get this: > > In file included from pipe.c:48: > ./spawn.h:112: error: field '_sp' has incomplete type > make[3]: *** [pipe.o] Error 1 This sounds like a problem I've had on my own system, which is threadless. So linuxthreads has nothing to do with it. My local patch to m4, supressing the bug, is appended. The comment next to the conditional I've spiked makes it clear what is going on. Apparently, glibc's headers expose the full definition of "struct sched_param" in cases not required by the standard, and gnulib attempts to optimize based on this. uClibc does not share glibc's behavior in this one case, but since it defines __GLIBC__, gnulib sees no need for caution. Michael Deutschmann diff -durpN m4-1.4.14/lib/spawn.in.h m4-1.4.14-ucfix/lib/spawn.in.h --- m4-1.4.14/lib/spawn.in.h2010-01-28 05:04:07.0 -0800 +++ m4-1.4.14-ucfix/lib/spawn.in.h 2010-02-27 23:10:41.0 -0800 @@ -31,7 +31,7 @@ /* Get definitions of 'struct sched_param' and 'sigset_t'. But avoid namespace pollution on glibc systems. */ -#ifndef __GLIBC__ +#if 1 # include # include #endif ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: uClibc-0.9.30.3-rc1
On Wed, 24 Feb 2010, I wrote: > On Sat, 20 Feb 2010, Bernhard Reutner-Fischer wrote: > > Hi all, > > > > I'd like to do a maintenance 0.9.30.3 release soon (in a week or so). > > > > If you have patches/fixes that should be backported from master then > > please say so now (or push non-controversial fixes right to the branch). > > uClibc-0.9,30.2 had three unfixed bugs, solutions to which had been > posted here or in the bug tracker before its release: > > #173 - DNS functions wrongly return TRY_AGAIN for all negative responses > #255 - printf behaves incorrectly for large field widths > #297 - the function dn_skipname() is missing 0.9.30.3 is out now, but none of the above were patched. Oddly though, one of my Linux 2.0 compatibility fixes (poll), did make it in... Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: uClibc-0.9.30.3-rc1
On Sat, 20 Feb 2010, Bernhard Reutner-Fischer wrote: > Hi all, > > I'd like to do a maintenance 0.9.30.3 release soon (in a week or so). > > If you have patches/fixes that should be backported from master then > please say so now (or push non-controversial fixes right to the branch). uClibc-0.9,30.2 had three unfixed bugs, solutions to which had been posted here or in the bug tracker before its release: #173 - DNS functions wrongly return TRY_AGAIN for all negative responses #255 - printf behaves incorrectly for large field widths #297 - the function dn_skipname() is missing ---- Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
res_query() brain damage
Recently, I've transitioned my routing computer over to uClibc. It
mostly works well, but I noticed some minor glitches with Exim (the mail
server).
After some investigation, I traced the problem to uClibc's
implementation of res_query, which contains the following:
--
i = __dns_lookup(dname, type, __nameserversXX, [...]
if (i < 0) {
h_errno = TRY_AGAIN;
return -1;
}
--
This means that all negative DNS results get reported as temporary
failures -- which confuses the mailserver. It cares much about the
difference between an ambiguous result due to failure and an definitive
denial that a record exists.
The result is a lot of log messages complaining about tempfailing dnsbl
blacklists (but fortunately no actual loss of their spam protection),
and endless deferral of email coming from domains with no MX record.
Diking the "h_errno = TRY_AGAIN;" line appears to resolve the problem.
(h_errno is set properly from within __dns_lookup.)
Were this a complicated emergent behavior of the library, I'd just
report it via the bug tracker. However, this looks like it was
deliberate -- so I'm bringing it to the list for comment.
Michael Deutschmann
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: Discrepancy? uClibc seems very large
On Sat, 26 Sep 2009, Ersin Akinci wrote: > Ah, you're correct. I was running a simple du ./ on the install dir, > but I didn't realize that that included the header files and static > libs. My total /lib comes out to ~320 KB and my libuClibc-*.so is > ~160 KB. > > Are the header files needed for anything? Can I delete them safely? They are required to compile anything against uClibc, but not otherwise. If you are cross-compiling every executable from a seperate system, on the target system you may nuke /usr/lib/*.a, /usr/lib/*.o, and /usr/include. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Discrepancy? uClibc seems very large
On Fri, 25 Sep 2009, Ersin Akinci wrote: > Yet whenever I compile uClibc seperately (also using the buildroot > toolchain w/ uClibc) it always comes to somewhere between 3.5-4.5 MB with > a rather slim config. Are you looking at the shared library file (/lib/libuClibc-*.so) or the static library (/usr/lib/libc.a)? On my system, the shared uClibc comes to about 260k, but the static library is over a megabyte. The static library is never needed at run time, and rarely needed at compile time, so you could delete it if you are pressed for space. Aside from that, the biggest bloat factor for uClibc is locales. While glibc's approach is to have a generic driver in the library that loads external data files, uClibc will compile a preset library of locales into the .so file itself. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] Add dn_skipname() from OpenBSD
On Sun, 13 Sep 2009, Natanael Copa wrote: > dn_skipname() is needed by a few applications like yate, wine, kde and > probably more. And libspf2. I reported this missing function as bug #297. The initial response was "this function is NIH, please submit patch to remove it from the headers". When I pointed out that applications *unconditionally* use the function, so that wouldn't help, I just got almost two months of silence. Until now. Thanks for finally fixing this. ---- Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Spurious dtor-attribute in ldso.c
I've noticed one bit of code in uClibc-0.9.30.1, which makes no sense. It's in "ldso/ldso/ldso.c". The function "_dl_fini" is marked __attribute__ ((destructor)). That marking cannot have any effect. GCC's constructor and destructor attributes depend upon the crt*.o modules to function. Since ld.so must run before libc is loaded, it has a highly custom entry arrangement that does not use those modules. While this function does indeed need to be run at shutdown (in order to handle shared libraries with destructors), that is handled explictly by the assembler code which hands off to the loaded program's main. All this seems to do is bloat ld-uclibc.so by 44 bytes. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Actual program requiring res_close()
The help text for the UCLIBC_HAS_BSD_RES_CLOSE option says "Answer Y if you desperately want BSD compatibility; Most people will say N". This would seem to imply that no real program needs that function. However, I've encountered such a program -- the libspf2 library (http://libspf2.org). It's a somewhat important component of a spam-filtering mailserver, and it needs res_close() to compile. (It also needs "dn_skipname", which no configuration setting can coax uClibc-0.9.30.1 into providing. But that's another story, and has been filed as bug #297.) Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: add __adjtimex to get ntpd to work properly
On Thu, 29 Jan 2009, David Mosberger-Tang wrote: > UCLIBC_NTP_LEGACY does the trick, too. Is there a way to > automatically force that when somebody selects the ntp package? If > now, perhaps the help message could be clarified? It does?? In my experience, while the ntp_???time functions enabled by that option can be used as a substitute for __adjtimex() by the core ntpd daemon, the tickadj utility can only use __adjtimex(). If __adjtimex is not available, it falls back to a different technique only applicable to non-Linux kernels, which doesn't even compile because it wants . Enabling UCLIBC_NTP_LEGACY is also a poor solution since it bloats the library (by a tiny bit) just for the sake of one package. I've solved the problem locally by creating a "libat.a" library, which defines __adjtimex() in terms of adjtimex(). I just need to supply it to configure with the LIBS= enviroment variable, and everything works. It would be nice if uClibc would supply __adjtimex() natively, and move the old adjtimex() alias into UCLIBC_NTP_LEGACY. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: GCC's exception unwind info and uClibc
On Wed, 31 Dec 2008, Daniel Jacobowitz wrote: > Are you sure that is the relevant check? ELF object files are used on > arm-uclinux and m68k-uclinux; they're just translated into bFLT for > executables. Ah, that explains a bit. However, immediately after that check is a test for "!defined(OBJECT_FORMAT_FLAT)" -- shouldn't that catch the case? (I was wondering why OBJECT_FORMAT_FLAT and OBJECT_FORMAT_ELF might be defined simultaneously...) Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: GCC's exception unwind info and uClibc
On Sat, 27 Dec 2008, I wrote: > So it looks like this case needs to be refined, not to reject uClibc, but > to make sure the platform is indeed ELF, which is no longer implied by > "__GLIBC__". I looked a little more closely and it seems things are a bit wierd. The code in question is already wrapped within an "#if defined(OBJECT_FORMAT_ELF)" block. Maybe multiple fixes for the same problem got committed at once? If so, then it makes sense to dike the __UCLIBC__ check since it is overbroad compared to the ELF format check. BTW, the page you linked asserts that uClibc doesn't have EH_FRAME support yet on the grounds that PT_GNU_EH_FRAME is not mentioned in the uClibc source, except in the header. That's not how it works -- ld.so does not need to parse the segment itself -- all it needs to do is tell libgcc_s.so where all the segments are. libgcc_s.so then sifts out the PT_GNU_EH_FRAME ones and parses them on its own. My own testing proves the basic machinery works, despite uClibc's PT_GNU_EH_FRAME agnosticism. But the reason I asked here is that there might be some subtle case that doesn't work. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: GCC's exception unwind info and uClibc
On Sat, 27 Dec 2008, Natanael Copa wrote: > You might want have a look at this thread which explains why the test > for __UCLIBC__ was added to the gcc code in first place. > http://archives.devshed.com/forums/development-94/don-t-define-use-pt > -gnu-eh-frame-when-using-1880468.html Thanks, that's exactly what I'm looking for. It looks like the problems occur on platforms where the binary format is not ELF. Which is no surprise since the better exception-handling system is absolutely dependent on a special type of ELF segment. So it looks like this case needs to be refined, not to reject uClibc, but to make sure the platform is indeed ELF, which is no longer implied by "__GLIBC__". Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
GCC's exception unwind info and uClibc
One annoyance of GCC 4.3.x on uClibc is that it links libgcc_s into every single executable and library it produces. This is because of the exception support -- code in crtbegin.o tries to register "unwind info" using a function deliberately absent from the static libgcc. Glibc users are apparently spared this -- on that platform libgcc_s can use the function "dl_iterate_phdr" from ld.so to retrieve the unwind info from the executable as it needs it, with no explicit registration required. Thus, libgcc_s only needs to be linked for code that actually throws or catches exceptions -- libraries that merely pass them through don't need it. I've noticed that the supposedly glibc-specific code, in fact is active on the uClibc platform. But GCC does the manual registration as well if being built for uClibc: (from gcc-4.3.2/gcc/crtstuff.c) > /* uClibc pretends to be glibc 2.2 and DT_CONFIG is defined in its link.h. >But it doesn't use PT_GNU_EH_FRAME ELF segment currently. */ > # if !defined(__UCLIBC__) \ > && (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2) \ > || (__GLIBC__ == 2 && __GLIBC_MINOR__ == 2 && defined(DT_CONFIG))) > # define USE_PT_GNU_EH_FRAME > # endif As an experiment, I built gcc-4.3.2 with the "!defined(__UCLIBC__)" diked out. I rarely use C++, but a simple exception test with an exception thrown from one .o file and caught in another seemed to work correctly. So, it seems I should report this as a bug in gcc-4.3.2, asking them not to treat uClibc as different from glibc in this regard. The present behavior is costly -- it bloats all executables. But before I do, I thought I should check here to see if anyone knew of a reason it is unsafe for GCC to rely upon uClibc's dl_iterate_phdrs. Michael Deutschmann ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Exceptions problem
I've recently made a discovery concerning uClibc and C++ exceptions.
Really, my "throwcp" patch doesn't go far enough, for *all* functions,
including cancellation points and qsort() could be marked __THROW, leaving
uClibc no more broken than it is already.
The problem is that, for exceptions to pass through a function like
qsort(), as in the C++ example below:
-8<-
#include
#include
static int dummy_comparer(const void *,const void *)
{
throw 42;
}
char dummy_array[2] = {0, 0};
int main(int argc, char **argv)
{
try
{
qsort(dummy_array,2,1,&dummy_comparer);
}
catch (int ei)
{
assert(ei == 42);
return EXIT_SUCCESS;
}
abort();
}
-8<-
... it's not enough that the function not be mistakenly marked __THROW.
It is also essential that it be compiled with "-fexceptions", and that the
library be linked with crtbegin.o / crtend.o. As a result, the above
example will crash on uClibc.
However, the cure, which would mean bloating uClibc with exception tables
and linking with libgcc_s.so, seems worse than the disease.
(GCC supports a way to work with glibc's ld.so and binutils to allow a
library which throws no exceptions to carry exception tables without
linking libgcc_s. However, for some reason this is explicitly disabled
for uClibc, although it seems to have the "dl_iterate_phdr" function GCC
is using, and the rest of the heavy lifting is done by ld.)
Michael Deutschmann
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: __THROW and cancellation point patch.
On Mon, 8 Dec 2008, Rob Landley wrote: > Not much point testing a patch from somebody whose spam filter has > blacklisted > the static IP my mail server has had since 2006. Not my problem. (greps mailserver logs for "landley") Ah, the rule you ran into was a block on "*.verizon.net". I've been blocking them since March 2005. I've added a whitelist entry on your from address, if you care... Michael Deutschmann <[EMAIL PROTECTED]> ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
NTP and uClibc
One of the new configure options in uClibc-0.9.30, UCLIBC_NTP_LEGACY, controls the ntp_gettime() and ntp_adjtime() calls, which are only used by the NTP daemon. You should be aware that stock ntp-4.2.4p5, the current version, will in fact not compile on uClibc no matter how that flag is set. The problem is that ntp requires the call "__adjtimex". If __adjtimex is not detected, the "tickadj" utility will fail to build on Linux. (It falls back to a hack it uses on non-Linux kernels, and uClibc doesn't supply the headers it would need for that.) uClibc has "adjtimex", which has identical semantics (so far as I know), but NTP and its configure script won't use that. The two underscores are mandatory. So to get ntpd to work on uClibc, I have to supply a shim library that translates __adjtimex() to adjtimex(). The good news is that if __adjtimex() is available, NTP can be fully functional without the ntp_???time() calls. So, in the next version of uClibc, I recommend changing "adjtimex" to "__adjtimex", and removing the ntp_???time calls entirely. Michael Deutschmann <[EMAIL PROTECTED]> ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
__THROW and cancellation point patch.
Last March, I made a suggestion to this list: That the many functions which are cancellation points, but would otherwise never throw C++ exceptions, be marked with a "__THROW_CP" macro. This would be a no-op on threaded builds of uClibc, but would be equivalent to __THROW for a threadless build. This would produce a tiny optimization boost for threadless builds, and more importantly, would make the include files much clearer. No longer will every tenth line be part of a comment explaining why __THROW is not applied to a given function. There was no response, probably because while the idea is simple, it requires a lot of typing to implement. Well, I'm back, having done the work. I now have a patch available at: ftp://ftp.ocis.net/pub/users/ldeutsch/beta/uClibc-0.9.30-throwcp.diff The patch adds "__THROW_CP", and applies it to every function previously having a "such-and-such is a cancellation point and so not marked with __THROW" comment. Additionally, fputw(), fgetw(), and BSD sigpause() have been marked __THROW_CP. sigpause() was formerly __THROW, which looked wrong to me. I'm "dogfooding" the patch, but that doesn't really count for much since I don't use C++. I'd be interested to see any heavy-duty exception users try it out, both to see if it helps the unthreaded case, and verify it does not break the multithreaded case. Michael Deutschmann <[EMAIL PROTECTED]> ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] all arches: c89 touchup
On Wed, 1 Oct 2008, Rob Landley wrote: > P.S. The reason I'm being annoying about this is I'm trying to come up > with a decent regression test for all the architectures I can get to > run under emulators. I got m68k to build, but qemu only seems to > support coldfire and not real m68k, so I'm sniffing around for another > emulator that might be able to boot the kernel and root filesystem I > just built. I might be able to help with that. I have an Amiga 4000 in working condition. It was originally a 4000/030, but presently has a third-party CPU module with a full 68040 (ie: with FPU and MMU). Michael Deutschmann <[EMAIL PROTECTED]> ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
__THROW and cancellation points
In uClibc's header files many functions are marked with a comment to the effect of "this function doesn't have __THROW because it is or could be a cancellation point". Rather than repeat this comment ad nauseam (since very many functions are in this class), I suggest it would be cleaner to define a no-op "__THROW_CP" macro to use for these functions. Then the comment can occur once at the definition of __THROW_CP. This would also offer a practical advantage, since cancellation points are only an issue with threading. __THROW_CP would only need to be a no-op in a threaded build of uClibc. For no-thread builds, it could be defined identical to __THROW, so that non-threaded users can gain the optimization benefits of correct __THROW declarations more often. Michael Deutschmann <[EMAIL PROTECTED]> ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Alignment fixups for gethostbyname_r
Mike Frysinger wrote: > the nice thing about alignment tests are they're easy to write ... the bad > thing is that not everyone has native alignment requirements, so it'll pass > fine on the common systems (x86/x86_64), warn on the semi-common (arm/hppa) > (and no one will notice), and only fail on the uncommon (Blackfin). Actually, there's an obscure flag bit that puts an IA-32 processor in a mode where it is fascist about alignment. So it should be possible to derive a special uClibc build which operates with the flag set, and will fault if there are alignment issues. Michael Deutschmann <[EMAIL PROTECTED]> ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Linux 2.0 troglodyte signing in
Hello, mailing list! Normally introduction posts are unnecessary in technical forums, but I felt I should say something since my intended use of uClibc is a little eccentric. You may remember wy back with Linux 2.2.0 came out, there were some cautions that the new kernel was a little bloated and maybe less stable, so for the moment it might be a good idea for slower machines to stick with 2.0.x for a while. I run a do-it-yourself GNU/Linux on old "toaster" computers, so I followed that advice. But, since then my impression of the stability of current versions of Linux has gone *down*, not *up*. So I continue to run 2.0 to this day. (It's also become something of a game to me, now...) There are some challenges, however. Current versions of GLIBC demand a current kernel, and current versions of GCC want a current GLIBC. So I'm stranded at glibc-2.1.3 and gcc-2.95.3. The latest versions of other applications usually compile, but sometimes patching is needed. Compounding this, I'm proud of my ability to cram all my root executables onto just two bootable floppies, without resorting to busybox. The binaries on my recovery disks are the same ones I use day-to-day. But the space margin is getting thin, and a current kernel and glibc would blow it away. uClibc offers me a way to solve both problems. It gives me back over 600k of rootdisk space (before compression) while offering better source compatibility than my ancient glibc. While uClibc is advertised as supporting Linux 2.0, I did encounter a number of serious bugs. But I found them easy to fix, and now have a prototype system running Linux-2.0.40 / uClibc-0.9.29 / gcc-4.2.2 which is fully self-hosted and working well. If the screaming about how crazy I am isn't too loud ;-), I'll probably send most of my changes to the bug-report system soon. Don't worry, most of my patches are very small and some resolve bugs that are not specific to old kernels. Michael Deutschmann <[EMAIL PROTECTED]> ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
