similar to: HUGE change soon coming to a klibc near you

In klibc-0.114, any shell script like this: ====================================================================== #!/path/to/klibc-0.114/ash/sh echo hi ====================================================================== ...elicits the following error when executed: /var/tmp/hack.sh: Can't open /var/tmp/hack.sh Running under strace, I get: execve("/var/tmp/hack.sh",

--9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I stripped down the insmod command from modules-init-tools for use with klibc. Rusty agreed to have this contributed to klibc. The second patch removes old style modules support. -- ciao, Marco --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment;

initramfs-tools version 0.117 requires 'readlink -f' and 'mount -o defaults' to work. The first two patches were previously submitted but not applied. Ben. Ben Hutchings (3): Implement realpath() readlink: Add -f option mount: Implement -o defaults usr/include/stdlib.h | 2 ++ usr/klibc/Kbuild | 2 +- usr/klibc/realpath.c | 49

Hi!! I found your ipconfig stuff in the udev rpm in SuSE 9.1. I'm about to setup a initramfs (pretty cool - much better than initrd) to boot linux diskless clients over the net. All the tools I would need, seem to be there with ipconfig/nfsmount ... I like to use the information I get from PXE/syslinux or Etherboot writing something like:

Commit-ID: 25a66fa8d8623fae267f6807b56438cd7c40e034 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=25a66fa8d8623fae267f6807b56438cd7c40e034 Author: maximilian attems <max at stro.at> AuthorDate: Wed, 21 Aug 2013 17:31:25 +0200 Committer: maximilian attems <max at stro.at> CommitDate: Wed, 21 Aug 2013 17:32:16 +0200 README.klibc: update build information It

Dear all, When I debugged the execution performance of an application using strace, I found there are some system calls like open and stat64 which run faster on XenLinux than the standard Linux. The following is the output of running "strace -c /bin/sh -c /bin/echo foo" on both systems. An open call runs averagely 109 usec on standard Linux but only 41 usecs on XenLinux. An stat64

Kay Sievers wrote: > Hi, > this simple program compiled with klibc: > > #include <stdio.h> > int main(int argc, char* argv[]) > { > setenv("TESTENV", "happy", 1); > printf("TESTENV='%s'\n", getenv("TESTENV")); > } > > prints: > > ./env > TESTENV='(null)' > >

Hi, I just got a bug report that klibc doesn't compile on s390: KLIBCCC usr/klibc/libgcc/__clzsi2.o KLIBCCC usr/klibc/libgcc/__clzdi2.o usr/klibc/libgcc/__clzdi2.c: In function `__clzdi2': usr/klibc/libgcc/__clzdi2.c:24: warning: implicit declaration of function `__builtin_clz' This looks like a common problem, because __builtin_clz is available since gcc 3.4, while the kernel

Here's an assortment of build and run-time fixes for various architectures that we've applied in Debian. Ben. Aurelien Jarno (1): ppc64: fix struct stat Ben Hutchings (2): MIPS: Update archfcntl.h syscalls: Override detection of direct socket syscalls on i386, m68k, s390 Helge Deller (1): Add pread and pwrite 32bit syscall wrappers for parisc Mauricio Faria de Oliveira

I'm thinking it's time to release klibc-1.5; however, before releasing klibc-1.4.31 as klibc-1.5, I wanted to give a call to see if there is anything that either really needs to be done, or any bug reports I've missed... -hpa

I'm trying to do a full rebase (history clean) of the klibc kernel tree, and came across the following changesets between klibc 1.3.12 and .16: --- a/usr/klibc/arch/s390/syscall.c +++ b/usr/klibc/arch/s390/syscall.c @@ -11,6 +11,6 @@ long int __syscall_common(long int err) { if ((unsigned long)(err) < (unsigned long)(-125)) return err; - errno = err; +

leroy christophe dixit: > Also you can see that it does try to create /lib instead of > /tmp/klibc-install/lib hence my second patch. That actually seems to be by design. I always set SHLIBDIR on the make command line, so it overrides that. bye, //mirabilos -- > Wish I had pine to hand :-( I'll give lynx a try, thanks. Michael Schmitz on

Le 22/08/2013 07:43, leroy christophe a ?crit : > Le 22/08/2013 00:59, Thorsten Glaser a ?crit : >> leroy christophe dixit: >> >>> Also you can see that it does try to create /lib instead of >>> /tmp/klibc-install/lib hence my second patch. >> That actually seems to be by design. I always set >> SHLIBDIR on the make command line, so it overrides that.

Le 22/08/2013 14:36, Thorsten Glaser a ?crit : > leroy christophe dixit: > >> If I set prefix to / and INSTALLROOT to /opt/klibc, klcc is not able to find >> the include files >> If I set prefix to /opt/klibc and SHLIBDIR to /opt/klibc/lib, it is the target >> that tries to load klibc.so from /tmp/klibc-install/lib instead of /lib > INSTALLROOT is some sort of

Hi, The current strlcpy code in the Syslinux tree copies one byte too much. Basically, it misses something like the following klibc patch: http://git.kernel.org/cgit/libs/klibc/klibc.git/commit/klibc/strlcpy.c?id=4644bd92e21c7fd9a48dd8dfd0c4f8ef772843f0 As the current klibc may carries lots of other relevant fixes as well, I wonder whether there is a way to import a newer klibc, or what's

This series fixes link/load issues I found on i386 with Debian's toolchain (gcc 8 with PIE as default, binutils 2.31). Ben. Ben Hutchings (2): [klibc] i386: Use -Ttext-segment to avoid address collision [klibc] Disable PIE scripts/Kbuild.klibc | 3 ++- usr/klibc/arch/i386/MCONFIG | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) -------------- next part -------------- A

Before we start accessing a huge (> 16 TiB) OCFS2 volume, we need to confirm that its journal supports 64-bit offsets. So we need to check the journal's feature bits before recovering the journal. This is not possible with JBD2 at present, because the journal superblock (where the feature bits reside) is not loaded from disk until the journal is recovered. This patch loads the journal

Are there any version compatibilities between linux and klibc? I tried to compile the latest klibc (1.5.18) with the latest linux (2.6.32.15) and there is miserable compile failures. It looks like klibc wants some headers to be in include/asm (linked in my case to include/asm-x86) but they are instead in include/asm-generic (it seems all headers but one are in there). I put together this script

See http://gcc.gnu.org/gcc-4.3/porting_to.html for details. Signed-off-by: Jon Ringle <jon at ringle.org> --- usr/include/klibc/compiler.h | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/usr/include/klibc/compiler.h b/usr/include/klibc/compiler.h index 816a4ee..e0da37e 100644 --- a/usr/include/klibc/compiler.h +++ b/usr/include/klibc/compiler.h @@ -24,7 +24,11

Hello, Sorry if this question is a FAQ, but I don't find it anywere. Does klibc support dynamic linking ? TIA -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwind.it> Key fingerprint = CE3C 7E01 6782 30A3 5B87 87C0 BB86 505C 6B2A CFF9