Arch Linux User Repository

And after setting up a LLVM/lld/clang/libc++ based cross-toolchain plus additional packaging for the Windows/ARM target I kind of doubt that we need osxcross at all. What prevents one from simply downloading the SDK from somewhere (which one needs to do anyway) and then setting up wrappers for clang and other tooling to pass the correct flags for targeting MacOS? It worked for Windows. We'd also had to build the compiler runtime and libc++ but that shouldn't be a big deal. (I suppose on MacOS one is supposed to link against the system provided libc++ so I suppose we'd only build it for the sake of header files.)

Don't expect any help from me at this point. I can incorporate changes if you can come up with concrete fixes or leave the package to a different maintainer if that's wanted.

hello

/usr/bin/ld: otool-arm_disasm.o (symbol from plugin): in function `create_arm_llvm_disassembler':
(.text+0x0): multiple definition of `dis_info'; otool-i386_disasm.o (symbol from plugin):(.text+0x0): first defined here
/usr/bin/ld: otool-arm64_disasm.o (symbol from plugin): in function `create_arm64_llvm_disassembler':
(.text+0x0): multiple definition of `dis_info'; otool-i386_disasm.o (symbol from plugin):(.text+0x0): first defined here
/usr/bin/ld: /tmp/lto-llvm-61b364.o: in function `print_bitcode_section':
ld-temp.o:(.text.print_bitcode_section+0x48c): warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'

At this point libc++ is simply an official package. So of course you won't run into that build error anymore.

I'm currently focusing on Android and Windows/ARM cross packaging. So this package is not really updated anymore. If someone can share an updated version of this package, please do so. I can make you co-maintainer if the changes make sense.

Note that it makes probably no sense to make this package depend on libc++ built for Linux. I only used that as a hack to easily get the required headers without following the recommended steps as they'd required to get an Apple developer account. I suppose I would now try to make a distinct build of libc++ for the actual cross target. I've already recently did that for Windows/ARM and it is actually not a big deal.

The build issue seems to be fixed on the current version

@alx365 libc++ is also an AUR package.

fails to build with following message:

[sudo] password for legendofmiracles: 
error: target not found: libc++
==> ERROR: 'pacman' failed to install missing dependencies.
==> Missing dependencies:
  -> libc++
==> ERROR: Could not resolve all dependencies.

I have updated this to a later commit and the MacOSX SDK 10.13. This was the latest SDK I was able to find. Updating the SDK is likely necessary to build the latest version of Qt.

I did not find any place which allows one to download XCode without Apple login. So instead of running the packaging scripts of osxcross I'm just copying over the header files from the libc++ package. I hope this breaks not everything.

Because I haven't had a good experience with it I removed the GCC build. Providing GCC as a separate package would make more sense anyways.

So far I only tested my simple c++utilities library which is using CMake and C++17. It worked quite well beside having to disable features relying on std::filesystem.

Like in the previous version executables are located under /opt/osxcross/bin. Additionally, it now uses dynamic libraries so one also needs to make sure ld.so finds them. The following exports should do it:

export PATH="/opt/osxcross/bin:$PATH"
export LD_LIBRARY_PATH="/opt/osxcross/lib"

Because the package has been flagged: There are still TODOs that I haven't tackled yet: https://github.com/Martchus/PKGBUILDs/issues/44#issuecomment-351698312

But since my Syncthing Tray application saw some Mac OS fixes lately I'm actually looking forward to proceed with that apple-darwin packages. It will just take a little bit more time.