similar to: warning killing for poor !LANG=C|US people

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",

I have the following toolchain: $ ld --version GNU ld version 2.15.90.0.3 20040415 $ gcc --version gcc (GCC) 3.3.2 I attempted to build klibc with this toolchain. It builds without errors, but the included "ash" shell does not function properly. Testcase: read cmdline </proc/cmdline echo $cmdline The first command prints a message: cannot open /proc/cmdline: error 14 Other

udev knows about DEBUG=true and builds a debug binary. Maybe klibc should do the same? Was there a reason for -g in the i386 MCONFIG? Index: MCONFIG =================================================================== --- MCONFIG (revision 1003) +++ MCONFIG (working copy) @@ -62,5 +62,11 @@ # include $(KLIBSRC)/arch/$(ARCH)/MCONFIG +ifeq ($(DEBUG),true) +STRIP = /bin/true

On Mon, Feb 24, 2003 at 05:26:32PM -0800, H. Peter Anvin wrote: > Greg has taken on the job of integrating klibc with the kernel, but > please post klibc bug reports to the klibc mailing list at > <klibc@zytor.com>. To avoid annoying warning from gcc I had to check for compatibility with -falign-* like we do in arch/i386/Makefile. check_usergcc located in top-level makefile to

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Was just working with the latest 3.54, and find that the Makefile in the menu directory didn't work until I added the /include/syslinux to the file. < CFLAGS = $(M32) -mregparm=3 -DREGPARM=3 -W -Wall - march=i386 -Os -fomit-frame-pointer -I$(LUDIR)/include - I$(COM32DIR)/include -I$(COM32DIR)/include/syslinux -Ilibmenu - D__COM32__ -

Hi, I am trying to compile the version on rhel 5.x box. Nasm version 0.98.39 I extracted the tar.gz and ran make in the extracted directory. Here is where it stops. gcc -Wp,-MT,rawcon.o,-MD,./.rawcon.o.d -m32 -ffreestanding -fno-stack-protector -fwrapv -freg-struct-return -march=i386 -Os -fomit-frame-pointer -mregparm=3 -DREGPARM=3 -msoft-float -fno-exceptions -fno-asynchronous-unwind-tables

Hi I've managed to compile klibc 0.198 and run the hello world program. How can I compile my own program? Can someone give an example or provide a simple wrapper program for doing this? like uclibc did with their earlier versions. I looked at the make process and did a bit reading and figure out this much: gcc -Wp,[preprocessor options] -MT,[target_name_I_think] tests/hello.o,

Thank you all. It looks like -mno-red-zone flag is already in master branch since commit 7d70885d, but it seems it is applied to all EFI builds. IIUC, the problem only affects efi64 builds. So here's the modification of my patch to only apply -mno-red-zone flag to efi64 target. The patch is against master. I verified that it builds correctly in master. Please feel free to accept or reject

make[1]: Entering directory `/syslinux-4.02-6-ge841d69/dos' gcc -Wp,-MT,syslxopt.o,-MD,./.syslxopt.o.d -m32 -ffreestanding -fno-stack-protector -fwrapv -freg-struct-return -march=i386 -Os -fomit-frame-pointer -mregparm=3 -DREGPARM=3 -msoft-float -fno-exceptions -fno-asynchronous-unwind-tables -fno-strict-aliasing -falign-functions=0 -falign-jumps=0 -falign-labels=0 -falign-loops=0

What do I need to do to fix this? [jonsmirl@smirl klibc-0.184]$ make make[1]: Entering directory `/home/dri/klibc-0.184/klibc' gcc -Wp,-MT,syscalls.nrs,-MD,./.syscalls.nrs.d -mregparm=3 -DREGPARM=3 -march=i386 -Os -g -falign-functions=0 -falign-jumps=0 -falign-loops=0 -nostdinc -iwithprefix include -D__KLIBC__ -DBITSIZE=32 -I../include/arch/i386 -I../include/bits32 -I../include

