Application developed in Snow Leopard not appearing executable in Leopard - cocoa

I developed a simple application in Snow Leopard. The build configurations at which it was compiled in Snow Leopard are: (10.5 | Release | i386).
When I tried to compile it using above stated configurations it gave me this error in the application delegate file, which was created automatically when I created the project: cannot find protocol declaration for 'NSApplicationDelegate'.
So I removed <NSApplicationDelegate> from its header file and it was compiled successfully.
Although it is running successfully in Snow Leopard, to my surprise its .app file is not appearing to be executable in Leopard.
Can anyone suggest me why it is showing such strange behavior and how can I resolve it
Thanks,
Miraaj

There are multiple settings that must all be set correctly in order to make this run. (One day, I'd love for Xcode to have a magic "What systems should this program run on?" list that then sets everything up correctly. But that's neither here nor there...)
Project -> Edit Project Settings -> Build Tab: make sure Architectures/Base SDK is set to Mac OS X 10.5.
Project -> Edit Project Settings -> Build Tab: make sure the Architectures/Valid Architectures list includes the system type you're running Leopard on (it's easy to leave out the ppc option).
Project -> Edit Project Settings -> Build Tab: make sure the Architectures/Build Active Architecture Only is unchecked
Project -> Edit Project Settings -> Build Tab: make sure the Deployment/Mac OS X Deployment Target is set to Mac OS X 10.5.
Under Project -> Edit Active Target -> Build Tab: check the same things
Now, you say you had to remove some 10.6 protocol declarations to get it to build. This implies that you'd already done all this (I mostly wrote the top part of the answer for Google's sake; but it's probably still worth double-checking). So now I'm curious what the symptoms for "is not appearing to be executable in Leopard" are.
Does it crash immediately? Does the OS not treat it as an executable bundle? Something else?
Have you tried running the executable from a command line on Leopard (cd into MyApp.app\Contents\MacOS, then run ./MyApp). What happens then? What gets printed to the console when you do it this way?
Basically, you haven't told us what's wrong in enough detail for us to really help out.

check your build settings. in particular Deployment:MacOS X Deployment Target

Check your Info.plist for the value of
Minimum system version (LSMinimumSystemVersion)

