Date: Sat, 25 Aug 2012 23:29:44 +0800 From: orc <orc@...server.ru> To: musl@...ts.openwall.com Subject: Re: Best bikeshed ever (feature test macros) On Sat, 25 Aug 2012 08:32:15 -0400 Rich Felker <dalias@...ifal.cx> wrote: > On Sat, Aug 25, 2012 at 03:35:56PM +0800, orc wrote: > > Will exposing everything by default enlarge program size by > > including unneeded symbols? > > The only way this could happen is if the newly exposed portions of the > headers include static inline functions and the compiler decides to > generate code for them even when they're not used. > > The compiler could also increase the size of _debugging_ tables in the > output to include the unused types, etc. but not the size of actual > code. > > > From my point of view, appending -D_GNU_SOURCE everytime when you > > install software on system is painful, but it can be "hidden", for > > Actually it can't; this is the main problem with the current approach. > Unconditionally adding -D_GNU_SOURCE to CFLAGS for all programs > "fixes" most programs that should be using it themselves, but breaks a > small but nonzero number of fully-correct programs that are using > feature test macros properly to _avoid_ having their namespace > polluted by nonstandard symbols that conflict with their own use of > the corresponding names. > > Thus, before you have build a package, you have to know whether it > makes use of feature test macros on its own. Then I would recommend the #2 way or even to expose everything by default since there is big number of software with their own incompatible build systems, broken build systems like you said about gcc, but there is still problem with ugly ones which logic uses __GNUC__ and similiar macros (but we can omit them now just because they are broken). (Btw how uglier preprocessor logic will become?) > > Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.