Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compiling, perhaps new Xcode problem #182

Closed
gaboentropy opened this Issue Mar 28, 2019 · 13 comments

Comments

Projects
None yet
3 participants
@gaboentropy
Copy link

gaboentropy commented Mar 28, 2019

Expected Behavior

It should compile

Current Behavior

It doesn't compile

Steps to Reproduce (for bugs)

I did (after a "git pull" in my MMseqs2 directory):
CXX="/usr/local/bin/g++-8" CC="/usr/local/bin/gcc-8" cmake -DCMAKE_BUILD_TYPE=RELEASE -DCMAKE_INSTALL_PREFIX=/usr/local/biotools ../MMseqs2
make

MMseqs Output (for bugs)

[ 41%] Building CXX object src/CMakeFiles/mmseqs-framework.dir/commons/Util.cpp.o
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/sysctl.h:83,
from /usr/local/biotools/MMseqs/MMseqs2/src/commons/Util.cpp:15:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/ucred.h:94:2: error: '_Atomic' does not name a type
_Atomic u_long cr_ref; /* reference count */
^~~~~~~
make[2]: *** [src/CMakeFiles/mmseqs-framework.dir/commons/Util.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/mmseqs-framework.dir/all] Error 2
make: *** [all] Error 2

Context

tried in an iMac, and a Mac Pro. Xcode 10.2, and gcc-8 (homebrew).

@milot-mirdita

This comment has been minimized.

Copy link
Member

milot-mirdita commented Mar 28, 2019

Both me and Martin develop on Macs and we didn't really have any issues.
What macOS version are you running? I am not sure where to begin to reproduce the issue.

@gaboentropy

This comment has been minimized.

Copy link
Author

gaboentropy commented Mar 28, 2019

Yep. It's an issue with Xcode 10.2. In another, not updated, iMac, with Xcode 10.1 it compiles all right. :(

@gaboentropy

This comment has been minimized.

Copy link
Author

gaboentropy commented Mar 28, 2019

Both me and Martin develop on Macs and we didn't really have any issues.
What macOS version are you running? I am not sure where to begin to reproduce the issue.

The update happened yesterday (both system and Xcode), and I had the brilliant idea of also installing: /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

To ensure having the /usr/lib and /usr/include directories (from the command-line Xcode tools).
That changed "ucred.h" for a version containing that dreaded "_Atomic" thing, not found in the previous "ucred.h".

@milot-mirdita

This comment has been minimized.

Copy link
Member

milot-mirdita commented Mar 28, 2019

@gaboentropy

This comment has been minimized.

Copy link
Author

gaboentropy commented Mar 28, 2019

Here is some other person having issues with this header:
https://apple.stackexchange.com/questions/355049/compilation-error-with-mojave-error-atomic-does-not-name-a-type

Yep. I saw that. I already have brew gcc, and it doesn't solve the problem. I'd guess that gcc-8 would use its own libraries, but I have not found a way to ignore mac's own libraries yet. At least to ignore that ucred.h thing.

@milot-mirdita

This comment has been minimized.

Copy link
Member

milot-mirdita commented Mar 28, 2019

You could copy the macOS sdk from the other computer and use something like in the following link to not use the broken sdk:
https://stackoverflow.com/questions/10165335/can-cmake-specify-the-base-sdk-on-mac-os-x

sysctl.h is a System Header, any Compiler will have to load that and would not be able to provide its own.

@gaboentropy

This comment has been minimized.

Copy link
Author

gaboentropy commented Mar 28, 2019

Yep. In the meantime I'll compile in the mac with the older system. It's the same model, so that'll have to do.

@gaboentropy

This comment has been minimized.

Copy link
Author

gaboentropy commented Mar 31, 2019

If anybody has this problem, and no older mac systems, mmseqs2 compiles all right with Mac's native clang, instead of gnu's gcc. Some feature must be lost, perhaps multithreading (I don't know if this is so), but it still runs very fast (I know this is so).

@milot-mirdita

This comment has been minimized.

Copy link
Member

milot-mirdita commented Mar 31, 2019

One think you could try is the following (super ugly) hack:

cmake -DCMAKE_CXX_FLAGS="-D_Atomic=volatile" ..

That might fix the issue in GCC.

@gaboentropy

This comment has been minimized.

Copy link
Author

gaboentropy commented Mar 31, 2019

Thanks Milot, that worked.

@milot-mirdita

This comment has been minimized.

Copy link
Member

milot-mirdita commented Apr 2, 2019

Reopening the issue, since Homebrew fails because of it.

@milot-mirdita

This comment has been minimized.

Copy link
Member

milot-mirdita commented Apr 4, 2019

Here is a cleaner solution to the problem.

@gaboentropy

This comment has been minimized.

Copy link
Author

gaboentropy commented Apr 8, 2019

Yep. That worked too. Thanks again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.