search for: stddefs

Syslinux fail to build with gnu-efi >= 3.0.16 with error: In file included from /host/i686-buildroot-linux-gnu/sysroot/usr/include/efi/efi.h:44, from /build/syslinux-6.03/efi/efi.h:23, from /build/syslinux-6.03/efi/adv.h:4, from /build/syslinux-6.03/efi/adv.c:29:

Hello there, I'm building a Linux distribution based on musl and LLVM as default toolchain (including lld/libc++/libc++abi/libunwind rather than GNU). For most of the time this works pretty well. However I'm having troubles with few packages, webkit for instance fails because of max_align_t being redeclared in musl's stddef.h I see that stddef.h is provided by both musl and in the

Please patch Mini-OS so that it uses stddef.h to define size_t and NULL. This problem fixes errors that occur when linking Mini-OS with ANSI standard code that uses stddef.h. John diff -ur oxen-3.0-testing/extras/mini-os/include/lib.h nxen-3.0-testing/extras/mini-os/include/lib.h --- oxen-3.0-testing/extras/mini-os/include/lib.h 2006-04-14 22:21:55.000000000 -0400 +++

This patch protects against redefinitions of size_t. There are currently at least two different definitions provided with klibc: unistd.h -> stddef.h -> bits32/bitsize/stddef.h sys/times.h -> linux/times.h -> linux/types.h both define size_t, causing gcc to complain. I suspect ptrdiff_t has a similar problem; not covered by this patch. Regards, Erik diff -urN

Just for the archive or in case of anybody is interested in: The problem is the missing stddef.h which resides more than one time on the OS. I mistakenly thought, that there is an typo in the code, because one of this files is in /us/include/linux so I changed #include <stddef.h> to #include <linux/stddef.h> But this was wrong and it is the wrong file too. The right file to

Hi folks, I am new to install xen 4.1.0-rc6-pre version on RHEL 6.2. When installing xen tools flask, I got an error said “No rule to make target ‘/usr/lib/gcc/x86-64-redhat-linux/4.1.2/include/stddef.h”, but I am using gcc 4.4..6. How to fix this? Thanks & Best Regards Shengkai _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org

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

src/libFLAC/memory.c cannot be compiled with MSVS 2005 (and probably VS2008 too) after this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=7cbecbae9f70be770f7651d09531fec0de6f9cf5 because MSVS2005 doesn't provide stdint.h. According to MSDN, uintptr_t is defined in "STDDEF.H and other include files".

Zig tests using Debug build of 5.0.1rc2 hit this bug: https://bugs.llvm.org/show_bug.cgi?id=34452 I suppose the fix has not been backported to 5.0.1. So I created a Release build of 5.0.1rc2 and all zig tests pass, with the following patches: * Patches to LLD: commit a206ef34bbbc46017e471063a4a1832c1ddafb0a Author: Andrew Kelley <superjoe30 at gmail.com> Date: Fri Dec 1 12:11:55 2017

echo_daemon is a simple echo which can be used to test connectivity between the client and daemon. --- daemon/Makefile.am | 1 + daemon/echo_daemon.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++ daemon/m4/stddef_h.m4 | 45 +++++++++++++++++++++++++++++++++ po/POTFILES.in | 1 + src/MAX_PROC_NR | 2 +- src/generator.ml | 7 +++++ 6 files changed,

Erik de Castro Lopo wrote: >> because MSVS2005 doesn't provide stdint.h. According to MSDN, >> uintptr_t is defined in "STDDEF.H and other include files". > > Does the rest of FLAC actually support those compilers? Yes. I removed this #include and all projects were successfully built with MSVS 2005 Express. > Is it worth > continuing to support them? * At

--- Greg KH <greg@kroah.com> wrote: > From: Greg KH <greg@kroah.com> > To: Kay Sievers <kay.sievers@vrfy.org> > CC: Hannes Reinecke <hare@suse.de>, linux-hotplug-devel@lists.sourceforge.net > Subject: Re: Bugfix: offsetof in klibc > Date: Thu, 12 Feb 2004 15:52:43 -0800 > > On Fri, Feb 13, 2004 at 12:20:55AM +0100, Kay Sievers wrote: > > On Thu,

Hi, While installing libeidt in Ubuntu 12.0 I am getting the following message. I am not even able to edit the curses.h and stddef.h file. Kindly help. /usr/lib/gcc/i686-linux-gnu/4.6/include/stddef.h:353:23: error: conflicting types for 'wint_t' /usr/include/curses.h:241:18: note: previous declaration of 'wint_t' was here make[3]: *** [terminal.lo] Error 1 make[3]: Leaving

I am having trouble with FC3. After doing a yum update (of 1264 packages) I still cannont compile 1.2.1 from source: make[1]: `libedit.a' is up to date. make[1]: Leaving directory `/usr/src/asterisk-1.2.1/editline' make[1]: Entering directory `/usr/src/asterisk-1.2.1/db1-ast' make[1]: `libdb1.a' is up to date. make[1]: Leaving directory `/usr/src/asterisk-1.2.1/db1-ast'

After more investigation, I decided to just recompile asterisk (on my newly upgraded Fedora core 4 system). Make dies with this error: "No rule to make target 'usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h" It seems this directory is gone under FC4, and replaced by No rule to make target 'usr/lib/gcc/i386-redhat-linux/4.0.0/include/ I can't find the

Dear Alf, > please, I'm trying to install the newest version of ssh, but I fail > every time (see the output below) : > the output of the configure complained, that there's no openssl, but I > installed openssl before: > configure: WARNING: stddef.h: present but cannot be compiled > configure: WARNING: stddef.h: check for missing prerequisite headers? > configure:

--- ssh-rand-helper.c.orig Mon Jun 18 16:48:13 2007 +++ ssh-rand-helper.c Mon Jun 18 16:47:32 2007 @@ -31,7 +31,7 @@ #include <sys/socket.h> #include <stdarg.h> -#include <stddef.h> +#include <string.h> #include <netinet/in.h> #include <arpa/inet.h> Tony. -- f.a.n.finch <dot at dotat.at> http://dotat.at/ SHANNON ROCKALL: EAST OR NORTHEAST

Hi Eli, Thank you for the patch! Yet something to improve: [auto build test ERROR on next-20200715] url: https://github.com/0day-ci/linux/commits/Eli-Cohen/VDPA-support-for-Mellanox-ConnectX-devices/20200716-155039 base: ca0e494af5edb59002665bf12871e94b4163a257 config: mips-allyesconfig (attached as .config) compiler: mips-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build):

I'm creating a struct of `{i8,i64}` and `DataLayout::getTypeAllocSize` is returning `12`. `getStructLayout` also gives an `4` offset for the second element. The native ABI, and clang, for the same type are producing a size of 16, with an alignment of 8, for the second element. This is for the system triple "x86_64-linux-gnu" What could be causing this difference in alignment and

On 04/05/2014 02:30, Tom Stellard wrote: > On Sat, May 03, 2014 at 12:32:02AM +0100, Alp Toker wrote: >> On 02/05/2014 20:45, Tuncer Ayaz wrote: >>> Bump. >>> >>> Is it really unsupported to build llvm from scratch with gcc 4.9 and >>> libstdc++ 4.9? Should I file a bugzilla ticket instead? >> Obviously LLVM/clang should compile out of the box