I’ve been getting this warning when using the Mac terminal and skm library to compile a simple hello world program in C++. I’m new to this so not really sure what to do.
ld: warning: dylib (/Users/chriscommon/.splashkit/lib/macos/libSplashKit.dylib) was built for newer macOS version (10.15.4) than being linked (10.15)
ld: warning: object file (/Users/chriscommon/.splashkit/clang++/lib/macos/libSplashKitCpp.a(splashkit.cpp.o)) was built for newer macOS version (10.15.4) than being linked (10.15)
ld: warning: object file (/Users/chriscommon/.splashkit/clang++/lib/macos/libSplashKitCpp.a(adapter_type_mapper.cpp.o)) was built for newer macOS version (10.15.4) than being linked (10.15)
Does anyone know if there is some way I can resolve this so it links to the correct version? I’m running macOS10.15.7 and have tried to update skm, reinstall Xcode command line tools etc and the program works ultimately but the warnings appear each time I compile.
Try to add this flag to Xcode when you build your program:
-mmacosx-version-min=11.0
Related
MacOS: 13.0.1
Boost: 1.80
CLion: 2022.2
I am getting the warning listed in the title when I try to compile and link my code in CLion using cmake on my Mac. The code in question is a set of tests on a small fraction of my code using the Boost testing framework. I installed Boost from Homebrew a while ago and recently upgraded all of my Homebrew packages. I did not have the error before the upgrade.
The path /usr/local/lib/libboost_unit_test_framework-mt.dylib you see in the message is a symlink to ../Cellar/boost/1.80.0/lib/libboost_unit_test_framework-mt.dylib, so I am using v1.80 of Boost. When I read the error message, it suggests to me that the Boost dynamic library for testing expects a MacOS version of 13.0. Yet apparently either
the compiler/linker believes I am on only MacOS 11.3 (which is false) or
I have inadvertently indicated somewhere (not sure where) that I want to build for 11.3 (I suspect this is what is happening).
My question is what is causing this error and how do I fix it. Is it option #1 or #2 or something else?
What I have already done
I've looked through my project in CLion for some setting where I might specify the MacOS version I am building to.
I have reviewed related posts suggesting to add the flag -w, but this just suppresses the warning and sweeps the problem under the rug.
I'm trying to use the Canon EDSDK (latest version, v3.6 as of writing) in a simple, C++, command-line program on macOS (Sierra 10.12.6). I wish to utilize a simple Makefile environment and the usual apple compiler tools (llvm-clang) and avoid Xcode or any other heavy-weight IDE. The samples included with the SDK are all Xcode centric so I've had to roll my own here.
At present, I am able to compile a program to init the SDK and list connected cameras. As soon as I execute any EDSDK command however, I am getting a dynamic linking error:
Error loading /Library/Frameworks/EDSDK.framework/Versions/A/DppCore.bundle/Contents/PlugIns/DppCoreG.bundle/Contents/MacOS/DppCoreG: dlopen(/Library/Frameworks/EDSDK.framework/Versions/A/DppCore.bundle/Contents/PlugIns/DppCoreG.bundle/Contents/MacOS/DppCoreG, 262): no suitable image found
Did find: ... snip ... mach-o, but wrong architecture
The same error lists twice (both for DppCoreG). Upon examination, DppCoreG is compiled for 64bit architecture:
file /Library/Frameworks/..snip../DppCoreG
/Library/Frameworks/..snip../DppCoreG: Mach-O 64-bit bundle x86_64
However, there are other critical parts of the EDSDK that are compiled for 32bit architecture only:
file /...snip.../DPP.framework/DPP
/...snip.../DPP.framework/DPP: Mach-O dynamically linked shared library i386
How do I resolve this? The path of least resistance so far is to compile to i386 architecture explicitly (and the documentation explicitly states EDSDK is not 64-bit compatible). All is well except this one dynamic linking error (and in fact everything I've tried so far, which is just listing connected cameras, seems to work okay) but it is something I'm sure I can't continue to ignore or allow to persist in a production version of this project.
Here's a minimal example to cause the DYLD error:
#include <EDSDK.h>
#include <EDSDKTypes.h>
#include <EDSDKErrors.h>
int main(int argc, char** argv) {
EdsInitializeSDK();
EdsTerminateSDK();
return 0;
}
And probably more informative is the command to compile:
c++ -D __MACOS__ -g -arch i386 -I./deps/mac/include -framework DPP -framework EDSDK -o min min.cpp
I have the headers in the local include directory shown in the command and the frameworks installed under /Library/Frameworks.
Note that the c++ command is Apple LLVM version 8.1.0 (clang-802.0.42)
I've concluded that this is just an error on the part of those that deliver the EDSDK for mac. They should be compiling this particular bundle as a universal binary, not a 64bit binary. You can work around the problem by simply removing the offending bundle. It appears to just be a plugin and removing it does not seem to immediately affect the SDK. Assuming you have installed the EDSDK framework in /Library/Frameworks then just do this:
sudo rm -rf /Library/Frameworks/EDSDK.framework/Versions/Current/DppCore.bundle/Contents/PlugIns/DppCoreG.bundle
Enter your password when prompted (this assumes you are an admin account) and it will delete the offending plugin.
I have to believe that there may be consequences for removing this plugin at some point and if anyone knows more about this particular bundle/plugin and can explain what removing it will do I'd appreciate the additional insight.
In addition to #OllieBrown answer, I found in Xcode building for MacOS I had an additional item to remove to stop the link warnings.
link warning- EDSDK.framework/Versions/Current/DPPLibCom.bundle/Contents/MacOS/DPPLibCom: mach-o, but wrong architecture
removing EDSDK.framework/Versions/Current/DppLibCom.bundle stopped the warning.
Since the 3.x version there is a split between intergrated versions of DPP RAW capabilities. The original DPP works in x86 mode only and allows inspection and conversion of CR2 files on cams up until a certain models. See the API doc for the list. For recent camera models which rely on the new 64bit DPP engine (v4+?, dppcoreg) you would need x86_64 bit build so it dynamically links to use the latest features. Quite some (Raw) features are dropped, and gradually make their way back in in beta state.
I am currently writing a c++ game using allegro 5.0 and c++. I will eventually get it working on mac, linux, windows, and possibly android and iPhone. Currently it compiles and runs on linux (tested on arch linux latest), but on mac there is a slight problem:
Using the apple provided g++, it complains about a linking error, _main not defined. However, I have checked and checked, and main is definitely defined in my file. It must be anyway because it compiles and runs on linux, but I can't figure it out.
I have googled many many days and many many terms (too many to list) and haven't found anything to do with mac and main not being defined. Could there be something I'm missing? Something i need to do special on mac? One last thing to note is when I link with allegro_main.a it links, but then crashes. Linking with this library is not necessary on linux. I am using allegro5 through macports. It is also useful to note that the sh script used to compile on mac is comp_mac.sh, and linux is simply comp.sh. Note that you may need to modify the sh script(s) to compile on your environment. These are only tested on my environment (macports) so far.
My code can be found here: http://github.com/2mb-solutions/horseshoes/
Thanks for all the help I can get.
-Michael.
The "_main" undefined symbol error is occurring because you are not linking with the allegro_main addon.
As the Allegro 5 manual specifies, in C and C++ projects, the file containing your main() function must include the core header allegro5/allegro.h. Additionally, you must link with the allegro_main addon.
It might be easiest to use pkg-config:
pkg-config --cflags --libs allegro-5 allegro_ttf-5 allegro_audio-5 allegro_acodec-5 allegro_font-5 allegro_main-5
You can place that command within backticks ( ` ) to include the output of pkg-config in your build command.
Like many others, I'm taking the CS106B class on iTunes and, although the class is old, I am attempting to use the Stanford C++ libraries that are current. They are found here: http://www.stanford.edu/class/cs106b/.
During the Build Phase of projects, I have inserted into "Link Binary with Libraries" the files "random.h" and "libStanfordCPPlib.a". When I do this, I get the following error messages:
Check dependencies
warning: skipping file '/Users/lewis/Documents/Think Like a Programmer/CS106/VotingSimulation/../../../Programming Abstractions/Assignment 1/Assignment1-xcode/0 - Warmup/StanfordCPPLib/random.h' (unexpected file type 'sourcecode.c.h' in Frameworks & Libraries build phase)
ld: warning: ignoring file /Users/lewis/Documents/Programming Abstractions/Assignment 1/Assignment1-xcode/0 - Warmup/StanfordCPPLib/libStanfordCPPLib.a, file was built for archive which is not the architecture being linked (x86_64): /Users/lewis/Documents/Programming Abstractions/Assignment 1/Assignment1-xcode/0 - Warmup/StanfordCPPLib/libStanfordCPPLib.a
Undefined symbols for architecture x86_64:
"randomChance(double)", referenced from:
_main in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I am using Mac OS X 10.7.5 and XCode 4.6.2. I have set the Build Settings Base SDK to OS X 10.7 for both the Project and the Target.
It appears to me that the "libStanfordCPPlib.a" file may be an archive file that I have to unarchive before I can link the implementation code for the header files. Is this what I need to do, and if so, how do I do it? Am I doing something else wrong in linking the files?
I'm a noob and I'd appreciate help from anyone who has been successful in getting the current Stanford CS106B C++ libraries to work in XCode 4.6.2.
I just ran into this problem myself after upgrading to the newest version of xcode (ver. 5.0, OSX ver. 10.8.5).
Try switching the architecture of the project to 32-bit Intel (i386). The default is "Standard Architectures 64-bit Intel (x86_64)".
I'm currently using xcode 6.4 and trying to work through the cs 106b course work, I had the same issue of not being able to run the sample files and assignment files (can be found here btw http://web.stanford.edu/class/archive/cs/cs106b/cs106b.1136/ ). After changing the Architectures for both the Project and Target to 32-bit-intel as listed above I still received errors. I had to take the additional step of changing the OSX deployment target from 10.10 to 10.8 under the Project info.
This allowed the program to build but I received a notification that i needed to install the Java Runtime Environment, and there was no consult output. Installing this did not resolve the issue. I was only able to fully execute the code after installing the Java Development Kit. I am now able to compile all files for the course.
I hope this update helps more recent attempts to access this info.
I hope you've found an answer to your problem by now, but as I was suffering from a similar problem, trying to get xcode 5.1 to compile Warmup.cpp, I thought I'd post my solution for those others trying to get xcode to work with the cs106b libraries.
After struggling with xcode 5.1.1 and 5.0.2, I downloaded xcode 4.6.3 off of the apple dev site, www.developer.apple.com, and trashed the later versions. After installing 4.6.3, I still got errors, but after switching the Architecures for the Project and for the Target, to "32-bit-Intel", as messysaurus suggests, the warmupp.cpp compiled fine. Trying this same technique with xcode 5.1.1 and 5.0.2 yielded no results.
Hope this helps anyone else running into problems.
I'm trying to port a project of mine on Mac OS-X.
As I developed my project using C++0X I needed a more recent version of GCC than the one provided with Xcode (even Xcode4), so I compiled GCC 4.6 on my Snow Leopards Mac.
My project does compile fine and it does start too on the computer I compiled it (OS-X 10.6.7) but when I transfer it to my MacBook (OS-X 10.5.8) it doesn't works.
It returns the following errors:
dyld: lazy symbol binding failed:
Symbol not found:
__ZNSo9_M_insertImEERSoT_ Referenced from:
/Users/zu/Desktop/OgreApp.app/Contents/MacOS/OgreApp
Expected in:
/usr/lib/libstdc++.6.dylib
dyld: Symbol not found:
__ZNSo9_M_insertImEERSoT_ Referenced from:
/Users/zu/Desktop/OgreApp.app/Contents/MacOS/OgreApp
Expected in:
/usr/lib/libstdc++.6.dylib
I understand that the program needs the libstdc++.6.dylib of the GCC 4.6.0 as this file contains the C++0x functions (despite the fact that my current test doesn't use any C++0x function) instead of the standard libstdc++.6.dylib usually included in the OS-X system.
So I tried the following:
to specify -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 in order to ensure backward compatibility with OS-X 10.5. But the error remains the same.
to verify the libstdc++.6.dylib path using otool -L and changing the shared library path using install_name_tool -change /opt/local/lib/gcc46/libstdc++.6.dylib #executable_path/../Libraries/libstdc++.6.dylib OgreApp (with a copy of the gcc 4.6.0 libstdc++.6.dylib in the Libraries folder) as suggested as answer of my previous question. But the error remains the same.
to statically link libstdc++ and libgcc using -static-libgcc - static-libstdc++. But it still returns the same error.
As my program use the Ogre framework, I applied the above manipulations to the Ogre executable embedded in the Ogre.framework too, but it doesn't change anything.
Does anyone can explain me how I'm supposed to deploy an application created with a non standard libstdc++ on another Mac computer installed with an older version (I guess the problem is the same with a computer running Snow Leopard as the program use the GCC 4.6.0 libstdc++) ?
Mac OS X 10.5 does not include a compatible copy of the GCC standard library. If you want your code to run on Leopard, you'll have to either modify it to compile under an older version of GCC, or you'll have to... well, really that's your only option.