[Added Chris Wright, Rusty and Virt list because they were involved with this issue before] On Thu, 3 Jan 2008, Ingo Molnar wrote: > > * Steven Rostedt <rostedt@goodmis.org> wrote: > > > +# function tracing might turn this off: > > +config REGPARM > > + bool > > + depends on !MCOUNT > > + default y > > are you sure -pg really needs this? Nope!

[Added Chris Wright, Rusty and Virt list because they were involved with this issue before] On Thu, 3 Jan 2008, Ingo Molnar wrote: > > * Steven Rostedt <rostedt@goodmis.org> wrote: > > > +# function tracing might turn this off: > > +config REGPARM > > + bool > > + depends on !MCOUNT > > + default y > > are you sure -pg really needs this? Nope!

Hi Ady, Would it work if we removed "ifdef EFI_BUILD" condition and just add -mno-red-zone for all x86_64 builds? If not, do you have any ideas how to pass this flag? This could work, because the patch is adding the -mno-red-zone flag only for x86_64 builds, which are only used in the form of the efi64 target. The efi32 and bios targets are both 32-bit. BTW. I also tried 6.04-pre1 and

Well, it has to happen at some point, so I have officially pushed out SYSLINUX 3.72. The big news in this release is of course the ISOLINUX hybrid mode support (a single image which can be booted either from a CD-ROM or from a hard disk/USB stick), but there are plenty of more goodies in here, including the label listing (not technically completion) on the Tab key. As usual, huge thanks to

From: Sylvain Gault <sylvain.gault at gmail.com> The System V ABI for x86-64 specify that a "red zone" is an area of 128 bytes above the current stack frame. This area can be used by a called function in order to avoid the overhead of modifying the stack pointer. The direct effect is that interrupt/event/signal handlers must not write to this area. In the UEFI calling convention,

I have, hopefully, found and fixed the issue with non-kernel binaries that appeared in 3.35. As a result, I have pushed out 3.36-pre6 and am classifying it as a release candidate. Please try it out, especially if you have had problems with 3.35. ftp://ftp.kernel.org/pub/linux/utils/boot/syslinux/Testing/ -hpa

Hi, I am new to LLVM and clang and I would like to seek some professional help. :) I have been trying to compile some C code on a linux x86 computer for a Sparc machine. I used: clang -ccc-host-triple sparc-unknown-linux -ccc-clang-archs sparc -pthreads -lm -emit-llvm test.c -c -o -test.bc The following error messages are produced: /usr/include/pthread.h:665:6: error: 'regparm' is

Are the RPMs for the latest GFS kernel module GFS-kernel-2.6.9-72.2.0.8 to be used with the version 2.6.9-55.0.9.EL available ? I tried to compile the Source RPMs available from the Red Hat site but the modules can't be loaded because of invalid module format arising from version magic issues. The syslog shows: node0 kernel: gfs: version magic '2.6.9-55.0.9.ELsmp SMP 686 REGPARM

On Fri, Sep 16, 2011 at 4:40 PM, Christine Cheng <clcheng at stanford.edu> wrote: > Hi, > > I am new to LLVM and clang and I would like to seek some professional help. > :) > > I have been trying to compile some C code on a linux x86 computer for a > Sparc machine. > > I used: > >  clang -ccc-host-triple sparc-unknown-linux -ccc-clang-archs sparc -pthreads

I get this with current linus bk now and klibc 187 [jonsmirl@smirl ash]$ make sh mknodes.sh nodetypes nodes.c.pat . gcc -Wp,-MD,.cd.d -mregparm=3 -DREGPARM=3 -march=i386 -Os -g -falign-functions=0 -falign-jumps=0 -falign-loops=0 -nostdinc -iwithprefix include -D__KLIBC__ -DBITSIZE=32 -I../include/arch/i386 -I../include/bits32 -I../include -I../linux/include -I../linux/include2 -I../linux/include