miraaj:~ keyss$ otool -L -arch all /Users/keyss/Desktop/Release_2/XYZ.app/Contents/MacOS/* /Users/keyss/Desktop/Release_2/XYZ.app/Contents/MacOS/XYZ (architecture x86_64): /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version
1.0.0, current version 111.1.4) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 32.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.18.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.24.0) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.46.0) /Users/keyss/Desktop/Release_2/XYZ.app/Contents/MacOS/XYZ (architecture i386): /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version
1.0.0, current version 111.1.4) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 32.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.18.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.24.0) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.46.0) /Users/keyss/Desktop/Release_2/XYZ.app/Contents/MacOS/XYZ (architecture ppc7400): /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version
1.0.0, current version 111.1.4) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 32.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.18.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.24.0) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.46.0)

Related

What is the simplest way to distribute an app depending on a few .dylib(s) on Mac (would zipping the .dylib(s) work)?

I built a simple app using Crystal on a Mac, and it appears to depend upon two libraries (.dylib).
What is the simplest way to distribute that app (would zipping the .dylib(s) along with the executable in a given directory work), or do I have to use a tool like install_name_tool to rewrite the path to the libraries?
In other words, if the required libraries are in the same directory than the executable, will the executable find them or is the path to libraries hard-coded in a Mac application?
otool -L ./bin/hello: yields:
./bin/hello:
/opt/homebrew/opt/bdw-gc/lib/libgc.1.dylib (compatibility version 7.0.0, current version 7.1.0)
/opt/homebrew/opt/libevent/lib/libevent-2.1.7.dylib (compatibility version 8.0.0, current version 8.1.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)

Setting up LLDB debugger in Qt 5.4 on Mac OS X Darwin Kernel Version 14.3.0

I have installed Qt 5.4 on MacOSX Darwin Kernel Version 14.3.0 and
am trying to setup LLDB Debugger as GDB has been depurated from MacOSX (as i didn't found it as default).
When i am trying to setting up debugger option in Build & Run kit in Qt Creator following below steps mentioned in Qt Documentation :
Select Tools > Options > Build & Run > Kits.
Select an automatically created kit in the list, and then select
Clone to create a copy of the kit.
In the Debugger field, select an LLDB Engine.
If an LLDB Engine is not listed, select Manage to add
it in Tools > Options > Build & Run > Debuggers.
For more information, see Adding Debuggers. To use the debugger,
add the kit in the Build Settings of the project.
I am setting the Debugger as "/usr/bin/lldb" in the Build&Run Kit.
After following all the steps correctly as mentioned various forums when i try to set the breakpoint and run the Qt project in Debug mode it is not hitting the breakpoint.It running as "Run" option Not working like "DEBUG" Mode.
I have one small question or maybe asking for suggestion regarding following error which i resolved but i don't know whether its correct way to do that.
When trying to run an executable I've been sent in Mac OS X, I get the following error
dyld: Library not loaded: libLocalIPC.1.dylib
Referenced from: /Users/"Directory my executable is in"
Reason: image not found.
I fixed this issue with setting Environment DYLD_LIBRARY_PATH under Project Settings/Run Environment with the library path which points to debut version of library.So for Building my Application in Release i have to again set the Library Path with Release Library Path.So this solution is not correct.
Another Solution i tried before that was with using otool -L #executable_Path/XXX.exe and checking the path of dylib and changing it with,install_name tool of Xcode but it didn't worked also.
Example:
MacOS xxx$ otool -L check abc
libLocalIPC.1.dylib (compatibility version 1.0.0, current version 1.0.0)
libxxx.1.dylib (compatibility version 1.0.0, current version 1.0.0)
libqyyy.1.dylib (compatibility version 1.0.0, current version 1.0.0)
libzzz.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/spandey/Qt/5.4/clang_64/lib/QtWebEngineWidgets.framework/Versions/5/QtWebEngineWidgets (compatibility version 5.4.0, current version 5.4.1)
/Users/spandey/Qt/5.4/clang_64/lib/QtWebEngine.framework/Versions/5/QtWebEngine (compatibility version 5.4.0, current version 5.4.1)
/Users/spandey/Qt/5.4/clang_64/lib/QtQuick.framework/Versions/5/QtQuick (compatibility version 5.4.0, current version 5.4.1)
/Users/spandey/Qt/5.4/clang_64/lib/QtGui.framework/Versions/5/QtGui (compatibility version 5.4.0, current version 5.4.1)
After this i set the path to libs libxxx.1.dylib,libyyy.1.dylib & libzzz.1.dylib and again run the otool -L abc
Results :Administrators-Mac-Pro:MacOS spandey$ otool -L abc
abc:
/Users/spandey/Desktop/Perforce/launcher/xxx/libxxx.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/spandey/Desktop/Perforce/launcher/ThirdParty/yyy/lib_osx/libqyyy.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/spandey/Desktop/Perforce/launcher/ThirdParty/zzz/debug_osx/libzzz.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/spandey/Qt/5.4/clang_64/lib/QtWebEngineWidgets.framework/Versions/5/QtWebEngineWidgets (compatibility version 5.4.0, current version 5.4.1
MacOS xxx$ ./abc
dyld: Library not loaded: libzzz.1.dylib
Referenced from:
/Users/spandey/Desktop/Perforce/launcher/xxx/libxxx.1.dylib
Reason: image not found
Trace/BPT trap: 5
Please can some one help me in both the issues as i am trying this from last 3 days with no success.

How will having a link to libgcc_s.1.dylib from two sources break things?

I am building a binary with MacPorts GCC 4.7.2+universal on a Mac OS X 10.8.3 host running Xcode 4.6.2.
I am targeting the build for Mac OS X 10.5-10.8 hosts by using the compilation flag:
-mmacosx-version-min=10.5
The resulting binary my_first_binary has two links to libgcc_s.1.dylib:
$ otool -L ../bin/my_first_binary
../bin/my_first_binary:
/opt/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.17.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1669.0.0)
/opt/local/lib/gcc47/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
The binary is written in C++, is compiled with the MacPorts g++ 4.7.2+universal compiler and has some trouble opening up a file using some C I/O routines.
I make a second binary that targets 10.6-10.8 hosts by changing the compilation flag:
-mmacosx-version-min=10.6
This second binary has only one link to the libgcc_s.1.dylib library:
$ otool -L ../bin/my_second_binary
../bin/my_second_binary:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/opt/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.17.0)
/opt/local/lib/gcc47/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
This second binary works properly and opens files without issues.
My questions are:
What about setting the minimum build version to 10.5 is causing the /usr/lib-variant of libgcc_s.1.dylib to be linked?
Can this cause namespace collisions or other problems with C-based code in my two binaries?
If this is a problem, what can I do to stop or troubleshoot this, while continuing to build to a minimum 10.5 target?

QuickLook PlugIn is "damaged/missing resources". Why?

SETUP:
OS X 10.8.2
Xcode4.5.2 (4G2008a)
Document-based Cocoa Application with a QuickLook PlugIn
PROBLEM:
I'm trying to add a QuickLook plugin to my Document-based OS X application, but the QL PlugIn will not launch.
My QuickLook PlugIn needs to embed and link to two Frameworks that I've created myself (Called IDEKit and TDAppKit). I've read this SO post about linking Frameworks in QuickLook PlugIns, and followed the instructions there (I set the DYLIB_INSTALL_NAME_BASE of my two Frameworks to #loader_path/../Frameworks).
Here's some relevant information about my QuickLook PlugIn after it is built:
% otool -L /Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/MacOS/ShapesQuickLook
/Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/MacOS/ShapesQuickLook:
/usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 47.0.0)
#loader_path/../Frameworks/IDEKit.framework/Versions/A/IDEKit (compatibility version 1.0.0, current version 1.0.0)
#loader_path/../Frameworks/TDAppKit.framework/Versions/A/TDAppKit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/QuickLook.framework/Versions/A/QuickLook (compatibility version 1.0.0, current version 555.4.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 55179.0.2)
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.8.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 19.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 45.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 57.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.1.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 945.11.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1187.33.0)
The linked/embedded Frameworks are in place:
% file /Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/MacOS/ShapesQuickLook
/Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/MacOS/ShapesQuickLook: Mach-O universal binary with 2 architectures
/Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/MacOS/ShapesQuickLook (for architecture x86_64): Mach-O 64-bit bundle x86_64
/Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/MacOS/ShapesQuickLook (for architecture i386): Mach-O bundle i386
% file /Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/Frameworks/IDEKit.framework/IDEKit
/Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/Frameworks/IDEKit.framework/IDEKit: Mach-O universal binary with 2 architectures
/Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/Frameworks/IDEKit.framework/IDEKit (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
/Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/Frameworks/IDEKit.framework/IDEKit (for architecture i386): Mach-O dynamically linked shared library i386
% file /Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/Frameworks/TDAppKit.framework/TDAppKit
/Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/Frameworks/TDAppKit.framework/TDAppKit: Mach-O universal binary with 2 architectures
/Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/Frameworks/TDAppKit.framework/TDAppKit (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
/Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/Contents/Frameworks/TDAppKit.framework/TDAppKit (for architecture i386): Mach-O dynamically linked shared library i386
However, when I try to launch my QuickLook PlugIn using qlmanage and a test document, I get the following error:
dyld: DYLD_ environment variables being ignored because main executable (/System/Library/Frameworks/QuickLook.framework/Versions/A/Resources/quicklookd.app/Contents/MacOS/qlmanage) is code signed with entitlements
Testing Quick Look preview with files:
/Users/itod/Desktop/test.shapes
[ERROR] Can't load plug-in at file://localhost/Users/itod/Library/Developer/Xcode/DerivedData/Shapes-bqzarhutlkqukverhbjatfvaextg/Build/Products/Debug/Shapes.app/Contents/Library/QuickLook/ShapesQuickLook.qlgenerator/: The bundle “ShapesQuickLook” couldn’t be loaded because it is damaged or missing necessary resources.
Note the:
The bundle “ShapesQuickLook” couldn’t be loaded because it is damaged or missing necessary resources.
I'm not certain that this issue is caused by a problem with embedded Frameworks (but I think it probably is).
What might I be missing? How can I get my QuickLook PlugIn to launch?
OP here. I found the solution in this blog post about Dylibs, Install Names, and rpaths.
Specifically, the advice under the #rpath section worked for me.
So in my embedded frameworks, I set the DYLIB_INSTALL_NAME_BASE to be #rpath/.
Then I have an App and a QL PlugIn which each embed the frameworks:
In my Application target's build settings, I added the following Other Linker Flags: -rpath #executable_path/../Frameworks/.
And in my QuickLook Plugin target's build settings I added the following Other Linker Flags: -rpath #loader_path/../Frameworks/.
That solved the issue. Now the app and the QL PlugIn work correctly.

dyld not loaded Reason: image not found libopencv_core.2.4.dylib

I'm still quite new to Objective C and Xcode, but I just finished a small app that uses the openCV libopencv_core.2.4.2.dylib.
When I went to open the final built app on another machine, OS X threw me this error:
Dyld Error Message: Library not loaded: */libopencv_core.2.4.dylib
Referenced from: /Users/USER/Desktop/my
app.app/Contents/MacOS/my app
Reason: image not found
Why is my app looking for 2.4 instead of 2.4.2 here?
What I already checked:
I added a new build phase -> so that libopencv_core.2.4.2.dylib is copied to the app package (via "Copy Bundle Resources" in Xcode) - libopencv_core.2.4.2.dylib now lies in my app.app/Resources
What did I miss? Do I have so set some more library search paths or similar?
What I also did:
install_name_tool -id "#executable_path/../Frameworks/libopencv_core.2.4.2.dylib" libopencv_core.2.4.2.dylib
Copying the dylib to the Frameworks directory doesn't work either:
Library not loaded: #executable_path/../Frameworks/libopencv_core.2.4.2.dylib
Don't know what to do now - the dylib is in the Frameworks directory of my app...
Using otool -L on the binary gives me:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 19.0.0)
#loader_path/../Frameworks/libopencv_core.2.4.2.dylib (compatibility version 2.4.0, current version 2.4.2)
#loader_path/../Frameworks/libopencv_highgui.2.4.2.dylib (compatibility version 2.4.0, current version 2.4.2)
#loader_path/../Frameworks/libopencv_imgproc.2.4.2.dylib (compatibility version 2.4.0, current version 2.4.2)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 945.11.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.1.0)
/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData (compatibility version 1.0.0, current version 407.7.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1187.33.0)
I had the same problem. i keep all .dylib in system root directory usr/lib it working fine. At the run time .o file not get .dylib file path then it gives an error.
I found a better solution: recompiling openCV in Xcode and set the #executable_path/../Frameworks in the build settings, for every .dylib you compile - now the .dylibs themselves always "know where they are".
Since other answers are not clear enough;
Assume your dylib files are located in /usr/local/opt/opencv3/lib
sudo ln -s /usr/local/opt/opencv3/lib/*.dylib /usr/local/lib
will solve this problem. Be aware that /usr/lib is protected by system in MacOS, thus you should use /usr/local/lib.

Resources