On Wed, 2016-02-24 at 09:40 -0600, Ken Gaillot wrote: > On 02/24/2016 06:15 AM, Jan Pokorný wrote: > > > I added this comment to the pull request: > > * The leading null byte in sun_path (the "+ 1" when using it) indicates > an abstract socket (see unix(7)). If Hurd doesn't support those, it'll > need a separate block -- we shouldn't change the behavior for Linux/Cygwin.
Now I see why you use the + 1 in sun_path, thanks. However, the second patch was derived under GNU/Linux, where the sun_path was found to be NULL, as by the comment. It FTBFS without the unlink statement with the second patch. The unpatched code in Debian version 0.17.2.real-4 FTBFS with gcc-4.9.1-16, as written in Debian bug #803766. How is the abstract socket selected in favor of the regular socket in GNU/Linux? > * I don't think the unlink() will make sense with abstract sockets. Same here, the unlink was is needed with the latest gcc: 5.3.1-8 :( Otherwise ipc.test fails. > * Not necessary with this request, but it would be nice if we could have > ./configure define semantic macros like HAVE_ABSTRACT_SOCKET or > something. Or at least #define them ourselves so we don't have to repeat > "defined(...) || ..." all the time. That would definitely be needed, especially if abstract sockets are not used in GNU/Linux, as I probably experienced, see above. _______________________________________________ Developers mailing list [email protected] http://clusterlabs.org/mailman/listinfo/developers
