similar to: klibc-1.0 pushed

Hi Currently I am trying to get device-mapper and dmraid ported to compile against klibc. So far there was no real issues, as the only thing they used was fscanf and feof not available presently in klibc (but easy to work around). Other than that there are really no way to easily check for installed klibc's other than trying to mangle the output of klcc (from adjusted configure.in): -----

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

Package: klibc Version: 1.5.20-1 Severity: normal Tags: patch User: ubuntu-devel at lists.ubuntu.com Usertags: origin-ubuntu natty ubuntu-patch Hi maks, Since the Ubuntu linux-libc-dev is now installing its asm headers to the multiarch /usr/include/<triplet>/ directory to allow co-installability, I've pushed the attached patch to Ubuntu so klcc knows to include this path when searching

Halo, I was wondering to no avail how to to use the klcc wrapper in order to build udev and module-init-tools. Does klibc has an install target when is embedded in the kernel tree? Is klcc available? .bill

Hi, trying to build klibc 1.1.8 on x86 fails on my machine as follows: KLIBCCC dash/trap.o KLIBCCC dash/output.o dash/trap.c: In function 'trapcmd': dash/trap.c:94: warning: unused parameter 'argc' dash/trap.c:94: warning: unused parameter 'argv' dash/trap.c: In function 'decode_signal': dash/trap.c:398: error: 'SIGRTMIN' undeclared (first use in this

On Sun, 2019-01-20 at 14:18 +0000, Thorsten Glaser wrote: > Hi Ben, > > *massive* thanks for picking up klibc work. This might motivate > me to pick up some of the TODOs for it that have piled on in my > TODO (but only after the freeze, I?m sorry to say, I have more > to do for other packages). > > >And I spotted another test program that has this property >

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.

Currently, in the entire klibc bash is only used to identify the path of the perl binary. It is doing so using the bash built-in 'type' function, which is POSIX compliant according to [0], but the option -c is not. By using `command -v` instead, we achieve the same result, in a POSIX compliant manor [1], potentially removing the unneeded bash dependency. 0

Here's a patch to klcc.in from klibc-0.202. The context: I have an application, managed with GNU automake/autoconf. Packagers should be able to build the application with klibc if available, with plain gcc otherwise, as follows: $ cd ~/klibc-0.202 $ ... make linux symlink $ make bindir=$HOME/local/bin \ mandir=$HOME/local/man \ INSTALLDIR=$HOME/local \ SHLIBDIR=$HOME/local/shlib \

Hi, we?re currently seeing trouble with klibc on several architectures, cf. http://www.zytor.com/pipermail/klibc/2012-May/003277.html and armhf is being one of them, when using klibc to compile mksh-static with it. I can look into it (asked zumbi for build-deps in a sid chroot on harris already), but not 100% sure I?ll find it, so more eyes on klibc would not be unwelcome ;-) maks, does klibc

This patch adds support to klcc for the --param parameter. Signed off by: Mike Pagano <mpagano at gentoo.org> --- klcc.in | 3 +++ 1 file changed, 3 insertions(+) --- klcc/klcc.in.orig 2011-03-21 08:35:02.130497501 -0400 +++ klcc/klcc.in 2011-03-21 08:47:21.025476293 -0400 @@ -159,6 +159,9 @@ while ( defined($a = shift(@ARGV)) ) { # gcc options, that force preprocessing mode

There's a problem in klibc 1.0.12: klcc -c t.c && klcc t.o && ./a.out works, but klcc t.c && ./a.out fails because open3() wants to close its input, and you can do that only once to STDIN. Attached patch makes "klcc t.c" work again. This might break the klcc from stdin option, but I can't tell because I've got no idea how it's supposed to

We currently use KLIBCKERNELSRC and KLIBCKERNELOBJ variables which used to be required to point to a kernel source and object directories. However the kernel headers were reorganised starting in Linux 3.7 such that that doesn't work properly. This series removes KLIBCKERNELOBJ and changes the use and documentation of KLIBCKERNELSRC to be consistent. Ben. Ben Hutchings (4): [klibc]

On Thu, Oct 27, 2005 at 10:22:08PM -0700, H. Peter Anvin wrote: > > >So it looks like as long as dash can link with klibc then: OK, I've got it to build with klibc using klcc: $ size src/dash text data bss dec hex filename 63333 356 5940 69629 10ffd src/dash Unfortunately there seems to be something fishy in parameter expansion as it fails three

Version: 2.0.4 and git Kernel tested: 3.10.70 Description: make install fails with: No rule to make target `headers_install'. File impacted: scripts/Kbuild.install Error Received: make[2]: *** No rule to make target `headers_install'. Stop. make[1]: *** [header] Error 2 make: *** [install] Error 2 Issue: KLIBCKERNELSRC=`pwd`/linux/usr points to Makefile without headers_install rule.

Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.zytor.com/pipermail/klibc/attachments/20050827/b7319510/attachment-0001.bin

klibc currently builds and installs differently depending on the locale and umask at build time. This series fixes that. Ben. Ben Hutchings (2): Install headers with consistent mode dash: mkbuiltins: Fix sort order harder scripts/Kbuild.install | 2 +- usr/dash/mkbuiltins | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -------------- next part -------------- A non-text

Steve Capper dixit: >> Do we need the fpregs saved even though klibc doesn't do fp? >For gcc targetting Aarch64, We can only guarantee that d8-d15 are >left alone when -mgeneral-regs-only is supplied for building klibc >and any software linked against klibc. I would much prefer to We can enforce this in klcc, just like -mregparm=3 is used by the i386 target. bye, //mirabilos

Compilation was ok with klibc-1.5.10 on linux-2.6.25. Distrib does not matter as it is inside a chroot a la LSF With the upgrade to linux-2.6.27 it broke on 1.5.10 (I try too the last 1.5.14) with make[1]: Entering directory `/usr/src/klibc-1.5.14' GEN klcc/klibc.config GEN klcc/klcc HOSTCC scripts/basic/fixdep KLIBCCC usr/klibc/__static_init.o KLIBCCC usr/klibc/vsnprintf.o

On Sun, 2019-01-20 at 04:37 +0000, Ben Hutchings wrote: [...] > ppc/powerpc-linux-gnu: pass fail: malloctest2*, > setjmptest*, sigint* [...] > s390x/s390x-linux-gnu: fail: fcntl fail: malloctest2*, setjmptest* setjmptest*, >