Re: Issue compiling simple code with clang++-mp-11

[Ryan Schmidt]

On May 3, 2021, at 07:14, Andrew Udvare wrote:

> it wasn't until recently that Xcode Clang and MacPorts Clang versions 
> mismatched their highest numbers (Xcode 12.5 having Clang 12, MacPorts having 
> up to 11).

Xcode clang version numbering is completely different from open source clang 
version numbering and has been for many years already. Xcode clang 11 is not 
the same thing as open source clang 11.

Re: Using macports-libcxx to build a non-MacPorts cmake project

[Ken Cunningham]

what you did actually might have worked, I think, ideally… too bad it didn’t.

Can you do this perhaps?

export CXXFLAGS="-nostdinc++ -I/opt/local/include/libcxx/v1” 
export LDFLAGS="-L/opt/local/lib/libcxx"


or maybe this: 

CXX=/path/to/clang-9.0 CXXFLAGS="-nostdinc++ -I/opt/local/include/libcxx/v1”  
LDFLAGS="-L/opt/local/lib/libcxx” cmake ../path/to/source


or maybe:

CXX="/path/to/clang-9.0 -nostdinc++ -I/opt/local/include/libcxx/v1”  
LDFLAGS="-L/opt/local/lib/libcxx” cmake ../path/to/source

I really need to finish that simple shell script that is supposed to set up the 
environment like MacPorts does for you, but I will probably never get around to 
that…

Ken

Using macports-libcxx to build a non-MacPorts cmake project

[wowfunha...@gmail.com]

Hello!

I spent the weekend building a copy of the Dolphin emulator that is compatible 
with OS X 10.9! It mostly works, thanks in no small part to MacPorts's 
excellent legacy-support and clang-11 ports. 
https://forums.dolphin-emu.org/Thread-unofficial-dolphin-built-for-an-older-version-of-macos-os-x-10-9-mavericks

However, I had to remove a couple uses of shared_mutex from Dolphin's code, 
which I think may be leading to some odd freezes when configuring controllers. 
It occurred to me that I might be able to revert those changes (and hopefully 
fix the freezes) by building Dolphin against macports-libcxx.

Dolphin uses cmake, so I added the following to cmakelists.txt:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -nostdinc++")
include_directories(/opt/local/include/libcxx/v1)
link_directories(/opt/local/lib/libcxx)

But Dolphin can't seem to compile this way. I don't know a ton about how C and 
CMake work—am I doing this right?

(I'm also perfectly content to live with what I have—I'm delighted that I got 
Dolphin to work at all—but I wouldn't feel right unless I exhausted all 
possible avenues.)

Thank you!

Re: Issue compiling simple code with clang++-mp-11

[Christopher Jones]

See

https://trac.macports.org/ticket/62770 

Its the macOS11.3 / Xcode 12.5 update, it has broken all MacPorts clang 
versions <= 11

At this time the only macports clang that works is the clang-level port.

Chris

> On 3 May 2021, at 1:14 pm, Andrew Udvare  wrote:
> 
> This code compiles fine with Xcode but fails with Clang from MacPorts. I have 
> not been able to figure out why. I successfully rebuilt Clang and LLVM from 
> source but it made no difference.
> 
> Setup:
> 
> macOS 11.3 20E232 x86_64
> Xcode 12.5 12E262
> 
> The code (main.cpp):
> 
> #include 
> int main(int argc, char *argv[]) {
>  std::filesystem::path p(argv[0]);
>  return p.string().length();
> }
> 
> $ xcrun clang++ -std=c++17 main.cpp
> # No errors
> 
> Anyone know why it would fail with MacPorts' Clang? Seems to be an include 
> path/file issue.
> 
> $ /opt/local/bin/clang++-mp-11 -std=c++17 main.cpp -ferror-limit=2
> In file included from main.cpp:1:
> In file included from 
> /opt/local/libexec/llvm-11/bin/../include/c++/v1/filesystem:234:
> In file included from 
> /opt/local/libexec/llvm-11/bin/../include/c++/v1/cstdlib:85:
> /opt/local/libexec/llvm-11/bin/../include/c++/v1/stdlib.h:142:34: error: 
> unknown type name 'ldiv_t'
> inline _LIBCPP_INLINE_VISIBILITY ldiv_t div(long __x, long __y) _NOEXCEPT {
> ^
> /opt/local/libexec/llvm-11/bin/../include/c++/v1/stdlib.h:143:12: error: no 
> member named 'ldiv' in the global namespace
>  return ::ldiv(__x, __y);
> ~~^
> fatal error: too many errors emitted, stopping now [-ferror-limit=]
> 3 errors generated.
> 
> This generates a lot of errors that are members are missing from the global 
> namespace.
> 
> This affects this port I have had working for a while, probably by accident 
> because it wasn't until recently that Xcode Clang and MacPorts Clang versions 
> mismatched their highest numbers (Xcode 12.5 having Clang 12, MacPorts having 
> up to 11).
> 
> https://github.com/Tatsh/ports/blob/ycm-fixes/devel/ycmd/Portfile
> 
> This project tries to compile this code within CMake to test for required 
> arguments, but it's failing for the reason above rather than actually missing 
> filesystem implementation. See 
> https://github.com/ycm-core/ycmd/blob/master/cpp/ycm/CMakeLists.txt#L279
> 
> -- 
> Andrew Udvare
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Issue compiling simple code with clang++-mp-11

[Andrew Udvare]

This code compiles fine with Xcode but fails with Clang from MacPorts. I have 
not been able to figure out why. I successfully rebuilt Clang and LLVM from 
source but it made no difference.

Setup:

macOS 11.3 20E232 x86_64
Xcode 12.5 12E262

The code (main.cpp):

#include 
int main(int argc, char *argv[]) {
  std::filesystem::path p(argv[0]);
  return p.string().length();
}

 $ xcrun clang++ -std=c++17 main.cpp
# No errors

Anyone know why it would fail with MacPorts' Clang? Seems to be an include 
path/file issue.

 $ /opt/local/bin/clang++-mp-11 -std=c++17 main.cpp -ferror-limit=2
In file included from main.cpp:1:
In file included from 
/opt/local/libexec/llvm-11/bin/../include/c++/v1/filesystem:234:
In file included from 
/opt/local/libexec/llvm-11/bin/../include/c++/v1/cstdlib:85:
/opt/local/libexec/llvm-11/bin/../include/c++/v1/stdlib.h:142:34: error: 
unknown type name 'ldiv_t'
inline _LIBCPP_INLINE_VISIBILITY ldiv_t div(long __x, long __y) _NOEXCEPT {
 ^
/opt/local/libexec/llvm-11/bin/../include/c++/v1/stdlib.h:143:12: error: no 
member named 'ldiv' in the global namespace
  return ::ldiv(__x, __y);
 ~~^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
3 errors generated.

This generates a lot of errors that are members are missing from the global 
namespace.

This affects this port I have had working for a while, probably by accident 
because it wasn't until recently that Xcode Clang and MacPorts Clang versions 
mismatched their highest numbers (Xcode 12.5 having Clang 12, MacPorts having 
up to 11).

https://github.com/Tatsh/ports/blob/ycm-fixes/devel/ycmd/Portfile

This project tries to compile this code within CMake to test for required 
arguments, but it's failing for the reason above rather than actually missing 
filesystem implementation. See 
https://github.com/ycm-core/ycmd/blob/master/cpp/ycm/CMakeLists.txt#L279

-- 
Andrew Udvare