similar to: [PATCH] avoid size_t redefinition

Hi, I?ve gone through the mailing list archives and hereby want to resubmit my pending patches. Most are independent of each other, except the m68k patch which will only be complete if sigsuspend is also fixed. (It can be applied before that, though.) http://www.zytor.com/pipermail/klibc/2012-January/003173.html [PATCH] fix m68k support Resubmitted here as 0005. While there was a question from

/klibc/klibc/include/bits32/bitsize/stdint.h:8: error: redefinition of `int8_t' /klibc/linux/include/linux/types.h:109: error: `int8_t' previously declared here The copy in stdint.h is not protected by: #ifndef __BIT_TYPES_DEFINED__ #define __BIT_TYPES_DEFINED__ #endif /* !(__BIT_TYPES_DEFINED__) */ ===== Jon Smirl jonsmirl@yahoo.com __________________________________ Do you Yahoo!?

Hi, after changing mksh to no longer use mkstemp, I decided to try and build mksh-static with klcc on most platforms, in Debian. Here are the results by Debian architecture: alpha (4) fails amd64 works armel works armhf (3) fails i386 works ia64 works m68k (1) workaround mips works mipsel works powerpc (2) fails ppc64 works (!) s390 works s390x works sparc works Architectures not listed either

Le 21/08/2013 12:20, maximilian attems a ?crit : > On Tue, Aug 20, 2013 at 07:44:39AM +0200, leroy christophe wrote: >> Find attached two patches I have in order to build klibc 2.0.2 >> against kernel 3.8.13 >> We had to introduce those patches when going from kernel 3.6 to kernel 3.7 >> Hope it helps. >> > those patches are wrong and again very brittle. >

On Tue, Aug 20, 2013 at 07:44:39AM +0200, leroy christophe wrote: > > > Find attached two patches I have in order to build klibc 2.0.2 > against kernel 3.8.13 > We had to introduce those patches when going from kernel 3.6 to kernel 3.7 > Hope it helps. > those patches are wrong and again very brittle. just use the way it is described in `make help': A) cd ~/src/linux

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

Im using snapshot 0.81. make[1]: Entering directory `/home/rogelio/src/klibc-0.81/klibc' gcc -Wp,-MD,./.getenvtest.d -march=i386 -Os -falign-functions=0 -falign-jumps=0 -falign-loops=0 -nostdinc -iwithprefix include -I../klibc -I../klibc/arch/i386/include -I../klibc/include/bits32 -D__KLIBC__ -DBITSIZE=32 -I../klibc/include -I../linux/include -W -Wall -Wpointer-arith -Wwrite-strings

fwd'ing to klibc malinglist. ----- Forwarded message from Lo?c Minier <lool at dooz.org> ----- Date: Wed, 16 Mar 2011 23:34:51 +0100 From: Lo?c Minier <lool at dooz.org> To: Debian Bug Tracking System <submit at bugs.debian.org> Subject: Bug#618616: arm build failure with latest binutils - usr/klibc/syscalls/_exit.S:29: Error: .size expression does not evaluate to a

I get the following error: make[1]: Entering directory `/home/greg/src/klibc/klibc-0.196/klibc' gcc -Wp,-MT,__static_init.o,-MD,./.__static_init.o.d -march=i386 -Os -g -malign-functions=0 -malign-jumps=0 -malign-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

Thank you, Clayton. It works now! Our debugger server responds "name:J28;generic:fp;bitsize:32;encoding:uint;format:hex;gcc:60;dwarf:60". And I also set other "generic" attributes like sp, pc, ra, arg1~arg8 to related registers. I dig a little and find llvm dwarf generator uses TargetRegisterInfo::getFrameRegister() to obtain frame base, and uses

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 \

This patch does two things. This test program results (on i386) in an error about _NSIG: #include <signal.h> #if defined (SIGRTMAX) int rtmax = SIGRTMAX; #endif The cause is that the kernel signal.h defines SIGRTMAX as _NSIG, then makes _NSIG invisibelby hiding it inside ifdef __KERNEL__. Perhaps it's more elegant to solve this in the kernel, but the ramifications of that scare

The *.shared targets require -shared on powerpc, and -R leads to linker errors. This patch makes the -R an arch define. ia64 at least requires -R. --- ash/Makefile +++ ash/Makefile 2003/11/27 15:04:02 @@ -36,7 +36,7 @@ $(STRIP) $(PROG) $(PROG).shared: $(OBJS) $(LIBS) - $(LD) $(LDFLAGS) -o $(PROG).shared -e main $(KLIBSRC)/interp.o $(OBJS) -R $(KLIBSRC)/libc.so $(LIBGCC) + $(LD) $(LDFLAGS)

I tried building with linux-2.6.0-test7 build dies with: make[1]: Entering directory `/home/rogelio/src/klibc-0.80/klibc' gcc -Wp,-MD,./.fork.d -march=i386 -Os -fomit-frame-pointer -malign-functions=0 -malign-jumps=0 -malign-loops=0 -nostdinc -iwithprefix include -I../klibc -I../klibc/arch/i386/include -I../klibc/include/bits32 -D__KLIBC__ -DBITSIZE=32 -I../klibc/include

In src/lib-ssl-iostream/iostream-openssl-params.c a call is made to DH_generate_parameters. This function has been deprecated since OpenSSL 0.9.8. With OpenSSL 1.1 compilation will throw an error. Not sure how to send patches, I don't even know if the patch I wrote actually works (I don't program in C, but gave it a shot anyway) but below is the patch. ---

Patch v2 --- a/src/lib-ssl-iostream/iostream-openssl-params.c +++ b/src/lib-ssl-iostream/iostream-openssl-params.c @@ -13,10 +13,19 @@ generate_dh_parameters(int bitsize, buffer_t *output, const char **error_r) { DH *dh; unsigned char *p; - int len, len2; + int len, len2, success; +#if OPENSSL_VERSION_NUMBER >= 0x00908000L + success = DH_generate_parameters_ex(dh, bitsize,

> On April 26, 2017 at 3:15 PM Peter van der Does <peter at avirtualhome.com> wrote: > > > Patch v2 > > --- a/src/lib-ssl-iostream/iostream-openssl-params.c > +++ b/src/lib-ssl-iostream/iostream-openssl-params.c > @@ -13,10 +13,19 @@ generate_dh_parameters(int bitsize, buffer_t *output, const char **error_r) > { > DH *dh; > unsigned char *p;

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

Hi all, Please review this patch. It's fixing PR3232 comment #8. Function bar from 2008-03-24-BitFiled-And-Alloca.c compiles to: %struct.Key = type { { i32, i32 } } ... define i32 @bar(i64 %key_token2) nounwind { entry: %key_token2_addr = alloca i64 ; <i64*> [#uses=2] %retval = alloca i32 ; <i32*> [#uses=2] %iospec =

Based on the recent found weaknesses in DH key exchange, http://weakdh.org/ I increased ssl_dh_parameters_length to 2048 bits, and found waited for 5+ minutes for dovecot to come back online after a restart. Unless you got a fast machine, the initialization of DH parameters can exceed your patience. Regeneration may not be a problem (if ssl_parameters_regenerate=0 or if Dovecot uses old