similar to: klibc broken on ppc with linux-2.6.27 and workaround

If the linux kernel was built using O=builddir, there is no correct choice for the linux symlink in klibc-1.5. See below for the possible outcomes: ----------------------- KLIBCCC usr/klibc/vsnprintf.o In file included from usr/include/sys/types.h:15, from usr/include/unistd.h:11, from usr/include/stdio.h:11, from usr/klibc/vsnprintf.c:13:

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

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 Sat, 31 Dec 2011, Aurelien Jarno wrote: > s390 and s390x are sharing the same include files, in > /usr/lib/klibc/include/arch/s390. However klcc seatches for the s390x > includes in /usr/lib/klibc/include/arch/s390x, which doesn't exist. > > The patch below fixes the issue by using the ARCHDIR variable instead > of the ARCH one in klcc. It's one possible fix,

This reverts commit 9d8d648e604026b32cad00a84ed6c29cbd157641, which broke signal handing on some architectures. On m68k and parisc, signal return depends on a trampoline that the kernel writes on the stack. On alpha, s390, and sparc (32-bit), we can avoid this by providing our own function as sa_restorer, but we currently don't. Signed-off-by: Ben Hutchings <ben at decadent.org.uk>

Basic infrastructure for building klibc. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 5bba564a5c133369b3e83e5827d053a98cb3c59a tree 11f2acc1f9d845e8764fa790f522b79ea1106b80 parent 378abd8f4d39024ea6c87eb5b54155238f647f0d author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:08 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:08

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]

The following patchset implements 3 seperate series of changes. External Building ================= Patches 1 through 8 enable to use of klibc's build system while leaving the src tree pristine (and potentially read only). Specifically: - srctree=<Sources for klibc> - objtree=<Ouput directory for klibc> - KLIBCKERNELSRC=<Kernel sources> - KLIBCKERNELOBJ=<Kernel

with the recent move of the includes from linux' include/asm-$ARCH to arch/$ARCH/asm, klibc fails to compile, because the in-linux-header files include from asm/, but this is not in the header search path. e.g. against linux-2.6.27 arm: arm-iwmmx-linux-gnueabi-gcc -Wp,-MD,usr/klibc/.vsnprintf.o.d -nostdinc -iwithprefix include -Iusr/include/arch/arm -Iusr/include/bits32

Hi, I wanted to test the kinit setup on my configuration, and I found out that I'm unable to build using an external object directory (i.e. using O=../dir). I'm using the sources from the GIT tree. The first problem is in usr/dask/Kbuild, in the invocations of mktokens; with O= the build system will try to execute something like:

GEN usr/klibc/syscalls/SYSCALLS.i GEN usr/klibc/syscalls/syscalls.nrs GEN usr/klibc/syscalls/typesize.c KLIBCCC usr/klibc/syscalls/typesize.o OBJCOPY usr/klibc/syscalls/typesize.bin GEN usr/klibc/syscalls/syscalls.mk GEN usr/klibc/syscalls/SYSCALLS.i GEN usr/klibc/syscalls/syscalls.nrs GEN usr/klibc/syscalls/typesize.c KLIBCCC

Merge s390 and s390x into s390. Compiled and tested on s390/s390x and i386. Also cross compilation for s390/s390x tested. This patch shouldn't break the build of any architecture. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> --- Makefile | 1 scripts/Kbuild.install | 4 +- scripts/Kbuild.klibc

Hi, From the Makefile I figured that to build klibc where the kernel was built with O=/someotherdir, you need to do: make KLIBCKERNELOBJ=/someotherdir KBUILD_SRC=1 Everything seems fine though, but it fails to link dash with: ----- KLIBCCC dash/bltin/printf.o KLIBCCC dash/system.o KLIBCCC dash/bltin/test.o KLIBCCC dash/bltin/times.o KLIBCCC dash/var.o GEN dash/init.c KLIBCCC

I've run into a problem with building klibc with high parallelism It's not quite predictable, but at a -j of approx 25-30 or more (on a 24 hyperthreaded machine), I often get something like the following error messages: ... KLIBCCC usr/klibc/sigsuspend.o KLIBCCC usr/klibc/sigprocmask.o KLIBCCC usr/klibc/pselect.o KLIBCCC usr/klibc/ppoll.o /git/KLIBC/usr/klibc/sigsuspend.c:8:31: fatal

H. Peter Anvin dixit: >You should be using the output of "make headers_install" to build klibc. Hm. Can we catch that somehow? Like? #ifdef using_uninstalled_kernel_headers # error Go RTFM! #endif ? in the klibc sources, centrally somewhere? Ideally, a klibc header that?d also be included when using klcc to build some? thing, so that both klibc-build time and klibc-use time would

On Wed, Apr 05, 2006 at 10:45:51PM +0200, maximilian attems wrote: [Received a forward of this mail and I had deleted the original one. So your reply-chain is broken]. > > sparc still needed to build with gcc-3.3 > belows makes use of the exported CC variable. > > also export the binutils for consistency, > added the missing ones too for klcc. > > > diff --git

This is a series of patches for clang compatibility: - Using flags needed flags and removing unsupported flags. - Adding support for clang's LLD linker. - Removing a variety of warnings. Bill Wendling (3): [klibc] Kbuild: use "libc.a" with clang [klibc] Kbuild: Add "-fcommon" for clang builds [klibc] Clean up clang warnings Michael Davidson (1): [klibc] Kbuild:

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

- Renamed IMAGE_BASE to LD_IMAGE_BASE_OPT. - Moved "-fcommon" to KLIBCREQFLAGS in scripts/Kbuild.klibc. - Remove "dash" warning fixes which have been upstreamed. - Conditionalize the inclusion of compiler flags by using the proper compiler name or "cc-option". - Added "-Werror" to "cc-option" to catch flags that cause warnings. - Retain

Hi, We installed the latest 1.4.24 on a test machine and can't get zaptel nor dahdi compile. It's a Linux Debian Etch. Errors we have: keewi:/usr/src/dahdi-linux-2.1.0.4# make make -C /lib/modules/2.6.18-custom.2/build ARCH=i386 SUBDIRS=/usr/src/dahdi-linux-2.1.0.4/drivers/dahdi DAHDI_INCLUDE=/usr/src/dahdi-linux-2.1.0.4/include DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes