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.
Related
The issue is about linking x86_64 macOS executables statically against libavcodec, libavdevice, etc, which have some object files built against freestanding as they use YASM which isn't able to embed the macOS "tag" in the binary (see Building for macOS, but linking in object file built for free standing for detailed information on that issue).
Everything works fine under Xcode 11.6 - the following messages are here, but they are warnings.
With the Xcode 12 update they become an error.
How to make them warnings again ? I could not find anything relevant in the ld man page.
ld: in ffmpeg/lib/libavcodec.a(aacencdsp.o), building for macOS, but linking in object file built for free standing, for architecture x86_64
There is no option I have found to revert the error to a warning. Apple has been warning us about this issue for a few releases of XCode now and the warning has become an error.
Until NASM is modified, or we can use some other assembler, the only option that allows me to build and link against the libav libraries in my application is to disable assembly when compiling ffmpeg.
./configure --disable-asm
This works my my case, as the performance of the non-assembly code path is acceptable in my desktop authoring tool. The server-based renderer still uses the assembly code path as it is linux based.
You may have to configure any libaries that you are including in your ffmpeg build to also disable assembly.
Once again, this is an acceptable solution for my case, as the non-assembly code paths are fast enough for my use case.
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.
We just wrapped up a game in SFML for Mac and submitted it to the Mac store. We are using SFML 2.0. We're using a standard SFML project in Xcode with the link script that copies over the required frameworks. The game works great on all computers from Mac OSX 10.6-10.9. Trouble is, when we submit to the App Store, we get an email back saying the following:
Malformed Framework - The framework bundle
(Shibashiba.app/Contents/Frameworks/freetype.framework) must contain a
symbolic link 'freetype' -> 'Versions/Current/freetype'. Refer to the
Anatomy of Framework Bundles for more information.
If I go into the Archived application, the freetype.framework folder is in Contents/Frameworks and it has a symbolic link that points to Versions/Current/freetype, so I'm at a loss as to what this error means. Could it be some kind of permissions error? Could the freetype distro included with 2.0 be messed up in some way? Any help would be appreciated. This is our last hurdle to shipping!
I think I figured it out! Basically, the compiled freetype.framework included with SFML is linked incorrectly.
If you look in the folder using Finder, the links look correct, but if you compare it to sndfile.framework, it is different. For example:
sndfile.framework
sndfile -> Versions/Current/sndfile
Versions
A
sndfile
Current -> A
versus
freetype.framework
freetype -> Versions/A/freetype
Versions
A
freetype
Current -> A
You can see above that freetype points DIRECTLY to the "A" version of freetype, whereas in the correct "Anatomy", it should point to Current, which in turn points to the current version.
I changed the symlink and Apple accepted the corrected binary:
cd /Library/Frameworks/freetype.framework
ln -fns Versions/Current/freetype freetype
Okay I've been searching for hours to try and solve this but nothing has worked. This problem is very similar to other posts, but I none of their solutions work.
So I am writing an OpenGL program using glew and glfw and for some reason I am unable to get the program to compile. The error is on the include statement:
#include <GL/glfw.h>
and the error says 'GL.glfw.h' file not found.
I have followed all the instructions on the
GLFW-2.7.8 Release Notes
web page, which includes making glfw, and then importing the static library libglfw.a into Xcode. The library does show up under Build Phases -> Link Binary with Libraries, but apart from that Xcode doesn't seem to recognize it. For example, under the File Inspector it detects the file type as "Default - data".
The static library is configured for 64-bit architecture, which I am running.
I have tried changing the search paths under Build Settings.
I have the following frameworks included: Cocoa, OpenGL, and IOKit.
Please let me know if there is any more information you need to help me solve this problem and thank you for reading.
It turns out my glew was not importing correctly and so glfw did not work either.
These are the steps I took:
Changed the Base SDK from Latest OSX (10.8) to Current OSX.
After doing this, I "reduced" the error to an Apple Mach-O Linker (Id) error. Next:
Added -lGLEW to Other Linker Flags.
Added /opt/local/include/ to the header search paths
Added /opt/local/lib/ to the library search paths
Here is where I found my answer.
so first off, I want to say that this question:
Bundle framework with application in XCode
and this question:
OSX: changing path of .framework
were both extremely helpful getting me up to this point, but I'm still not quite there.
So, like both the Original Posters for the two previous questions, I'm trying to embed a framework inside my app bundle. Or, rather, the issue is that I'm trying to embed MULTIPLE frameworks in my app bundle, some of which depend on eachother. I believe that even though my application can successfully find the frameworks (i've changed the install directory so the frameworks know where they are), the ones that reference each other are still looking for the frameworks to be installed in the normal ~/Library/Frameworks directory.
This is the output I'm getting when trying to run my app:
Dyld Error Message:
Library not loaded: #rpath/SDL.framework/Versions/A/SDL
Referenced from: /Users/Daly/Library/Developer/Xcode/DerivedData/Coin_Checkers_2-cibyiolfgsmcicdrcfxufftxzbsk/Build/Products/Debug/Coin Checkers 2.app/Contents/MacOS/../Frameworks/SDL_image.framework/SDL_image
Reason: image not found
Binary Images:
0x7fff5fc00000 - 0x7fff5fc3be0f dyld 132.1 (???) <29DECB19-0193-2575-D838-CF743F0400B2> /usr/lib/dyld
It seems to me that It's correctly loading SDL_image, but failing when SDL_image references SDL. Is there any similar trick I can use to direct the SDL_image framework to the correct location for my embedded SDL framework?
Thanks a bunch!
Oh, never mind. I hadn't seen this question until it showed up in the related section on the side:
Embedding frameworks in a Mac App Bundle
Apparently all I needed to do was set the runpath searchpath, and that solved all my problems. I had tried setting the Frameworks search path, but that didn't seem to help.
In fact, I redownloaded the frameworks to see if the install_name_tool steps were even necessary, and it seems they are not. they worked without it. Interesting.