* Lennart Poettering <[email protected]> [2010-03-09 19:56:18]:
> On Tue, 09.03.10 22:12, Balbir Singh ([email protected]) wrote:
>
> > * Lennart Poettering <[email protected]> [2010-03-09 16:58:12]:
>
> > > libcg is Linux-specific anyway. AC_USE_SYSTEM_EXTENSIONS enables the
> > > full Linux API. Every single API call there is on Linux. And for
> > > something that is Linux-specific anyway, this should be the exact right
> > > thing to do.
> > >
> >
> > There is no bloat due to header expansion, namespace collision issues,
> > etc? Does it make sense to enable things like _TANDEM_SOURCE, etc?
>
> No. There should not be a problem with that. those #ifdefs are nops on
> Linux. Thre should not be any namespace issues. And if there were it
> should be left to the autoconf folks to fix them so that A_U_S_E can be
> used without headache. Also, an #ifdef like this does not influence in
> any way how you link your stuff, so it should have exactly no runtime
> effect.
>
> If you really are concerned about issues like this, as least use the
> older AC_GNU_SOURCE, wich sets _GNU_SOURCE only. But then again, I'd
> always go for A_U_S_E simply because I wouldn't want to create the
> impression that anything of this was really specific to glibc. Because
> it isn't. it is specific to Linux.
>
OK, fair enough
> And for weirdos who want to link your libs against non-glibc libc's it
> might be quite handy if your code isn't bound to GNU, but simply to the
> functions you actually need. If you understand what I mean.
>
Yep, I do, linking against non-glibc is a good use case. I am all for
moving _GNU_SOURCE from the header.
--
Three Cheers,
Balbir
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Libcg-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libcg-devel
