search for: _gnu_source

I get a redefinition warning on _GNU_SOURCE when compiling with MinGW, and while I could see that this #define was introduced in e4fc44 [1], but the reason to introduce it is not mentioned, and I can't really see a good reason to have it, especially as MSVC will happily compile that source. So far I have found no evidence that _GNU_S...

https://bugzilla.mindrot.org/show_bug.cgi?id=3497 Bug ID: 3497 Summary: setresuid configure check may need _GNU_SOURCE Product: Portable OpenSSH Version: 9.1p1 Hardware: 68k OS: Mac OS X Status: NEW Severity: enhancement Priority: P5 Component: Build system Assignee: unassigned-bugs at mindrot.org Reporter:...

...fweisbec@gmail.com> --- btrfs-list.c | 1 + btrfs.c | 1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/btrfs-list.c b/btrfs-list.c index 7741705..9dedb5d 100644 --- a/btrfs-list.c +++ b/btrfs-list.c @@ -16,6 +16,7 @@ * Boston, MA 021110-1307, USA. */ +#define _GNU_SOURCE #ifndef __CHECKER__ #include <sys/ioctl.h> #include <sys/mount.h> diff --git a/btrfs.c b/btrfs.c index ab5e57f..672ffe2 100644 --- a/btrfs.c +++ b/btrfs.c @@ -15,6 +15,7 @@ */ +#define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <string.h> -...

I find that adding -D_GNU_SOURCE is useful for linux. This define enable more features from header files. First) i found that define enable declaration/definition of following methods - grantpt(...) - unlockpt(...) - ptsname(...) for device "/dev/ptmx" ( support for ptys, preferred is method openpty (...) ) Second) _GN...

The patch makes gen_init_cpio generate the initramfs_data.cpio from a file which contains a list of entries: file, dir, nod. I swapped the order of filename/location for the file arguments so that it would be more uniform with the dir and nod tyes. [thayne@torch linux-2.6.8]$ usr/gen_init_cpio --help ERROR: unable to open '--help': No such file or directory Usage:

...8b tools/xenpaging/xenpaging.c --- a/tools/xenpaging/xenpaging.c Tue Dec 13 09:49:55 2011 +0100 +++ b/tools/xenpaging/xenpaging.c Tue Dec 13 10:22:09 2011 +0100 @@ -18,7 +18,6 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#define _XOPEN_SOURCE 600 #define _GNU_SOURCE #include <inttypes.h>

ISSUE: ExternalFunctions.cpp::lookupFunction() calls dlsym(RTLD_DEFAULT, ...). In glibc, dlfcn.h does not make RTLD_DEFAULT visible unless _GNU_SOURCE is #defined. Unlike the evil money-grubbing non-free software pigs at sun, the FSF is trying not to pollute the C namespace. ;) ACTION: Hack the Makefile to #define _GNU_SOURCE while compiling in tools/lli. Yes, I know that this is ugly. PATCH: Apply from llvm top-level directory with "p...

I am trying to use the fnmatch() function in a C program and pass as the 3rd arg (options) of case insensitive search... When I use the value FNM_CASEFOLD it does not work... I'm confused on what to send to fnmatch() to do a case insensitive search. Any pointers ? Thanks. Jerry

