|Summary:||../build-aux/install-sh: invalid option: -m700 build failure on macOS|
|Component:||core||Assignee:||D-Bus Maintainers <dbus>|
|Status:||RESOLVED FIXED||QA Contact:||D-Bus Maintainers <dbus>|
|OS:||Mac OS X (All)|
|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: *** [all-local] Error 1 make: *** [all-recursive] Error 1 make: *** [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.