A couple of platform compatibility issues...

Greg Schafer gschafer at zip.com.au
Sun Jan 5 15:55:37 PST 2003

On Sun, Jan 05, 2003 at 05:23:50PM +0000, Richard Lightman wrote:
> Defining _REENTRANT is unlikely to do any harm, and also unlikely
> to do any good - unless you are getting warnings like getlogin_r
> is used without a protoype or getlogin_r defined twice.

Ok, thanks Richard for the explantion. Sorta confirms what I suspected but I
wasn't sure.

> > I'm sure I read somewhere that pretty much all GNU software should be
> > compiled with -D_GNU_SOURCE. I think I even did some investigations and
> > noted that only a few of the source files in findutils define _GNU_SOURCE.
> > So again, no objections from me.
> >
> The feature test macros like _GNU_SOURCE change the default behaviour
> when a signall arrives during a system call. See:
> info '(libc)Interrupted Primitives'
> For this reason we should only be setting _GNU_SOURCE if the source
> code expects that the default behaviour for an interrupted system
> call is to retry.
> _GNU_SOURCE adds extra (non-standard) features to the library. If you
> use these features, you must ensure that _GNU_SOURCE is defined before
> any system header is loaded. The documentation for glibc-2.2.5
> recommends defining the macro at the head of each source file. This is
> totally impractical because flex generates includes for system headers
> before any of your code. Older versions of the glibc documents gave
> dire warnings of subtle erratic bugs if you defined _GNU_SOURCE
> inconsistently.
> If you are going to use _GNU_SOURCE in your own software , it should
> be on the preprocessor command line either as -D_GNU_SOURCE, or
> -include some_config_file_that_defines_GNU_SOURCE.h
> For other people's software, I recommend you leave it alone unless
> it is broken.

I also did some grepping in the glibc source and it turned up some nice
references worth reading. Thanks.

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list