Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
Hello Erik,
to compile the new uClibc release for a SH3 we need some little
modifications:
First I fix the crt[in].S files, so we can use them for big endian and
little endian targets.
|
|
broke a couple of days ago. :-(
|
|
|
|
showed up while running the latest LTP testsuite.
-Erik
|
|
|
|
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.
|
|
|
|
|
|
need to be fixed properly. I tried, but I was unable to build a cross
toolchain for each of these (using stock binutils and gcc) so it is someone
else's problem to fix them now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I've noticed a few people have posted over the last year about problems
compiling programs that use vfork when pthreads are involved. Some
detective work turned up that ptfork.c aliases vfork to fork and then tries
to call the original fork as __libc_fork. This patch removes the aliasing
when there is no MMU present, and uses the same call semantics to call
__libc_vfork. I then added a symbol to the m68k vfork.S to allow vfork to
be called as __libc_vfork.
The same bug exists in the uClibc CVS, and with a possible tweak this patch
should go through there as well.
Obviously, all other platforms need __libc_vfork as a workable means to call
vfork in order for this to work for them.
Let me know if there are any problems with this patch.
Art Shipkowski
Videon Central Software Engineer
(814)235-1111 x307
|
|
|
|
|
|
|
|
|
|
|
|
function not implemented".
|
|
we were unable to switch back to the original saved group/user ID.
-Erik
|
|
|
|
|
|
|
|
|
|
stop applying patches by hand...
|
|
select for older 2.0 kernels where poll is missing.
|
|
fpu_control.h header file, since the correct arch specific one was
always later overwritten by the generic one. oops.
-Erik
|
|
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.
|
|
contributed by John Williams <jwilliams@itee.uq.edu.au>
|
|
Current uClibc contains only one fpu_control.h and it is i386 version.
This is a patch to use platform specific fpu_control.h. All new files
come from glibc 2.3.2. This patch is against 0.9.21 but also can be
applied to CVS as is.
|
|
|
|
expected thing. A so called "D'oh!".
|
|
|
|
code.
|
|
is not defined.
|
|
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.
|
|
is disabled
|
|
fixes it again so it both compiles and works,
-Erik
|
|
|
|
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.
|