similar to: Add use of NOSTDINC_FLAGS back

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): -----

Hi, So far with the latest changes the projects I am trying to port works fine, except for a mismatch on what is considered the ansi behaviour of islower() in ctype.h: ----- i = 220 islower (i) = 0, ISLOWER (i) = 0 toupper (i) = 220, TOUPPER (i) = 220 i = 221 islower (i) = 0, ISLOWER (i) = 0 toupper (i) = 221, TOUPPER (i) = 221 i = 222 islower (i) = 0, ISLOWER (i) = 0 toupper (i) = 222, TOUPPER

Hi, I am getting this: ----- armv4-unknown-linux-gnu-ld -o tests/fcntl.shared -e main interp.o tests/fcntl.o -R libc.so /usr/lib/gcc-lib/armv4-unknown-linux-gnu/3.3.5/libgcc.a armv4-unknown-linux-gnu-ld: internal error: aborting at /space/var/tmp/portage/binutils-2.15.90.0.3-r4/work/binutils-2.15.90.0.3/ld/ldlang.c line 3835 in lang_place_orphans armv4-unknown-linux-gnu-ld: please report this

__FD_SET, __FD_CLR, __FD_ISSET, __FD_ZERO are inside of __KERNEL__ in: include/asm-ia64/posix_types.h and therefore not available. I've added stuff like this to our code: #ifndef __FD_SET #define __FD_SET(d, set) ((set)->fds_bits[__FDELT(d)] |= __FDMASK(d)) #endif but it would be nice if this can be solved in klibc. Thanks, Kay

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.vas.nu/pipermail/klibc/attachments/20050825/0e6d8370/attachment.bin

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

Hi, If say ppc where LDFLAGS=, you get the problem that klcc is generated like: ----- @LDFLAGS = ( '' ) ----- which then causes '' to get passed to ld, which gives: ----- /usr/bin/ld: : No such file: No such file or directory ----- One of two ways (I tried over here at least) to fix it, namely the quick hack: ----- --- 1/makeklcc.pl 2005-03-10 00:22:03.000000000 +0200

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/20050902/d8550194/attachment.bin

hpa notified me in private mail that we have an issue that when building initramfs - if the content changes (say kinit) then the initramfs will not be rebuild. The solution I have come up with is to let make check all the files included in the initramfs and rebuild it if any files are newer than the initramfs and also rebuild if arguments changes (root_uid). In same process the usr/Kbuild file

Hi, I have a port here of device-mapper to use klibc (still trying to get it upstream, but oh well). It used to work fine, but with latish klibc's I seem to have issues with fread(). Same code with glibc works just fine, but with klibc fread only seems to read the first two lines when it tries to get the major device number for misc and device-mapper from /proc/devices - then it keeps

Hi I have mailed about this previously, but back then it was not really confirmed, so I have let it be at that. Anyhow, problem is that for some reason 2.5/2.6 ext3 with HTREE support do not like what perl-5.8.0 does during installation. It *seems* like one of the temporary files created during manpage installation do not get unlinked properly, or gets into the hash (this possible?) and cause

This fix has been implemented in preparation for the upcoming klibc merge in -mm. But as it fixes a real (but rare I hope) bug in vanilla kernel it will be added to my pending 2.6.17 kbuild queue. I've done quite some changes to the gen_initramfs script and being shell programming newbie review by more experienced shell hackers would be appreciated. I did a git mv

The tools for raidN (mdadm and friends) don't seem to compile with klibc. Has anyone tackled that, lvm or evms yet in a klibc-based initramfs, or do you usually include uclibc or something when it comes time to get fancy (also, looking ahead to crypto-root and such) Tks, Jeff Bailey

Hi, Any reason why the scsi headers and malloc.h are not installed as well for klibc 'make install' ? Thanks, -- Martin Schlemmer -------------- 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 :

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: klibc-mount-opts.diff Type: text/x-patch Size: 886 bytes Desc: not available Url : http://www.vas.nu/pipermail/klibc/attachments/20050601/403b221d/klibc-mount-opts.bin

Hi, Just wondering if klibc are planning on supporting the .note.GNU-stack section and all it entails ? On sort of a related topic - we have QA tests that checks if something have executable stack. Klibc of course fails due to the many .S, and not passing --noexecstack to gas. Adding this to EXTRA_KLIBC{C,A,LD}FLAGS fixes the issue for all the syscalls, crt0.o, interp.o and the .so, as well as

Avoiding full path to KLIBCINC will result in havesyscall.h being generated in the $(objtree). We do not want generated files in the source tree with make O=.. -I parmeters to gcc now prefixed with $(srctree) allowing to pick up the generated .h file in $(objtree) Signed-off-by: Sam Ravnborg <sam@ravnborg.org> --- diff --git a/scripts/Kbuild.klibc b/scripts/Kbuild.klibc index

BANNED CONTENTS ALERT Il sistema di scansione ha rilevato un problema in una email presumibilmente inviata da Lei -> (<klibc at zytor.com>), per il seguente destinatario: -> chic81900r at istruzione.it La consegna del messaggio non e' potuta avvenire Il messaggio e' stato bloccato in quanto contenente delle componenti che violano le policy di accesso al sistema di posta

Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part Url : http://www.vas.nu/pipermail/klibc/attachments/20050516/9a6fbbd1/attachment.bin

Commit-ID: d105e7f87b5d6e8be35cc90976061a30c0c05545 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=d105e7f87b5d6e8be35cc90976061a30c0c05545 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Fri, 1 Feb 2019 15:39:12 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 1 Feb 2019 15:40:52 +0000 [klibc] README: Point the mailing