| Age | Commit message (Collapse) | Author |
|---|
|
We use the compiler-driver and not ld.
|
|
|
|
|
|
header is not needed to build gcc. Move generation of this header.
(Yann E. MORIN)
|
|
a problem where the linker was trying to use the wrong symbol name for the
init function.
Define SYMBOL_PREFIX as _ in Rules.mak for h8300, bfin, i960,
microblaze, and v850. Add -D__UCLIBC_UNDERSCORES__ in CFLAGS for targets
which define SYMBOL_PREFIX as _. Remove defines and undefs from
uClibc_arch_features.h of each target.
Add $(SYMBOL_PREFIX) to __uClibc_init when passed by ld option -init.
|
|
|
|
iby redefining __always_inline to inline until gcc 4.x.x will get
fixed.
Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
|
|
iby redefining __always_inline to inline until gcc 4.x.x will get
fixed.
Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
|
|
|
|
__dns_lookup(). This avoids segmentation faults when more than 1024
file descriptors are used by an application.
|
|
|
|
|
|
|
|
|
|
|
|
MontaVista noticed that when their kernels were configured to trap on unaligned
access gethostbyname_r could mysteriously crash. I tracked this down to an
unaligned buffer being passed to gethostbyname_r from some other part of uClibc
(afraid I don't remember where from any more). We have to pad the beginning of
the buffer to a pointer alignment before we store pointers in it.
|
|
exists, and move some definitions to their proper place.
|
|
doing double negatives
|
|
local one
|
|
|
|
|
|
This was one of the stragglers still bent on __uClibc_start_main
utilization, now it's only FR-V.
|
|
|
|
|
|
misaligned scratch buffers
|
|
execls fail by simply not releasing the memory reserved for the arguments of children processes
|
|
gcc version checking in every pt-machine.h header ... while __extern_always_inline should work fine, i think what is intended is __extern_inline ... should double check later
|
|
|
|
|
|
|
|
- add missing header guards while at it
|
|
|
|
generalizes what Blackfin was already doing)
|
|
The following patches add support for the Xtensa processor architecture
to uClibc. They are based on a recent SVN checkout (12/05/2007).
The first patch (attached to this post) adds Xtensa support to various
shared configuration and make files. The following patches then include
the Xtensa specific files and directories.
I welcome any feedback and would appreciate it if you could include the
patches into the mainline tree. I am certainly committed to maintain the port.
Bob Wilson was kind enough to review the patches.
Some notes about the architecture: Xtensa is a configurable and
extensible processor architecture developed by Tensilica. For more
information, please visit: www.linux-xtensa.org.
|
|
|
|
|
|
string functions
|
|
|
|
|
|
Cirrus Logic EP93XX ARM9 Procs.
|
|
sys_errlist[] to strerror()
|
|
|
|
|
|
I noticed, that in libc/misc/syslog/syslog.c when the syslog socket is opened, the close-on-exec flag is not set, as it is in gnu libc.
This enables that behavior.
|
|
I had occasion to look at the uClibc script "getent" and felt compelled to clean out the cargo-cult programming style. I believe that this version is clearer, and I've added some minor features while I was in there:
* usage clause, if no arguments or "--help" requested
* original version appears to have been intending to "exit 2" on failure to match, but didn't
* basic, probably good enough, support for ethers and netgroups
* faster ;-) [as if that matters for this script]
|
|
|
|
transparent
|
|
When no TIOCGPTN definition is present in the kernel headers, the library's ptsname() function will not work.
The libc/stdlib/ptsname_r.c file is the problem. This file includes a complicated nest of #if directives. One of these #if's has the opposite sense from what is required.
|
|
as documented in the function api
|
|
On an i386 platform with no rt_sigsuspend syscall (ie: Linux 2.0), compilation will halt on libc/sysdeps/linux/common/sigsuspend.os with a cryptic error message:
"Error: non-constant expression in ".if" statement"
I've investigated and found that the cause is that a literal '0' is being passed into a block of complex assembler macrology that is only prepared to deal with register names - '%eax', etc.
In turn, that seems to be because of a typo in the GCC register constraints. The constraints for 2 and 3-argument syscalls includes a "C" constraint. To gcc, "C" means an SSE floating point constant -- an unlikely element in a syscall. I suspect the author meant to type "S" (%esi).
|
