Bug 103521

Summary: ../build-aux/install-sh: invalid option: -m700 build failure on macOS
Product: dbus Reporter: ilovezfs
Component: coreAssignee: D-Bus Maintainers <dbus>
Status: RESOLVED FIXED QA Contact: D-Bus Maintainers <dbus>
Severity: normal    
Priority: medium Keywords: patch
Version: git master   
Hardware: All   
OS: Mac OS X (All)   
Whiteboard: review+
i915 platform: i915 features:

Description ilovezfs 2017-10-31 06:49:35 UTC
dbus 1.12.0

In test/Makefile.am the following appears:

## copy tests to builddir so that generated tests and static tests
## are all in one place.
all-local: copy-config-local uninstalled-config-local
        $(AM_V_at)$(MKDIR_P) -m700 XDG_RUNTIME_DIR

If GNU coreutils is installed, this does not cause a problem. During configure, dbus selects

checking for a thread-safe mkdir -p... /usr/local/opt/coreutils/libexec/gnubin/mkdir -p

and all is well.

However, if GNU coreutils is not installed, the build fails. During configure, dbus selects

checking for a thread-safe mkdir -p... build-aux/install-sh -c -d

and then make fails with the following error:

../build-aux/install-sh -c -d -m700 XDG_RUNTIME_DIR
../build-aux/install-sh: invalid option: -m700
make[3]: *** [all-local] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

This is because install-sh expects "-m 700" not "-m700"

The bug can be fixed with the following diff:

bash-3.2$ diff -u test/Makefile.am test/Makefile.am.new 
--- test/Makefile.am	2017-10-30 23:34:08.000000000 -0700
+++ test/Makefile.am.new	2017-10-30 23:33:26.000000000 -0700
@@ -543,7 +543,7 @@
 ## copy tests to builddir so that generated tests and static tests
 ## are all in one place.
 all-local: copy-config-local uninstalled-config-local
-	$(AM_V_at)$(MKDIR_P) -m700 XDG_RUNTIME_DIR
+	$(AM_V_at)$(MKDIR_P) -m 700 XDG_RUNTIME_DIR
 
 copy-config-local:
 	$(AM_V_at)$(MKDIR_P) data/valid-config-files/session.d
bash-3.2$
Comment 1 Simon McVittie 2017-10-31 11:45:36 UTC
Thanks, fixed in git for 1.12.2 and 1.13.0. I'm glad to hear 1.12 still mostly works on macOS; does it pass the build-time tests?

For any future patches it would be great if you could commit your changes to a git clone of dbus and attach a patch as produced by the "git format-patch" command, so that it can have proper attribution under your preferred name or pseudonym. For this commit I've assumed that "ilovezfs" is a suitable pseudonym, but I can change how you're credited in NEWS if you'd prefer something different.
Comment 2 ilovezfs 2017-10-31 12:00:18 UTC
>Thanks, fixed in git for 1.12.2 and 1.13.0.

Thanks!

>does it pass the build-time tests?
Yes: https://gist.github.com/ilovezfs/61f85e7096aead4f5cce692bb2715ef3

>For any future patches it would be great if you could commit your changes to a git clone of dbus and attach a patch as produced by the "git format-patch" command, so that it can have proper attribution under your preferred name or pseudonym.

Sure.

>For this commit I've assumed that "ilovezfs" is a suitable pseudonym

Yes: https://github.com/ilovezfs
Comment 3 Simon McVittie 2017-10-31 13:01:27 UTC
(In reply to ilovezfs from comment #2)
> >does it pass the build-time tests?
> Yes: https://gist.github.com/ilovezfs/61f85e7096aead4f5cce692bb2715ef3

The options you're building with there are fine for just having dbus available, but provide really weak test coverage. There are two things you could do to have an early warning of (perhaps OS-specific) dbus bugs on macOS:

* Do a build with GLib available, and ideally also Python, dbus-python and
  PyGI (PyGObject). This adds extra test coverage without affecting the
  installed binaries; it's what I'd recommend OS distributors do, unless
  they are doing a really tightly constrained OS with no GLib. dbus
  itself doesn't require GLib, but we use it for test infrastructure
  because reinventing it would seem like a waste of time.

* Do a build with ./configure --enable-developer. The resulting library
  and binaries are not safe for production use (they're full of extra
  asserts, tests and other clutter) but good for development and testing,
  and in particular they contain the other half of the test suite.

(For full coverage, do both.)

We don't have a dbus maintainer or a regular contributor who uses macOS, so it is quite likely that there are bugs we don't know about.

There are also a few old bugs in limbo because patches can't be tested, because contributed patches haven't been updated in response to reviews, or because we don't know what "shape" macOS takes in terms of OS versions that people want to support, which software distributions (Homebrew/Fink/etc.) are or aren't still relevant, and that sort of thing. If dbus on macOS is important to you and you're able to spend some time helping, I'd be happy to point you towards the right places.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.