After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 598572 - wrong wait.h included
wrong wait.h included
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
trunk
Other OpenBSD
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
: 574441 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-10-15 15:04 UTC by Jasper Lievisse Adriaanse
Modified: 2011-05-19 15:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Include correct header (398 bytes, patch)
2009-10-15 15:04 UTC, Jasper Lievisse Adriaanse
none Details | Review
proposed patch (649 bytes, patch)
2009-11-05 18:54 UTC, Alexis Ballier
committed Details | Review

Description Jasper Lievisse Adriaanse 2009-10-15 15:04:18 UTC
Created attachment 145524 [details] [review]
Include correct header

the wrong wait.h file is included by metacity's src/core/main.c on OpenBSD.
attached patch fixes this.
Comment 1 Daniel Macks 2009-10-15 18:16:35 UTC
Does OpenBSD also have <wait.h> (but this situation requires <sys/wait.h> instead), or is the wait.h just in a different location on this platform?
Comment 2 Jasper Lievisse Adriaanse 2009-10-15 18:23:44 UTC
OpenBSD doesn't have <wait.h>. The only wait.h is <sys/wait.h>.
Comment 3 Daniel Macks 2009-10-16 04:46:41 UTC
A more portable solution is to autoconf test for which one exists and use it rather than having to "know" what each platform does specifically. Looks like darwin also appears to use <sys/wait.h> rather than <wait.h>. Probably something like:

configure.in:
+AC_CHECK_HEADERS([wait.h sys/wait.h])

src/core/main.c:
+#ifdef HAVE_WAIT_H
 #include <wait.h>
+#else
+#ifdef HAVE_SYS_WAIT_H
+#include <sys/wait.h>
+#endif
+#endif
Comment 4 Jasper Lievisse Adriaanse 2009-10-16 08:59:46 UTC
That should do the trick :)
Comment 5 paul 2009-10-27 11:06:21 UTC
*** Bug 574441 has been marked as a duplicate of this bug. ***
Comment 6 Alexis Ballier 2009-11-05 18:53:34 UTC
Why do you want such checks? POSIX mandates sys/wait.h and doesnt talk about wait.h at all [1].
On my linux/glibc system, /usr/include/wait.h contains the single line "#include <sys/wait.h>"...


[1] http://www.opengroup.org/onlinepubs/9699919799/basedefs/sys_wait.h.html
Comment 7 Alexis Ballier 2009-11-05 18:54:09 UTC
Created attachment 147030 [details] [review]
proposed patch
Comment 8 paul 2009-11-05 19:19:02 UTC
i thought so too, 7 months ago
Comment 9 Nirbheek Chauhan 2009-12-22 11:06:58 UTC
Are there any problems with the proposed patch by Alexis?

(if not, can we get this trivial patch in please? :)
Comment 10 Romain Perier 2009-12-22 11:23:12 UTC
(In reply to comment #6)
> Why do you want such checks? POSIX mandates sys/wait.h and doesnt talk about
> wait.h at all [1].
> On my linux/glibc system, /usr/include/wait.h contains the single line
> "#include <sys/wait.h>"...
> 
> 
> [1] http://www.opengroup.org/onlinepubs/9699919799/basedefs/sys_wait.h.html

I totally agree, sys/wait.h is POSIX , wait.h not.
Have a look at sys/wait.h :
/*
 *	POSIX Standard: 3.2.1 Wait for Process Termination	<sys/wait.h>
 */

so there is nothing to check or to demonstrate, this is the norm.
Comment 11 Jasper Lievisse Adriaanse 2009-12-22 12:02:31 UTC
Please get this in..
Comment 12 Daniel Macks 2010-02-23 02:49:00 UTC
ping? Any metacity developers alive?
Comment 13 Jasper Lievisse Adriaanse 2010-10-01 07:40:16 UTC
What's delaying this?
Comment 14 Jasper Lievisse Adriaanse 2011-05-18 17:45:33 UTC
So, both metacity and it's developers have left the building? No activity in more than a year on this trivial fix?
Comment 15 Colin Walters 2011-05-19 15:58:45 UTC
Just for future reference, when dealing with portability issues, the first thing to check in GNOME is:  

  What Would GLib Do?

glib/gspawn.c just has:

#include <sys/wait.h>

So this is clearly right.