similar to: klibc tree status

If you have access to an Alpha, please test klibc-1.3.21; in particular, anything which uses pipes... Thanks, -hpa

When I compile klibc on little-endian mips, I get: KLIBCLD klibc/libc.so ld: klibc/arch/mips/crt0.o: compiled for a little endian system and target is big endian ld: klibc/arch/mips/crt0.o: endianness incompatible with that of the selected emulation ld: failed to merge target specific data of file klibc/arch/mips/crt0.o When I change "elf32-tradbigmips" to

Hello all, I really want to support vfork() in klibc, mostly because uClinux *has* to use it. Unfortunately vfork() isn't allowed to use the stack *at all* across the system call -- including return address -- which means it needs an assembly wrapper on most architectures. I have tried implementing wrappers for most architectures, but I don't know parisc or s390/s390x well enough,

I was wondering if it would be possible to add a cpio (extraction) implementation to klibc. Maybe this can be done in a way that the code could bet shared between klibc and init/initramfs.c in the kernel. Background of what I'm trying to do: I want to load an initramfs from flash on a number of different devices. The devices are quite similar but the partition in flash where the initramfs

Pipe doesn't work in dash on mips/mipsel - everything delivered to a pipe is shown on stdout: mipsel: $ echo foo | cat > ~/d foo <ctrl-c pressed manually> $ cat ~/d $ i386: $ echo foo | cat > ~/d $ cat ~/d foo $ This may be related to the following warnings during compilation but I'm not sure: klibc/arch/mips/syscall.S: Assembler messages: klibc/arch/mips/syscall.S:12:

In case people here don't follow the udev mailing list, udev seems to be quasi-dropping klibc support. Well, see the forwarded message below. As I don't agree with the "omg udev is complex! use glibc!" rationale, I want klibc and udev to remain working with each other.... Assuming some minor breakage in the near future, is klibc open to accepting patches for "basic C

Just curious if anyone has done anything similar, as I'd rather not reporduce work. I'm going to put alias handling (and only alias handling) into a modified version of insmod. The reason I'm doing this is to aid in boot time module loading via aliases exposed in sysfs. Sure, I could include modprobe directly in the initramfs, but it's a bit large, and I really only need alias

I'm supporting a number of consumer devices (e.g. small NAS devices) in Debian. They typically don't export the serial console and don't have any other output devices. We perform the installation via SSH on such devices and start SSH automatically when the system boots so people can login. This works pretty well but sometimes a device stops to boot for no good reason. This is

This was filed as a bug report on the Debian r-base package. It is more properly a bug report on the ctest package in R. The default method for wilcox.test manipulates x and y without checking the class or data.class of these objects. Possible solutions are - create wilcox.test.factor (if appropriate) - check the class and/or data.class of x and y in wilcox.test.default and produce error

Processing commands for control@bugs.debian.org: > reassign 368417 xen-hypervisor-3.0.2-1-i386 Bug#368417: xen-hypervisor-3.0-i386: cannot start NetBSD-HEAD Warning: Unknown package 'xen-hypervisor-3.0-i386' Bug reassigned from package `xen-hypervisor-3.0-i386' to `xen-hypervisor-3.0.2-1-i386'. > reassign 380333 xen-hypervisor-3.0.2-1-i386 Bug#380333:

From: Sjoerd Simons <sjoerd@spring.luon.net> It seems that klibc uses __sparc64__ to determine if it's compiled in 64 bit mode on sparc, unfortunatly gcc doesn't define __sparc64__ :) It does define __arch64__ though. Signed-off-by: maximilian attems <maks@sternwelten.at> --- klibc-1.2.2.orig/include/sys/vfs.h 2006-02-15 18:32:10.000000000 +0100 +++

I see the following on a Jetson TK1: [ 9.495425] [TTM] Initializing DMA pool allocator [ 9.495513] nouveau 57000000.gpu: DRM: VRAM: 0 MiB [ 9.495520] nouveau 57000000.gpu: DRM: GART: 1048576 MiB [ 9.508076] nouveau 57000000.gpu: DRM: failed to create ce channel, -22 A Google search suggests that I'm not the only one with this, but I don't see it being discussed anywhere. Is

Stop makeklcc.pl from hardcoding paths of cc, ld and strip in the klcc script it generates. Using hardcoded paths is generally a bad idea. First, the whole idea of $PATH is that you don't need to hardcode paths. Second, klcc is a Perl script but my hardcoding the paths you make it less portable. Signed-off-by: Martin Michlmayr <tbm@cyrius.com> --- klibc-1.1.16/klcc/makeklcc.pl~

Package: xen-unstable Version: 3.0-unstable+hg11292-2 Your package fails to build with GCC 4.2. Version 4.2 has not been released yet but I'm building with a snapshot in order to find errors and give people an advance warning. The bug below is in your package though and not because I'm using a snapshot of the compiler so please take a look at it. You can reproduce this with the

Hey all, I'm curious if any of you know decent way to test this sort of thing over ssh. That is, I have little experience with Xen/UML/VMware/etc etc, but the ones I have attempted were X-only apps, and thus not suited nicely to testing remotely. The rationale behind this is that my headless fileserver has a decent amount of 'juice' and idle clock cycles, so I've taken to

hello hpa, nothing particular stands out, just syncing with latest Debian upload and subsequent patch emails. please review merge or nack. thanks :) maks git pull git://git.debian.org/~maks/klibc.git maks for the changes: Aaron Griffin (1): [klibc] kinit: skip md assembly if mdX exists Colin Watson (1): [klibc] mount/umount FUSE support Harald Jenny (1): [klibc] fstype:

I'd like to use linear and quadratic trend analysis in order to find out a change in slope. Basically, I need to solve a similar problem as discussed in http://www.gseis.ucla.edu/courses/ed230bc1/cnotes4/trend1.html My subjects have counted dots: one dot, two dots, etc. up to 9 dots. The reaction time increases with increasing dots. The theory is that 1 up to 3 or 4 points can be counted

Hi hpa & others. Following is a list of issues that I hope to be addressed soon so we are in even better shape for -mm inclusion. 1) rebuild initramfs when content changes. > It is a simple matter of copying in usr/Makefile from the latest > -linus kernel and replace the 10 first lines with the content from > klibc Kbuild file. 2) havesyscalls.h is not deleted after make

Hi, Greg - I have a 2.5.70 BK repository, with klibc integrated, at: bk://klibc.bkbits.net/2.5-klibc This repo has the following features: * Completely up-to-date w.r.t. klibc itself. * Kbuild sort of happy, but still needs an eyeball from Kai to figure out why it always rebuilds everything in usr/. * Supports both IP autoconfig and NFS root from initramfs.

I have updated and pushed the klibc-kernel tree. "In theory" it should be a 1:1 replacement for any stock kernel, which kinit taking up the slack. Anyway, I haven't yet removed any in-kernel functionality, but that's hopefully coming; the in-kernel functionality won't be executed in either case. git://git.kernel.org/pub/linux/kernel/git/hpa/linux-2.6-klibc.git -hpa