Opened 9 years ago

Closed 4 years ago

Last modified 5 weeks ago

#11818 closed bug (no change required)

Posix __USE_GNU vs _GNU_SOURCE

Reported by: kallisti5 Owned by: nobody
Priority: normal Milestone:
Component: System/libroot.so Version: R1/Development
Keywords: posix Cc:
Blocked By: Blocking:
Platform: All

Description

we seem to be all over the map on our GNU posix extension macros...

/Builds/haiku/headers/posix> grep -R __USE_GNU *
regex.h:#ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
regex.h:# ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
signal.h:#ifdef __USE_GNU
/Builds/haiku/headers/posix> grep -R __USE_GNU *^C
/Builds/haiku/headers/posix> grep -R "_GNU_SOURCE" *
stdio.h:#ifdef _GNU_SOURCE
stdio.h:#endif /*_GNU_SOURCE*/
string.h:#ifdef _GNU_SOURCE
string.h:#ifdef _GNU_SOURCE
wchar.h:#ifdef _GNU_SOURCE
wchar.h:#ifdef _GNU_SOURCE

Our libroot tests also reflect the confusion as they were mixed and some broken.

I think _GNU_SOURCE is the correct way to go... not sure however so I'm opening this for someone smarter than me :-)

Change History (6)

comment:1 by axeld, 7 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:2 by cocobean, 5 years ago

Reference:

  1. https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
  2. #define  _GNU_SOURCE    1 /* for strsignal in GNU's libc */
    #define  __USE_GNU      1 /* exact same thing as above   */
    #define  __EXTENSIONS__ 1 /* and another way to call for it */
    
Version 1, edited 5 years ago by cocobean (previous) (next) (diff)

comment:3 by pulkomandy, 5 years ago

The way it work in glibc is that the user defines _GNU_SOURCE, and features.h defines __USE_GNU and other __USE_* stuff.

Our public features.h works differently, as I don't think the internal __USE_* defines are very useful and they are confusing to track. So when taking headers from glibc and making them public, we have to be careful about this.

I would leave these as is for now unless there are problems compiling things because of this? The BSD extensions that we have in libbsd are quite useful, but the things glibc adds or goes against POSIX for, I'm not so sure.

comment:4 by waddlesplash, 4 years ago

Resolution: no change required
Status: assignedclosed

comment:5 by nielx, 4 years ago

Milestone: R1

Remove milestone for tickets with status = closed and resolution != fixed

comment:7 by bipolar, 4 months ago

Not sure if I should open a new/different ticket, maybe the following is enough to re-open this one? (considering the "I would leave these as is for now unless there are problems compiling things because of this?" on an earlier comment here)...

I had some problems compiling TraX, in part due to __USE_GNU vs apparently, some issues with Haiku's features.h

Link to the discussion there: https://github.com/HaikuArchives/TraX/pull/4#pullrequestreview-1625900739

Hoping a real dev either fixes this before beta5, or someone just merges my sub-optimal TraX fixes in the meantime :-)

---

Edit: Just for future reference... hrev57485 (and the follow up fixes on hrev57497) fixed TraX's issue mentioned above.

Last edited 5 weeks ago by bipolar (previous) (diff)
Note: See TracTickets for help on using tickets.