On Apr 04, 2014, at 01:03, Ryan Schmidt wrote:

> 
> On Apr 3, 2014, at 17:51, René J.V. Bertin <[email protected]> wrote:
> 
>> On Apr 04, 2014, at 00:33, Ryan Schmidt wrote:
>>>> 
>>>> What are the options here? I'm a bit amazed that this flag wasn't passed 
>>>> in earlier dbus versions, as it's been around since Linux kernel 2.6.23 …
>>> 
>>> IIRC, O_CLOEXEC was added to OS X in 10.7. Please report the problem to the 
>>> developers of dbus so that they can provide a workaround for earlier 
>>> systems that don’t have it. I recently had to do that for glib2 as well and 
>>> they were quick to add that support.
>> 
>> Will do... In the mean time I created a patch that removes the offending 
>> flag and allows the build to succeed. We'll see if that leads to problems!

It took a while, but I got a reaction to my bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=77032#c1


There doesn't appear to be much enthusiasm to take initiatives tackling the 
issue; lacking a maintainer it'd be up to someone (else ... us?) to propose a 
patch. Apparently one had already been proposed for *BSD, along the lines of

-          fd = open (new_dirs[i], O_RDONLY);
+#ifdef O_CLOEXEC
+          fd = open (new_dirs[i], O_RDONLY | O_CLOEXEC);
+
+          if (retval < 0 && errno == EINVAL)
+#endif
+            fd = open (new_dirs[i], O_RDONLY);
+
+          _dbus_fd_set_close_on_exec (fd);

but not been included, probably because of lack of demand.


R.
_______________________________________________
macports-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-users

Reply via email to