similar to: Detecting KLIBC from userspace

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

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

Hi, Here's a try at writing an initramfs HOWTO. This is basically a write-up of a number of interesting emails I collected over time. It could probably use an editor, more fact-checking and a bunch of other good things, but it should be better than nothing ;-) Daniel -------------- next part -------------- INITRAMFS HOWTO 0) What are klibc and initramfs? Initramfs is a ramfs into which

Hi, I hope this is the right list for initramfs questions. First I noticed: with initrd I can use real-root-device and pivot_root mechanisms. with initramfs only pivot_root works. My init (or linuxrc) scripts end like this: mount -t xfs -n -o ro /dev/mapper/root /new-root umount -n /sys || true umount -n /dev || true umount -n /proc || true cd /new-root pivot_root . initrd exec chroot .

working fine with glibc. thanks! Andreas -- ---------------------[ Ciphire Signature ]---------------------- From: aj@ciphirelabs.com signed email body (35 characters) Date: on 19 January 2005 at 12:48:14 GMT To: klibc@zytor.com ---------------------------------------------------------------- : The message above has been secured using Ciphire Mail. : Verify this signature and download your

Hi, please correct me if I'm wrong: - the kernel needs enough ram for the compressed initramfs and the same files decompressed, so it can decompress the files and boot the /init on the initramfs. - if the kernel does not have enough ram, it will kernel panic. my tests were done on a server with 256 mb ram and a 80MB compressed initrd. I removed some packages and now it fits and the

a bit unrelated, still I wonder: does syslinux contain an mbr? or does anyone know any app that contains an mbr and can install it, without overwriting the partition table? my experience is, that is wise to have an mbr and use the active flag to select the active partition (which might have a bootmanager installed). however every linux distribution I know installed the bootloader such as

Hi, I'm using initramfs with pivot_root mechanism to mount my real root directory. I notived the gentoo halt.sh script tries to unmount everything on shutdown. That includes /initrd. The kernel seems to freeze immideatly. Do you have the same problems? Regards, Andreas CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_CLEAN_COMPILE=y

Commit-ID: 95a3123c94abc28c65f33c9589693dde9f140fe1 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=95a3123c94abc28c65f33c9589693dde9f140fe1 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Sat, 29 Aug 2020 22:29:52 +0100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 29 Aug 2020 22:53:10 +0100 [klibc] Kbuild, klcc: Support

Commit-ID: 7752eb456addbd1973e9c6b609294ccef89a65a2 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=7752eb456addbd1973e9c6b609294ccef89a65a2 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Thu, 20 Aug 2020 21:48:07 +0100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Thu, 20 Aug 2020 21:50:09 +0100 [klibc] klcc: Treat CC, LD, STRIP

Signed-off-by: Thorsten Glaser <tg at mirbsd.org> --- klcc/klcc.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/klcc/klcc.in b/klcc/klcc.in index 43d0984..e03bf3c 100644 --- a/klcc/klcc.in +++ b/klcc/klcc.in @@ -136,7 +136,7 @@ while ( defined($a = shift(@ARGV)) ) { } else { die "$0: unknown option: $a\n"; } - } elsif ( $a =~

Later versions of gcc include an option in the form of --param=name=value. This patch adds support for this and continues to support the --param name=value option. Signed-off-by: Mike Pagano <mpagano at gentoo.org> --- klcc/klcc.in | 15 +++++++++++---- 1 files changed, 11 insertions(+), 4 deletions(-) diff --git a/klcc/klcc.in b/klcc/klcc.in index 711a832..5d00bfd 100644 ---

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 \

I've been working on a buildrelease.sh script to call hg2dist.sh, export debian/ from svn and run dpkg-source for me. When I ran dpkg-source I noticed that it gave warnings regarding the *.dpatch files being chmod 0755 is there any reason to maintain this within the repository or would 0644 suffice and remove these warnings from dpkg-source? Regards, Jeremy --

Commit-ID: 23273aa05bdc564eb8ff0565d9df9c3edfffaee9 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=23273aa05bdc564eb8ff0565d9df9c3edfffaee9 Author: Olliver Schinagl <oliver at schinagl.nl> AuthorDate: Sat, 25 Jul 2020 10:59:01 +0200 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sun, 26 Jul 2020 00:16:13 +0100 klcc: Remove the need for bash

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

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

On Sat, 2020-07-25 at 10:59 +0200, Olliver Schinagl wrote: > 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