| Age | Commit message (Collapse) | Author |
|---|
|
Here's the patch for the ldso bits for sh64. This is still in need of a bunch
of debugging, testing, etc. and is really only being submitted for general
completeness. This assumes that the previous patches I've submitted have
already been applied.
I plan on playing with this and buildroot some more later, as I'd definitely
like to see buildroot images for sh64.
|
|
This patch adds the libpthread backend bits for sh64. As noted previously,
we can't inline things like the testandset() in pt-machine.h as we need to
use a completely different ISA / CFLAGS in order for this to work.
As a result, this patch is somewhat of a RFC as well to see what people think
of the libpthread/linuxthreads/sysdeps Makefile approach, etc. The approach
I've taken currently has been to provide a sysdeps/Makefile with a note that
TARGET_ARCHs that want build rules can simply add themselves into the list of
matching architectures to add to the subdir rule for. This probably isn't
the cleanest solution, but it's quite transparent and works quite well.
|
|
256 is fine of course, but many applications use this value
and expect it to be larger.
|
|
Nothing overly interesting here, this renames Hitachi/Mitsubishi to Renesas
for the relevant platforms (in this case, h8, sh, and m32r). The same changes
have already been going on in gcc/binutils/gdb/glibc/etc.
|
|
|
|
currently supported)
|
|
|
|
are implemented in hardware or via kernel emulation doesn't matter to
the libc code.
|
|
|
|
Another little patch fix the configuration for the SH3 targets. The SH3 has
no FPU, but our ldso runs fine on a SH3 target. (I think the
ldso should also run on a SH2 target, so you might want to enable the ldso
for SH2 targets too. But I can't test it, since I have no such a system) :
|
|
Dear Erik,
We downloded uClibc lattest version from the CVS. Still there are some
minor problems with extra/Configs/Config.e1
You have actually set ARCH_HAS_C_SYMBOL_PREFIX to NO which is not
correct for our architecture. Please apply the patch that will fix the
problem.
Best Regards,
- George
P.S. Patch also removes some irritating comments we have added in the past.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
endian cris architecture.
|
|
|
|
on a per-arch basis, or left to the user to choose.
|
|
|
|
some defaults. So give it some empty defaults and let people
select their own options.
|
|
Hello!
The latest changes document ldd in RUNTIME_PREFIX/bin, but it is installed
in RUNTIME_PREFIX/usr/bin
Peter
|
|
|
|
90% of correct is simply not good enough. Some people will not be very happy
about the decision to kill the wrapper toolchain. Sorry, but a real toolchain
is the One True Way(tm).
-Erik
|
|
which should simplify enabling arbitrary architectures.
-Erik
|
|
|
|
Remove the ADD_LIBGCC_FUNCTIONS option and do things the right way.
Either we have a shared libgcc available, or the libgcc routines
aren't PIC and don't belong in the shared libc anyway.
|
|
The attached patch performs a clean up of
extra/gcc-uClibc/gcc-uClibc.c:
* Use NULL for pointers and '\0' for characters;
not the opposite...
* Fixed an (assumed) segv if --uclibc-cc was used.
* Skip the argument to -x so it isn't considered
to be a source file.
* Simplified the loop in xstrcat().
* A little white space clean up.
//Peter
|
|
prepend "__". Unfortunately, when we #undef things, we do not prepend the
"__". This results in collateral damage to unsuspecting applications as we
undefine random unrelated macros. Oops.
For example, when compiling xfree86, libGLcore.a defines MALLOC for its own usage.
But include/bits/uClibc_config.h then does an
#undef MALLOC
#define __MALLOC_930716__ 1
which inadvertantly trashes the define from libGLcore.... Ouch.
The autogenerated include/bits/uClibc_config.h should instead have
contained:
#undef __MALLOC__
#define __MALLOC_930716__ 1
This patch makes that happen.
|
|
|
|
ln.patch:
* Define $(LN) as ln in Rules.mak.
* Change all occurrences of ln into $(LN).
* Change all constructs like (cd path && ln -sf foo/file file)
into $(LN) -sf foo/file path/file. The latter construct is
already used in a number of places so it should not be
an additional compatibility problem.
|
|
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.
|
|
|
|
|
|
|