...; Try `guestfish --help' for more information. [Exit 1] ------------------------------ The fourth patch makes the Before/After change demonstrated above. The last patch avoids new cpp macro redefinition warnings. Now that we're using a few more gnulib modules, they end up defining _GNU_SOURCE via a definition in config.h, so the explicit definitons in various *.c files evoke warnings. $ wc -l 00* 45 0001-build-avoid-some-autoconf-warnings.patch 353 0002-guestfish-write-help-to-stdout-use-gnulib-s-progname.patch 27 0003-guestfish-don-t-try-to-diagnose-getopt-failure.patch 53...

Two simple build fixes for libldm. Well, the first isn't a build fix as such, but a code improvement. Rich.

On Wed, Feb 24, 2016 at 8:02 AM, Pete Batard via Syslinux <syslinux at zytor.com> wrote: > I get a redefinition warning on _GNU_SOURCE when compiling with MinGW, and > while I could see that this #define was introduced in e4fc44 [1], but the > reason to introduce it is not mentioned, and I can't really see a good > reason to have it, especially as MSVC will happily compile that source. So > far I have found no evid...

...as errors btrfs.c: In function ''split_command'': btrfs.c:168: warning: implicit declaration of function ''strndup'' btrfs.c:168: warning: incompatible implicit declaration of built-in function ''strndup'' make: *** [btrfs-list.o] Error 1 We can add _GNU_SOURCE definition according man strndup. Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> --- btrfs-list.c | 1 + btrfs.c | 2 +- 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/btrfs-list.c b/btrfs-list.c index 7741705...

When run under valgrind, the 'errors' test would sometimes fail because a single NBD_CMD_WRITE managed to actually send() the entire packet to the server without blocking the state machine. To make things more robust, switch to a server which is serialized (memory is parallel, but sh is serial), and which intentionally does not read a second command until the first is processed, then

Only to signal that if you want to compile app_rxfax and app_txfax with last cvsses of asterisk you have to modify the patched versions of the apps directory Makefile to define the symbol _GNU_SOURCE example, the line to compile app_rxfax from: gcc -O2 -g -Iinclude -I../include -c -o app_rxfax.o app_rxfax.c to gcc -D_GNU_SOURCE -O2 -g -Iinclude -I../include -c -o app_rxfax.o app_rxfax.c this won't break compilation but I've not tryied functionality becuse of my mgcp problems wit...

...piler identification is MSVC 19.0.23026.0 My CPP includes are: WIN32 _WINDOWS NDEBUG _CRT_SECURE_NO_DEPRECATE _CRT_SECURE_NO_WARNINGS _CRT_NONSTDC_NO_DEPRECATE _CRT_NONSTDC_NO_WARNINGS _SCL_SECURE_NO_DEPRECATE _SCL_SECURE_NO_WARNINGS __STDC_CONSTANT_MACROS __STDC_FORMAT_MACROS __STDC_LIMIT_MACROS _GNU_SOURCE %(PreprocessorDefinitions) Now, a couple of things are suspicious: - in googling around it seems like there are some problems with including Windows.h (which I have to include for other reasons) as well as the LLVM headers, at least with previous versions of LLVM. - on OSX, I did have to add a -...

Hey All, I'm having a bit of a problem trying to get spandsp working on my asterisk machine. The machine is a Redhat 9.0 install with the latest version of libtiff and libtiff-devel (according to freshrpms.net). I manaaged to download, compile and successfully install the actual spandsp package with no errors. The problem comes when I try to compile the rxfax and txfax asterisk

...may get trashed if the user sits behind one of these corporate firewalls that modifies the download payload and replaces it with something like "You are not authorized to download this file"... o [PATCH 5/5] installers: fix a MinGW redefinition warning I get a redefinition warning on _GNU_SOURCE when compiling with MinGW, and while I could see that this #define was introduced in e4fc44 [4], but the reason to introduce it is not mentioned, and I can't really see a good reason to have it, especially as MSVC will happily compile that source. So far I have found no evidence that _GNU_S...

...3 16:36:37 -0000 1.65 +++ configure.in 21 Jul 2003 04:20:22 -0000 @@ -65,7 +65,7 @@ ;; esac else - XIPH_CFLAGS="-Wall -ffast-math -fsigned-char" + XIPH_CFLAGS="-Wall -ffast-math -fsigned-char -DVERSION=${SHOUT_VERSION}" AC_DEFINE(_GNU_SOURCE, ,[Define if you have POSIX and GNU specifications]) DEBUG="-g" PROFILE="-pg -g" Index: src/shout.c =================================================================== RCS file: /usr/local/cvsroot/libshout/src/shout.c,v retrieving revision 1.48 diff -u -r1.48 s...

I am having trouble building appradius from http://appradius.minitelecom.org/ I configure, make, make install cpprad-1.0, but when I configure, then make appradius I get :- obelix:/usr/src/appradius/appradius1.0 # make make[1]: Entering directory `/usr/src/appradius/appradius1.0/lib' make[1]: Nothing to be done for `all'. make[1]: Leaving directory

(Fixed the cfe email address) On 12/18/2015 09:34 PM, Tim Northover wrote: > On 18 December 2015 at 19:15, Richard Pennington via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> It turns out that it can with some simple patches. > This sounds really cool. I think we should seriously consider putting > these patches into LLVM mainline. > >> Information on