There seems to be a conflict between the version of zlib used in the SDK and what may exist on a user's machine. For example...
On macOS 10.11.6 and Xcode 8, the version of zlib used during compilation doesn't match the version of libz.dylib loaded at runtime. Specifically, the header file used during compilation is for zlib v1.2.8, but the dylib file loaded at runtime is for 1.2.5.
This can result is a runtime crash because it can attempt calling a function that doesn't exist in 1.2.5. The problem is the header (from the SDK) thinks we are using 1.2.8 so it will compile code that is 1.2.8-specific based on any #if defined for a version check.
What then is the best way to link against and use zlib?
Should I compile it as a static lib and ignore the OS supplied version? I am currently doing that and using 1.2.8 in my app, but it may be causing a problem for a user on 10.14.3. I am considering switching to a dynamic lib, but the above situation comes into play there too.
Related
My app uses a couple of third-party dynamic libs, which I include in my app package. But what about the system libs that my own code and third-party libs depend on?
Examples include
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
/usr/lib/libSystem.B.dylib
Should I bundle these and update their reference paths in all caller binaries of the app package?
If I must, should I create app binaries for each macOS version?
My thinking is that I shouldn't force my users to install Xcode, but I'm not sure if those system frameworks and dynamic libs are bundled with OS or installed through Xcode ...
The system libs are guarantee to run on any system your application supports (and naturally they are installed on any Mac since the system itself uses them). Therefore, no, you don't have to bundle these libs. Instead you have to carefully decide from which version of the OS your codes are prepared to support this or that version of a lib.
When a piece of code needs to be handled differently for different versions of the lib at runtime, you can use such form to synchronize your codes with the current environment :
if (#available(macOS 10.14, *)) {
//codes supporting any system since 10.14
} else {
//codes supporting earlier systems
}
You must not bundle these. Anything in /System or /usr/lib is part of the operating system, not Xcode. They are not intended to be copied to other systems.
I am using macOS 10.15 and Xcode11.1 to do my OpenGL project. However, Xcode cannot build the program as errors was detected and the program crashed. It states:
dyld: Library not loaded: #rcpath/libGLEW.2.1.dylib
Referenced from:#rcpath/Xcode/DerivedData/GLFW_opengl-digmcjjsxnhrabepersfaxavutvh/Build/Products/Debug/GLFW opengl
Reason: no suitable image found.
Did find: /usr/local/opt/glew/lib/libGLEW.2.1.dylib:
code signature in (/usr/local/opt/glew/lib/libGLEW.2.1.dylib) not valid for use in process using Library Validation:
mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.
I have followed many tutorials online, brew installed the libraries and finished all the settings both in the Header search paths and Linked Binaries with Library. But it also fails to build.
What should I do?
Seems like your libGLEW is not code signed. Since MacOS Catalina, the code has to be at least ac-hoc signed.
You might download the newest version of libGLEW here and see if it fixes. If that didn't help, you can compile it from source. After that, all you have to do is replace your old libGLEW.dylib with the new one.
I develop a utility in Go that requires recent version of sqlite. I'm interested only in targeting specific architecture, to be specific: x64 linux. I'm developing that utility on Mac OS X. I'm using go-sqlite3 driver. I use GNU Make + Glide to build my utility. In order to cross compile on my Mac I pass specific arch flags to make.
Repos on Linux platforms that I'm targeting usually have quite old versions of sqlite that don't have features that I need in my utility.
I can manually compile and install required version of sqlite on all the platforms that I need, but it is quite cumbersome. I wonder if there is a good way to either statically link a specific version of sqlite or somehow bundle a utility with specific version of sqlite dynamic library.
Even though I mention sqlite a lot, this question can be generalized to other libraries: how to bundle a golang app with a specific version of C library an outdated version of which may be installed on the target platform.
Also: how to better organize development of that utility so that other devs won't need to manually compile and install specific version of the library - the preference is to use Makefile that would build all the binaries for required target platform. I see that I can just copy code of specific version of library (e.g. sqlite) to my utility's repo though I wonder if there is a better option - maybe I can somehow use glide dependencies for that purpose and build library that I need as part of my other dependencies.
I have a serious issue getting Xcode 7.3 to compile a Project against Mac SDK 10.7 with LLVM (7+) and C++11. The source of the issue seems to be Xcode or the fact that I'm running OS X 10.11. Some colleagues of mine don't have the same issue compiling the same issue with older Xcode Versions (6). Here is the general setup:
The needed Libraries and Headers are linked with CMake. The Include paths of everything got checked multiple times. The created Xcode Project also seems to be ok, we've compared all important settings (C++ dialect, std library , target, defines etc) against systems where the project does compile.
The actual error comes when compiling vecLib source.It seems to be a set of random error messages I would trace back to the lack of c++ std headers.. Here are a few examples:
Explicite specialization of non-template class 'complex'
Redifinition of complex as different kind of symbol
Did anybody run into similar problems when working with newer Xcodes against older SDKs?
EDIT
Here is some more informations. After checking what was behind the redifinition, I found that for some odd reason, the complex definition that was interfering with the forward declaration in the file comes from /usr/include/c++/4.2.1. I think that the header is outdated or at least not compatible with c++11. I checked again what the compiler used and the lib / language (std=c++11 and stdlib=libc++) where correctly set. I have the strange feeling that the source in user/include isn't supposed to be included but I don't know how to fix it.
EDIT 2
I've checked the standard include paths with cpp -v and got the following list:
/usr/local/include
/Applications/XCode/.../XCodeDefault.xtoolchain/usr/bin/../lib/clang/7.3.0/include
/Applications/XCode/.../XCodeDefault.xtoolchain/usr/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
The definition of complex in the Xcode toolchain (3rd entry) is the correct one, the definition in /usr/include is the one that seems to be used while compiling, leading to the error messages. The definition of complex uses structs.
What is the issue here? Is the issue that Xcode / Clang or what ever decides to go with usr/include instead of the toolchain include? I've checked the project settings and the compiler output and there was no explicit include of this path.
It seems like AppleClang 7+ and libc++ just doesn't support vecLib from OS X SDK 10.7. I had to go back to Xcode 6 to get it to build.
I'm writing an application in which I want to use free image to load files. I am on MacOSX 10.8.2 and I am using the mac ports version of free image. I had it working, but when I tried putting it on another computer without the port, it wouldn't run because it didn't have the files. The macports version comes with a dylib, can I use that to run it without downloading the port? If I can how would I compile it with the project because I have tried linking it as a Binary Library, but I can't include the files. Any help would be appreciated, as I have bee at this for a few hours now.
Thanks
You can actually build the FreeImage library as a static library. Unfortunately, the downloadable source from the http://freeimage.sourceforge.net/download.html website uses makefiles that are expecting to use the older SDKs for Xcode3.
I actually updated the Makefile.osx to build with Xcode4 using the 10.7 SDK and posted the change to https://gist.github.com/AhiyaHiya/5105571
You should be able to run this make from Terminal.app and create your .dylib and .a files for your needs.