| Age | Commit message (Collapse) | Author |
|---|
|
rm.patch:
* Define $(RM) as rm -f in Rules.mak and test/Rules.mak
(this is the same definition as gmake uses by default).
* Change all occurrences of rm and rm -f into $(RM).
|
|
install.patch:
* Define $(INSTALL) as install in Rules.mak.
* Change all occurrences of install into $(INSTALL).
* Change all occurrences of mkdir -p into $(INSTALL) -d.
install -d is already used in a number of places so
this should not be an additional compatibility problem.
|
|
|
|
|
|
Hello,
Attached is a patch of some changes I made to the gcc wrapper to
get it to compile XFree CVS.
Basically it supports the use of '-' on the command line to read stdin
for gcc, as well as setting the file type back to none before adding the
last too .o files if the file type was set on the command line.
It is applied against uClibc-0.9.20
Regards,
nash
|
|
contributed by John Williams <jwilliams@itee.uq.edu.au>
|
|
The attached patch performs a clean up of
extra/gcc-uClibc/Makefile:
* Better dependencies to only rebuild what is necessary.
* Use $< and $@ where appropriate.
* Suppress warning messages from which about
commands that cannot be found.
//Peter
|
|
|
|
|
|
|
|
|
|
Sorry I didn't test this before the release.
Please remember that the locale data generation tools are not very robust,
so doing something like disabling 8-bit codeset support is likely to break
things. As it stands, UTF-8 support is required, but I'm not sure I test
for that.
Also, you will notice a difference in the locale data generated by uClibc
verses glibc. That's because the bg_BG locale specifies use of grouping
in LC_NUMERIC, but supplies no grouping char. The uClibc locale code
tests for and works around this (at the moment) by disabling grouping.
But the result is slightly different data which ripples throughout the
rest of the tables.
|
|
1. Under Solaris the test command with the 'string' argument don't
work well. So I added the '-n' argument, which might work on all
platforms.
2. The sed under Solaris don't support the '-s' argument, which is a
GNU extension. I changed it to '-e' which works fine for me.
|
|
appears to be wrong with their toolchain that is tickled
by LFS.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static build sizes and not needing wchar support.
Add in a SUSv3 getopt as an option for those not needing gnu getopt.
Again, mainly for the static linking crowd.
|
|
|
|
top level config menu.
|
|
|
|
|
|
|
|
headers. Move most of that into a script, and warn loudly
when having to guess.
-Erik
|
|
SYSTEM_DEVEL_PREFIX says: "This defaults to $(DEVEL_PREFIX)/usr", but it
actually defaults to just "($DEVEL_PREFIX)".
Just thought I'd mention it... :)
|
|
(2) Add a command-line option --uclibc-cc with the same functionality.
|
|
|
|
|
|
Move stub gettext functions to a stub libintl to make switching in
gnu gettext easier. Also add a few gnu-isms.
Change to using hidden names with global weak aliases for the extended
locale functions, as expected by libstd++.
Slightly rework the locale data generation stuff to allow pregenerated
locale data to be used with buildroot.
|
|
|
|
|
|
the UNDEFINED entry set properly.
|
|
Here's a patch that implements the beginnings of a rudimentary sh64 port. So
far, this only works static, as I haven't done any of the ldso work yet. I've
also not touched the libpthread stuff yet either, so that's also disabled for
now.
This port was based off of some work that Sean McGoogan at SuperH did for his
initial port, but the this patch doesn't carry over too much from there
(basically the libc/sysdeps/linux/sh64/Makefile (or rather, parts of it),
the setjmp/longjmp stuff (which I had to rewrite portions of it to work with
the new toolchains), etc.).
However, for static, everything appears to work correcly, at least in a hello
world type application.
|
|
want glibc style malloc(0) behavior
|
|
|
|
|
|
-Erik
|
|
To use the pregenerated locales, untar in the extra/locale directory.
Do a 'make config' or 'make menuconfig' in the uClibc root dir, then
a 'make headers' followed by 'make -C extra/locale pregen'. Then
continue with 'make' as usual.
|
|
Should be standards compliant and with several optional features,
including support for hexadecimal float notation, locale awareness,
glibc-like locale-specific digit grouping with the `'' flag, and
positional arg support. I tested it pretty well (finding several
bugs in glibc's scanf in the process), but it is brand new so be
aware.
The *wprintf functions now support floating point output. Also, a
couple of bugs were squashed. Finally, %a/%A conversions are
now implemented.
Implement the glibc xlocale interface for thread-specific locale
support. Also add the various *_l(args, locale_t loc_arg) funcs.
NOTE!!! setlocale() is NOT threadsafe! NOTE!!!
The strto{floating point} conversion functions are now locale aware.
The also now support hexadecimal floating point notation.
Add the wcsto{floating point} conversion functions.
Fix a bug in mktime() related to dst. Note that unlike glibc's mktime,
uClibc's version always normalizes the struct tm before attempting
to determine the correct dst setting if tm_isdst == -1 on entry.
Add a stub version of the libintl functions. (untested)
Fixed a known memory leak in setlocale() related to the collation data.
Add lots of new config options (which Erik agreed to sort out :-),
including finally exposing some of the stripped down stdio configs.
Be careful with those though, as they haven't been tested in a
long time.
(temporary) GOTCHAs...
The ctype functions are currently incorrect for 8-bit locales. They
will be fixed shortly.
The ctype functions are now table-based, resulting in larger staticly
linked binaries. I'll be adding an option to use the old approach
in the stub locale configuration.
|
|
|
|
|
|
|
|
|
|
|
|
implement 'UCLIBC_CC', which does this:
$ UCLIBC_CC=gcc-2.95 /usr/i386-linux-uclibc/bin/i386-uclibc-gcc --version
2.95.4
$ UCLIBC_CC=gcc-3.3 /usr/i386-linux-uclibc/bin/i386-uclibc-gcc --version
gcc-3.3 (GCC) 3.3 (Debian)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
So put it where it is supposed to be.
-Erik
|
