I am using the function statfs64 to obtain the mount point from a path on macOS via property f_mntonname.
This works fine when building against the SDK 10.x for the architecture x86_64.
However, when building for arm64 (and SDK 11), the method is not available.
I can use statfs as fallback which seems to be available, but this has limits to the path length.
I know there is the NSFileManager-API (attributesOfFileSystemForPath), but unfortunately there is no property for the mount path.
Does anyone know how to to this on the new SDK/Platform?
Thank you and regards,
Dominik
statfs64 and fstatfs64 have been deprecated since macOS 10.6 in favour of "versioned symbols".
If you're building for macOS 10.6 or higher, simply switch to statfs and fstatfs, and add this at the top of your source files (before the includes):
#define _DARWIN_USE_64_BIT_INODE
Or add a compiler flag, if changing many source files is too tedious:
-D_DARWIN_USE_64_BIT_INODE
For arm64 targets, this is already set, so it has no effect.
For x86_64 targets, this causes the linker to emit a dependency on _statfs$INODE64 (which is equivalent to _statfs64) rather than _statfs.
If your x86_64 slice does indeed need to support macOS 10.5, then you'll have to resort to some preprocessing:
#define _DARWIN_USE_64_BIT_INODE
#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 1060
#define STATFS statfs64
#define FSTATFS fstatfs64
#else
#define STATFS statfs
#define FSTATFS fstatfs
#endif
And if you need to support macOS 10.4 or lower, you're out of luck anyway because there is no 64-bit inode support back there.
Related
I have a compilation error on macOS v11 (Big Sur) with the standard Clang compiler (version 13.0.0).
I am trying to include the sys/sysmacros.h to use the makedev() function which surprisingly is mentioned on the Apple developer website and should be compatible with macOS 15.5+.
Including sys/types.h also gives me an error, however sys/stat.h works. Sadly it still doesn't give me the makedev(), major() and minor() functions that I need.
The Linux manual page of makedev states there were some changes in the glibc library, but as far as I know, macOS does not use the glibc library.
There should be a simple way of installing glibc on macOS using Homebrew (brew) as described here, but I get the same error as was mentioned in this question. So apparently currently there is no proper way of doing it and then I am not sure if this will solve my problem.
Is there a solution to this?
The macro makedev is defined in sys/types.h. Just add #include <sys/types.h> into your files. sys/types.h is a header file of Kernel.framework. You should set it in the Clang invocation, like clang -framework Kernel ....
You can also define these macros as they are defined in sys/types.h:
#define major(x) ((int32_t)(((u_int32_t)(x) >> 24) & 0xff))
#define minor(x) ((int32_t)((x) & 0xffffff))
#define makedev(x, y) ((dev_t)(((x) << 24) | (y)))
i want to use #ifdef __MAC_10_12 to detect that the current os version is 10.12, but the header file Availability.h doesn't have this define, the highest version for that file is #define __MAC_10_11_4 101104
So how can i do this right now?
I'm working on an embedded project which will be using an arm7-a (armhf) system on a chip running Debian Jessie.
This system includes GCC/G++ 4.9.2, which should be fully C++11 compatible.
However, I'm seeing issues like, std::mutex and std::condition_variable not being present in the std namespace. I believe this is because the _GLIBCXX_HAS_GTHREADS macro isn't defined. I've found this to be the case whether I pass -std=gnu++0x or -std=c++11.
Does anybody know if this is expected behaviour on this platform?
After I declared a variable in this way:
#include <thread>
namespace thread_space
{
thread_local int s;
} //etc.
i tried to compile my code using 'g++ -std=c++0x -pthread [sourcefile]'. I get the following error:
example.C:6:8: error: thread-local storage is unsupported for the current target
static thread_local int s;
^
1 error generated.
If i try to compile the same code on Linux with GCC 4.8.1 whit the same flags, i get a functioning executable file. I'm using clang-503.0.40 (the one which comes with Xcode 5.1.1) on a MacBook Pro running OSX 10.9.3. Can anybody explain me what i'm doing wrong?
Thank you!!
Try clang++ -stdlib=libc++ -std=c++11. OS X's outdated libstdc++ doesn't support TLS.
Edit
Ok, this works for the normal clang version but not for the Xcode one.
I did a diff against Apple's clang (503.0.38) and the normal released one and found the following difference:
.Case("cxx_thread_local",
- LangOpts.CPlusPlus11 && PP.getTargetInfo().isTLSSupported() &&
- !PP.getTargetInfo().getTriple().isOSDarwin())
+ LangOpts.CPlusPlus11 && PP.getTargetInfo().isTLSSupported())
So I think this is a bug in Apple's clang version (or they kept it in there on purpose - but still weird, because -v says based on 3.4).
Alternatively, you can use compiler extensions such as __thread (GCC/Clang) or __declspec(thread) (Visual Studio).
Wrap it in a macro and you can easily port your code across different compilers and language versions:
#if HAS_CXX11_THREAD_LOCAL
#define ATTRIBUTE_TLS thread_local
#elif defined (__GNUC__)
#define ATTRIBUTE_TLS __thread
#elif defined (_MSC_VER)
#define ATTRIBUTE_TLS __declspec(thread)
#else // !C++11 && !__GNUC__ && !_MSC_VER
#error "Define a thread local storage qualifier for your compiler/platform!"
#endif
...
ATTRIBUTE_TLS static unsigned int tls_int;
The clang compiler included in the Xcode 8 Beta and GM releases supports the C++11 thread_local keyword with both -std=c++11 and -std=c++14 (as well as the GCC variants).
Earlier versions of Xcode apparently supported C-style thread local storage using the keywords __thread or _Thread_local, according to the WWDC 2016 video "What's New in LLVM" (see the discussion beginning at 5:50).
Seems like you might need to set the minimum OS X version you target to 10.7 or higher.
OS X 10.6.8, XCode 3.2.6, Base SDK 10.5, Intel Compiler 11.1
I am getting a weird message when I try to compile that says:
catastrophic error: could not open source file "stdarg.h"
I am using a PCH, I did find: Xcode Intel compiler icc cannot find #include <algorithm>
which is a similar issue and I think that the source file type is set to .c.c instead of .c
From what I can see stdarg.h is:
/* This file is public domain. */
/* GCC uses its own copy of this header */
#if defined(__GNUC__)
#include_next <stdarg.h>
#elif defined(__MWERKS__)
#include "mw_stdarg.h"
#else
#error "This header only supports __MWERKS__."
#endif
so must be GNUC is defined, obviously.
Can anyone help me figure out how to better compile since this works without changes in GCC 4.0? Is there a global way one might have XCode re-evaluate the source file type to not be .c.c or .cpp.cpp I am not even sure how this would happen.
Also, is there a #define that I can check to see if the Intel compilers are being used to make special cases if I need to?
I looked at a few of the files referenced in the build results and looking at the source file type in XCode it says source.c.c and I think if I change that to source.c that compiler error goes away.