Age | Commit message (Collapse) | Author |
|
Ported over from GNU C Library and runtime tested in Qemu.
|
|
Otherwise, buildroot rejects uClibc-ng in an external toolchain.
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
This commit includes following features.
1. Support NPTL/TLS
2. Add libm function which is used to handle FP rounding and excpetions
(ex: fclrexcpt,fedisblxcpti,feenablxcpt... )
3. Add *context function for operating user context
(ex: setcontext,getcontext,makecontext... )
4. Change the return flow from signal handler
5. Cleanup of old code
The testsuite only has 2 errors, tst-cpuclock1 and tst-cputimer1,
which are related to timing accuracy. (math and locale tests are disabled)
Signed-off-by: Vincent Ren-Wei Chen <vincentc@andestech.com>
|
|
|
|
|
|
|
|
The syscall wrappers are not required and other C libraries
do not provide them. Busybox modutils.c must be patched so
that syscall() is used for uClibc-ng.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
|
|
Remove __UCLIBC_HAS_OBSTACK__ as it isn't very uptodate and
maintained part. It shouldn't be required for any software and
mostly shipped with stuff which use it. (f.e. binutils-gdb)
|
|
This option is enabled for a long time and I see no
useful case where we should be incompatible to glibc here.
|
|
These adds the stubs from gettext-tiny 0.0.5
from here:
https://github.com/sabotage-linux/gettext-tiny
|
|
To use it enable UCLIBC_HAS_LIBICONV, then iconv_open/iconv_close
should be available.
|
|
|
|
|
|
|
|
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
|
|
Only static linking is supported for now.
More debugging and analyzing for ld.so, TLS and NPTL
is required. But at least you can bootup a static
root fileystem in Qemu.
|
|
Not perfect, but a starting point.
Some tests of the test suite are failing.
|
|
To analyze or debug any linuxthreads problems it is useful to
have the ability to have a full gdb on the target available.
At the moment you could only debug stuff on microblaze.
Now we can verify that linuxthreads are working fine for
every supported architecture.
|
|
|
|
|
|
|
|
Enable locale application to be build when utils are
build. Remove useless compile and link warnings.
Default to minimal locale builds.
Signed-off-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
|
|
A single test with targeting ARM showed that this feature
seems bit rotted. Remove DOMULTI and simplify Makefiles.
|
|
|
|
Signed-off-by: Martin Thomas <mtdev@hamtam.de>
|
|
Add support for Andes Technology NDS32 architecture.
See here http://www.andestech.com/en/index/index.htm for more
informaton. Verification of the port from an older uClibc
port was done on a sponsored AG101p board.
The testsuite only has 5 errors, three are related to
an existing bug in dlclose() with LT.old, also happening
on cris32 and m68k.
Failures to fallocate/posix_fallocate are unresolved.
Thanks to Andes Technology sponsoring the hardware and
being very helpful while doing the uClibc-ng porting.
Signed-off-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
|
|
Select required features. Fix intendation.
Reported-by: Leonid Lisovskiy <lly.dev@gmail.com>
|
|
Nobody should use gcc 3.3 nowadays.
|
|
|
|
There exist some problem with the new memcpy/memset functions
imported from GNU libc/newlib. If you have any problem
with the new MIPS optimized assembly try to disable
prefetching support.
Thanks to Rene Nielsen and Matthew Fortune analyzing the
problem so far.
|
|
Linuxthreads.new isn't really useful with the existence
of NPTL/TLS for well supported architectures. There is no
reason to use LT.new for ARM/MIPS or other architectures
supporting NPTL/TLS. It is not available for noMMU architectures
like Blackfin or FR-V. To simplify the live of the few uClibc-ng
developers, LT.new is removed and LT.old is renamed to LT.
LINUXTHREADS_OLD -> UCLIBC_HAS_LINUXTHREADS
|
|
Ported over from glibc mostly without changes.
Lightly tested with mongrel2 in qemu-system-sparc.
|
|
This might be used to generate a Debian copyright file.
|
|
Currently, the Thumb support on ARM has three related Config.in
options, which are not trivial for users to understand, and are in
fact not needed:
- The USE_BX option is not needed: knowing whether BX is available or
not is easy. If you have an ARM > v4 or ARMv4T, then BX is
available, otherwise it's not. This is the logic used in glibc.
- The USE_LDREXSTREX option is not needed: whenever Thumb2 is
available, ldrex/strex are available, so we can simply rely on
__thumb2__ to determine whether ldrex/strex should be used, without
requiring a Config.in option.
- Once USE_BX and USE_LDREXSTREX are removed, the only thing left
that COMPILE_IN_THUMB does is to set -mthumb. This makes the option
unnecessary, as on ARM at least, the user is already supposed to
pass -march=<foo> or other compiler options tuning the library for
a specific ARM variant. There is no reason to do otherwise for
Thumb, which allows to get rid of the COMPILE_IN_THUMB option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
|
|
Obstack was enabled in ARC defconfig to enable builds of native binutils and
GDB. This is not needed after earlier patch which removes invalid
_GNU_OBSTACK_INTERFACE_VERSION definition in cases when obstack is not
selected in uClibc configuration. With this change binutils and GDB would
use obstack implementation from their own source trees. In fact with recent
binutils it is not possible to build it using obstack implementation in
uClibc, because binutils/include/obstack.h started to use _obstack_free
function instead of obstack_free, but _obstack_free is not defined in
uClibc.
Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
|
|
The FR-V port is really broken, and I have no emulator
or hardware for this platform. I tried to get some hardware
from RedHat, who made the FR-V port initially. Unfortunately
Fujitsi didn't agreed to sent me some of their unused spare
hardware lying @RedHat. As I invested some time to get stuff compiled,
I decided to add the code and may be anytime later I can gain
access to some emulator or hardware.
GDB simulator for FR-V doesn't support booting Linux AFAIK.
|
|
At least allow to compile a toolchain targeting nios2 without MMU.
|
|
At least allow to build a toolchain for hppa.
Sync some headers with glibc.
|
|
syncfs() was recently added (commit dfa593d4d). But man sync(2) specifies
that syncfs() is Linux-specific. This was overlooked in the original
commit so we add it to the set of Linux-specific functions supported by
uClibc.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
|
|
|
Both architectures are more or less deprecated.
No Linux upstream support, no gcc support for uClinux.
|
|
Argp is an advanced support for parsing unix-style argument vectors.
In addition to the common getopt interface, it provides automatic
response
to `--help' and `--version' options and use of custom parser in
conjunction
with argp native option parser, among others.
Argp support is required by elfutils package and prelink.
In uClibc argp functionalities has been moved from C library to
libuargp.so
Further the libc.so linker script contains an AS_NEEDED entry so that
it doesn't need to link libuargp.so explicitely.
Disable argp test if feature disabled.
Signed-off-by: Salvatore Cro <salvatore.cro@st.com>
Signed-off-by: Filippo Arcidiacono <filippo.arcidiacono@st.com>
Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
|
|
|
|
The current (arbitrary) limit of 128 characters for path names has
proven too short for Android builds, as longer path names are used
there.
Change conf.c, so it can handle path lengths up to PATH_MAX characters.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
|
|
|
|
Get rid of NIOS support. We try to support NIOSII.
|
|
It is marked as broken and it seems you can't get
any hardware for that anymore.
|
|
I mailed with Jan-Benedict Glaw, it seems VAX on Linux
is really a lot of work todo and uClibc support didn't work ever.
|
|
No real hardware available. The project for sh64 with sh5 seems
dead since 10 years. Gcc will remove support for it soon.
|