| Age | Commit message (Collapse) | Author |
|---|
|
but they do no harm for the linuxthreads case. Yes, I tested this.
|
|
only once. Generalize all toplevel makefiles. Make sure, that libdl.so is built against libc.so and not libc.a
|
|
|
|
breaks compatibility with existing binaries, unless the new COMPAT_ATEXIT option is enabled.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
every subdir
|
|
|
|
|
|
|
|
|
|
be able to run apps built with 0.9.27. This also renames
__uClibc_start_main to __uClibc_main.
This compat option should be removed some time after 0.9.28 is released.
Let me know if you don't like this change.
|
|
|
|
|
|
using grep because the '.config' will not get included if we are doing
a 'clean' or other targets. This was preventing the proper cleaning up
target architecture include files.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- add support for DESTDIR to work the same as PREFIX
|
|
|
|
Add UCLIBC_BUILD_NOEXECSTACK support.
|
|
Seperate out security features into a separate menu
|
|
rename UCLIBC_PROPOLICE to UCLIBC_HAS_SSP
|
|
-fstack-protector and -fno-stack-protector-all security
options
|
|
rename UCLIBC_PIE_SUPPORT to UCLIBC_BUILD_PIE
|
|
|
|
as the flags for all calls to 'as'
|
|
Here's an updated version of the patch I posted about a month ago. It
leaves -nostdinc alone, and uses -print-file-name=include instead of
-print-search-dirs to figure out where GCC's internal headers are.
Please let me know whether there are any portions of this patch you'd
like me to break into smaller pieces, to rework, or to give up trying
to get into uClibc :-) Thanks,
|
|
the utils using the uClibc-targeted toolchain.
|
|
|
|
The attached patch is an updated version of an earlier sent patch
It solves the problem that the target utils (ldconfig/ldd/iconv, readelf
is not handled, but can be easily added) are not built w/ the newly
created [S]crt[01].o files.
|
|
Mazinger implements the changes suggested by me on the uclibc list.
On Tuesday 28 September 2004 02:24 pm, Erik Andersen wrote:
> What I think should be done is
>
> *) Someone that cares about USE_CACHE should fix that option
> up to be sure it works, and give it a proper config entry
> in extra/Configs/Config.in, and rename it to something
> more appropriate such as LDSO_CACHE_SUPPORT.
>
> *) When LDSO_CACHE_SUPPORT=n, UCLIBC_RUNTIME_PREFIX /usr/X11R6/lib
> should be included in the default library search path in
> dl-elf.c, ldd, and ldconfig.
>
> *) When LDSO_CACHE_SUPPORT=y, UCLIBC_RUNTIME_PREFIX /usr/X11R6/lib
> should be excluded from the default library search path in
> dl-elf.c, ldd, and ldconfig, and those wishing to include
> X11 stuff should add that into /etc/ld.so.conf and re-run
> ldconfig.
>
> *) At present, LDSO_CONF and LDSO_CACHE use the same names
> and same structure as glibc. This precludes
> LDSO_CACHE_SUPPORT being uses in any sane fashion on a
> dial glibc and uClibc system. Just as it was necessary
> for use to use a different name for 'libuClibc' rather
> than 'libc', and 'ld-uClibc.so.0' rather than
> 'ld-linux.so.2' it seems that these configuration files
> really ought to be given different names.
>
|
|
|
|
|
|
[peter.kjellerstedt@axis.com]
Peter Kellerstedt writes:
May I suggest the attached patch instead?
It handles PICFLAG the same way as it was already done
for other architectures (e.g., CRIS and frv).
|
|
This patch makes -fpic work for PCC and optimzes the relcation by moving the cache
flushing stuff to JMP relocs only. Actually PPCs ldso can only handle small
GOT tables(<=8192 entries)anyhow, so it makes little sense to compile PPC with -fPIC.
libuClibc shrunk from 340724 to 330780 bytes with -fpic.
|
|
won't be needed for 3.3.4 either when I get some time to clean up that
toolchain which also suffers from the g++ include dir search order bug.
|
|
about the best settings the AMD Elan and the VIA Nehemiah.
|
|
This patch adds code to uClibc to support a new ABI designed for the
FR-V architecture, that enables text segments of executables and
shared libraries to be shared by multiple processes on an OS such as
uClinux, that can run on FR-V processors without an MMU.
Patches for binutils and GCC have just been posted in the
corresponding mailing lists. The binutils patch was approved,
but there's one additional patch pending review, that I posted
this week. An updated GCC patch will be posted to
gcc-patches@gcc.gnu.org as soon as I complete testing (I used a
known-good compiler to test the uClibc patch below).
Since the existing dynamic loader code didn't support independent
relocation of segments, it required changes that were somewhat
extensive. I've added a number of new machine-specific macros to try
to keep the platform and ABI-specific details outside the generic
code. I hope this is not a problem.
|
|
|
|
|
