Processing of port openmpi-gcc7 failed

[ogourgue (Olivier Gourgue)]

I reinstall macports for high sierra, and I'm reinstalling ports one by one. It works fine for most of them, but not for openmpi. I tried with openmpi-gcc7 and openmpi-gcc6, and the same issue arises.

[ogourgue (Olivier Gourgue)]

log file

[mf2k (Frank Schima)]

In the future, please Cc the port maintainers (port info --maintainers openmpi-gcc7), if any.

[aivazis (Michael Aivazis)]

the problem is caused by an incorrectly configured access to syslog.

syslog.h fails to compile during configuration, leaving HAVE_SYSLOG set to 1, without HAVE_SYSLOG_H, which causes LOG_PRI and its sisters to be undefined.

the following fails to compile with gcc(6|7) on high sierra:

// include the problem
#include <syslog.h>

// entry point
int main() {
    // all done
    return 0;
}

[aivazis (Michael Aivazis)]

Looking further, it looks like an APPLE problem: the decoration of the syslog function in </usr/include/sys/syslog.h> places the attribute decorations BEFORE the asm specification, which gcc does not support; see

​https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html

[aivazis (Michael Aivazis)]

Further verified that after repairing the syslog() declaration in /usr/include/sys/syslog.def, the port compiles and installs correctly. Fixing this will have to wait for an update to the command line compiler tools from APPLE. Submitted bug report 34872007

[tdouilletgrellier]

I am having the same problem. Is is possible to explain a bit more how to "repair the syslog() declaration" so I can make it work while waiting for Apple to update the command line compiler tools ? Thanks.

[aivazis (Michael Aivazis)]

corrected /usr/include/sys/syslog.h

[aivazis (Michael Aivazis)]

I have attached the repaired “/usr/include/sys/syslog.h”

The relevant section is the declaration of void syslog(…) near the bottom, where the decorations that follow the function signature appear in the corrected order. You want to diff it with yours to verify that you have identified the correct portion of the file.

“Repairing” is somewhat tricky: the /usr filesystem is mounted read-only and cannot be modified while the machine is in multi-user mode. You have to reboot, and hold command-r to enter rescue mode, open a terminal, and navigate to /Volumes/xxx/usr/include/sys where this file lives. Don’t confuse it with /usr/include/syslog.h: this is /usr/include/sys/syslog.h. What I did is edit the file by hand; it seems to be the best option. Save and reboot normally. You should be good to go.

[tdouilletgrellier]

It worked perfectly (and it fixes also the same issue for the port openmpi-gcc5).

Thank you again.

[SigneRiemer (Signe Riemer-Sørensen)]

I cannot navigate to /Volumes/xxx/usr/include/sys in rescue mode. No problem in normal mode, but then of course syslog.h is read-only. In rescue mode the only option under /Volumes/ is OS X Base System for which the usr directory doesn't have any include or sys subdirectories... Any suggestions?

[aivazis (Michael Aivazis)]

on my system and in rescue mode, /Volumes has two folders: "OS X Base System" and "osx", the latter being what I have renamed the volume with the running version of the system. could you please run "ls -la" in /Volumes when in rescue mode and show me what you get?

[rieder (Steven Rieder)]

As of the most recent update (macOS 10.13.2 and corresponding Xcode / Command Line Tools 9.2 updates), this remains unfixed... Any update from Apple?

[seanfarley (Sean Farley)]

Damn, I just verified this. Is there a radar for this yet?

[rieder (Steven Rieder)]

How is this resolved as 'fixed'? It is definitely still broken on my system...

[seanfarley (Sean Farley)]

Oops! I accidentally changed the status when trying to reply.

[aivazis (Michael Aivazis)]

i have submitted multiple requests for a status update on my bug report to apple. no news yet, despite two updates to the command line tools package

[rieder (Steven Rieder)]

Following the suggestion on ​https://discussions.apple.com/thread/8127677, adding

configure.optflags-append   -mmacosx-version-min=10.12

to the portfile as a workaround makes it compile for me.

[rieder (Steven Rieder)]

Would this be an acceptable workaround for the portfile? I'm not aware of any negative consequences this optflag may have.

Replying to rieder:

Following the suggestion on ​https://discussions.apple.com/thread/8127677, adding

configure.optflags-append   -mmacosx-version-min=10.12

to the portfile as a workaround makes it compile for me.

[seanfarley (Sean Farley)]

I don't have another machine to test this on but does this bug only happen on High Sierra? Or is it the version of Xcode (meaning it affects Sierra as well)?

[Athius (Romain LEGUAY)]

I have the same issue with openmpi-devel-gcc6 and openmpi-devel-gcc7.

I'm also on High Sierra.

I try to apply the "fixed" syslog.h but no change.

[mf2k (Frank Schima)]

@seanfarley: It builds fine for me on Sierra with Xcode 9.2. So it appears to be a High Sierra issue.

[Athius (Romain LEGUAY)]

I just find a fix using the gcc option -mmacosx-version-min=10.12 (from ​https://discussions.apple.com/thread/8127677)

[kencu (Ken)]

so it appears to be this new definition here in syslog.h

#if defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) && __DARWIN_C_LEVEL >= __DARWIN_C_FULL
void	syslog(int, const char *, ...) __printflike(2, 3) __not_tail_called __DARWIN_ALIAS_STARTING(__MAC_10_13, __IPHONE_NA, __DARWIN_EXTSN(syslog));
#else
void	syslog(int, const char *, ...) __printflike(2, 3) __not_tail_called;
#endif

gcc accepts the call if the test sends it to the second definition. I think the mmacosx-version-min=10.12 makes the first definition work by affecting that DARWIN_ALIAS_STARTING macro.

I assume there is some reason Apple did that. They did it on purpose.

we could add mmacosx-version-min=10.12 to the optflags --- not really an optimization flag, though, is it? So that feels a bit off.

Perhaps we just change the configure.macosx_deployment_target to 10.12 when building on high sierra and newer.

Is there something that needs to be written into the wrappers as well?

I suppose this is only needed on the gcc subports -- I'll test an openmpi-clang build and see.

Also -- this would affect anything build with gcc that uses syslog.h, I suppose, not just openmpi.

[kencu (Ken)]

As expected, openmpi-clang installs on high sierra without any trouble at all. No doubt all the clang subports will work too.

[aivazis (Michael Aivazis)]

The cause of the problem is systemic: the system header file uses syntax that is explicitly not allowed by gcc. The offending syntax is exposed only on High Sierra thanks to an ifdef. The only correct fix is to adjust the header file. Any other solution will need to be repeated for each port that uses the syslog facility, as they will all fail to compile with gcc.

This is a bug, not something done on purpose. It is actually a silly bug on their part. It's hard to imagine that they don't run their test suites with gcc, as well as their now default compiler. Apple has already announced a fix in the upcoming high sierra update. So this problem is days from going away for good.

[kencu (Ken)]

Looks like we can just ignore this ticket then and close it when the new headers come out. I'll stop allocating it cycles.

[rieder (Steven Rieder)]

Replying to aivazis:

Apple has already announced a fix in the upcoming high sierra update. So this problem is days from going away for good.

Oh, that's great to hear. The fix will be in the 10.13.3 command line compiler tools update?

[kencu (Ken)]

So they did. I see that in the new syslog.h header for Xcode 9.3, they reversed the macros. So once that rolls out to the wild, this error will be fixed.

[rieder (Steven Rieder)]

Is there any news on when Xcode 9.3 will be released?

[seanfarley (Sean Farley)]

Looks like Xcode 9.3 is finally out!