Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
calling setrlimit(RLIMIT_STACK, &limit)
|
|
|
|
|
|
|
|
|
|
from Peter S. Mazinger
|
|
|
|
Sometimes it is desirable to build ldconfig non-static.
|
|
for propolice/ssp
|
|
|
|
Add pie support for mips
|
|
Add UCLIBC_BUILD_NOEXECSTACK support.
|
|
Seperate out security features into a separate menu
|
|
rename UCLIBC_PROPOLICE to UCLIBC_HAS_SSP
|
|
rename UCLIBC_PIE_SUPPORT to UCLIBC_BUILD_PIE
|
|
|
|
|
|
using uClibc. mincore() and the ones for Extended Attributes setxattr(), lsetxattr(), fsetxattr(), getxattr(), lgetxattr(), fgetxattr(), listxattr(), llistxattr(), flistxattr(), removexattr(), lremovexattr(), fremovexattr() which are optional.
|
|
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,
|
|
|
|
*current_menu;' in scripts/config/lkc.h line 63, and this conflicts with
static definition in mconf.c.
|
|
dl-cache.h and make use of it. Also disables the lib-path-redundancy check
for the case the cache is not used. Makes use of _PRELOAD_FILE_SUPPORT.
From Peter Mazinger.
|
|
|
|
After the addition of a configuration option for
enabling the support of /etc/ld.so.cache, I thought
it might be a good idea to add one for the support
of the /etc/ld.so.preload file too. So here it is.
While doing this, I also noticed that the dynamic
linker would hang indefinitely if either LD_PRELOAD
or /etc/ld.so.preload contained a library which was
already loaded, so I made a patch for that too.
And of course, I could not resist from doing a little
clean up of comments and indentation, so here is a
patch for that too.
|
|
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.
>
|
|
be used by the unsuspecting masses quite yet.
|
|
Port the generic optimized string funcs from glibc, with some tweaks
to cut their size a little. The main change is making memmove
call memcpy for forward copying to trim redundant code.
Make use of both the generic and arch-specific speed-optimized string
funcs configurable. Arch-specific take precedence over generic,
and generic takes precedence over basic size-optimized uClibc funcs.
|
|
|
|
|
|
|
|
size and performance penalty to profiling applications this way, as well as
Heisenberg effects, where the act of measuring changes what is measured.
There are better tools for doing profiling, such as OProfile, that do not
require gcc to instrument the application code.
-Erik
|
|
|
|
Hi Erik,
I'm not sure why the NIOS support is not in uClibc -- perhaps the patch
was rejected or never submitted? In any case, I'm playing with some NIOS
stuff and created this patch against 0.9.26. The work was done by
Microtronix. I'm not sure who else contributed to it. It would be great
to have the NIOS support available in uClibc so developers don't have to
go searching for these bits.
Pete
|
|
Hello,
the attached patch should bring extra/config in line
with the Linux 2.6.7 sources.
The following are the commit messages for the respective
files from the Linux bk-repository:
checklist.c:
* fix menuconfig choice item help display
confdata.c:
* config: choice fix
* kconfig: don't rename target dir when saving config
expr.c, expr.h:
* config: disable debug prints
mconf.c:
* fix menuconfig choice item help display
menu.c:
* Kconfig: use select statements
symbol.c:
* config: choice fix
* Avoid bogus warning about recursive dependencies
* c99 struct initialiser conversions
textbox.c:
* janitor: don't init statics to 0
util.c:
* fix lxdialog behaviour
//Peter
|
|
|
|
This patch arranges for the .so files in say /usr/lib to be soft links
to ../../lib, instead of to /some/arbitrary/pathname/lib. This
enables seamless relocation of a toolchain containing the development
and run time trees in a sys-root.
|
|
|
|
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.
|
|
does, rather than depending on the kernel header files.
-Erik
|
|
stuff will see other than "delete".
|
|
|
|
items, we have to declare what endianness cpus are capable of supporting
and work using dependancies.
|
|
|
|
|