I am using Mac OS X 10.6 SDK and my deployment target is set to Mac OS 10.5. I'm linking to libcrypto (AquaticPrime requires this) and found out that my app doesn't launch on Leopard. The error is
dyld: Library not loaded: /usr/lib/libcrypto.0.9.8.dylib
I've tried the following workarounds but none of them work:
Linking directly to libcrypto.0.9.7.dylib (the 10.6 SDK refuses to link directly with libcrypto.0.9.7.dylib.
Copying the 10.5 SDK's version of libcrypto.0.9.7.dylib to the 10.6 lib directory and try t link with it (this time the link process succeeded but in Leopard the app still tries to lookup the non-existent libcrypto.0.9.8.dylib file and thus won't launch).
Copying libcrypto.0.9.7.dylib from a Mac OS X 10.5.8 installation and link with it (the link was successful but the app still looks for libcrypto.0.9.8.dylib).
Is there a way to link to this library and still use the 10.6 SDK?
Thanks.
As per this thread here ( first post in thread: http://lists.apple.com/archives/cocoa-dev/2009/Aug/msg01737.html , "libcrypto on Snow Leopard" thread listing: http://lists.apple.com/archives/cocoa-dev/2009/Aug/thrd19.html ), I believe the solution is to do the following:
Go to /Developer/SDKs/MacOSX10.5.sdk/usr/lib/ . From this folder, copy "libcrypto.0.9.7.dylib" to your project source folder.
Rename the file you just copied to "libmycrypto.dylib".
Add the file you just renamed to your project. Make sure to remove any other linked libcrypto frameworks from your project.
Go through your build settings, and make sure you remove the "-lcrypto" linker flag. (It's usually put in the "Other Linker Flags" setting.)
Now you should be able to build your project and it will work on both 10.5 and 10.6.
(libcrypto.0.9.7 is available on both 10.5 and 10.6. The file you copied is just a stub of the headers, but you're just linking against it, not embedding it in your project. Since the linker uses the install path not the actual filename of the dylib, naming it "libmycrypto.dylib" eliminates path conflicts, but still allows you to link against the library you need.
FWIW, this is an Xcode problem. You should be able to link against /usr/lib/libcrypto.dylib -- the symbolic link -- and have it target the correct version of libcrypto on both 10.5 and 10.6. However, Xcode always seems to link to version 0.9.8 when building on Snow Leopard for some reason.)
You could try setting the base SDK to 10.5 in your target build settings.
Depending on what you're using the lib for, you might be able to replace libcrypto with CommonCrypto which works well with both 10.5 and 10.6. I've used libcrypto only for the MD5 function, so I replaced openssl/md5.h with CommonCrypto/CommonDigest.h and MD5() with CC_MD5(), and libcrypto with CommonCrypto, and now it works on both Leopards.
Have you tried linking against libcrypto.0.9.dylib or libcrypto.dylib instead of the specific versions?
Leopard OS X ships with a libcrypto and libssl that only has the ppc architecture.
A simple solution that doesn't require changing the code of the app is to backup your libcrypto.0.9.dylib, libcrypto.0.9.8.dylib, libssl0.9.dylib, libssl.0.9.8.dylib and copy over the libcrypto.0.9.7.dylib and libssl.0.9.7.dylib.
You can use Terminal.app to make these changes in your Applications folder:
cd /usr/lib
sudo cp libcrypto.0.9.dylib libcrypto.0.9.dylib.old
sudo cp libssl.0.9.dylib libssl.0.9.dylib.old
sudo ln -sf libcrypto.0.9.7.dylib libcrypto.0.9.dylib
sudo ln -sf libssl.0.9.7.dylib libssl.0.9.dylib
Here's an alternative solution that lets you stay on the freshest openssl version:
1. reactivate the current openssl: port activate openssl#1.0.0c_0 (or whatever)
2. clean up your old unwanted versions of everything: port uninstall inactive
3. uninstall badly behaved ports: port uninstall md5sha1sum subversion neon
4. get them back: port install subversion md5sha1sum
Related
I downloaded the FastX toolkit precomplied binaries for "MacOS X 10.5.8 (32-bit)" (http://hannonlab.cshl.edu/fastx_toolkit/download.html). However, when I cd into the directory with the tools and try to execute any of them (e.g. with any command like fastq_quality_filter -h), I get the error:
-bash: /usr/local/bin/fastq_quality_filter: cannot execute binary file
I'm not positive but it seems like it might be because the file kinds are "Unix executable" which might not be compatible with Mac (though I downloaded the binaries that were supposedly for Mac). I've tried chmod + x but the files already have execution permission so that didn't help. Any other ideas?
macOS 10.15 (Catalina) and newer do not support 32-bit apps. If you are on 10.15 or later, you need to either compile the toolkit yourself, or find a place to download 64-bit executables.
The ironic thing is that all this used to work on my Mac, but Apple no longer supports 10.5.8, so I was forced to update to Snow Leopard, 10.6. And everything broke (thank you Apple).
On the surface, it seems simple. Build an open source package like octave under Snow Leopard (Mac OS X 10.6)
Apple has made this difficult, to say the least. They no longer download XCode for older operating systems unless you are a paid developer. My Macbook pro 2.16Ghz cannot load Lion, so that option is not available.
My old fink doesn't work because it was old. In order to build a new one, I need Xcode 3.2, which I can't get (see above).
I downloaded a free gcc 4.2, and it works fine.
So in order to try to build octave, it's the old style gnu install:
./configure
make
make install
./configure fails because there is no fortran installed. That's a special case because the install of gcc didn't include fortran. So a fallback would be building a complete gcc which I have done in the past.
downloaded gcc 4.9:
gcc-4.9-20130728
inside, gcc49
gcc can't build because it needs the three subsidiary packages gmp, mpfr and mpc
I am now trying to build these, so that I can bootstrap a complete gcc build, but in the meantime, is there any simpler way to bootstrap these things? I find it hard to understand why no binaries are available for:
fink
octave
which would solve part of my current problems.
You can still get XCode. You just have to be registered on Apple Developer, but you do not have to pay for the license. You then download it through the Mac App store, or you can get a link that opens it in the App store here. Finally, you have to install the command line tools from within Xcode. These can be found under the Components tab of the Download Preferences panel.
Let me know if that does not help. My iMac running 10.6 is currently in for repairs, so I am on my 10.7 laptop and cannot test all the specifics yet.
The Mac QT Installer puts its shared libraries under /Library/Frameworks/QtXXX.Framework.
I'm building a QT application using a qmake-generated xcode project. I'd like to add these frameworks as private framewords inside my app bundle for easy deployment.
I've tried various options for doing this but I don't seem to be able to make it work. What I did -
change the Qt framework files in /Library/Frameworks/ using install_name_tool as described here
copy the these framework bundles manually to inside the app bundle
recompiling the bundle.
When I change the name of the original framework so it would appear that it's not there, the app crashes and says that it doesn't find the needed framework. What am I doing wrong?
Using xcode 4.3 on OSX 10.7.3
Some options to deploy a Qt application on Mac:
Qt comes with the macdeployqt tool, to bundle Qt with the built app bundle. The tool is a bit limited though and might or might not do what you want.
CMake comes with DeployQt4, which can also be used for deployment only, in case one doesn't want to use cmake for the build as well.
One can write his own script using install_name_tool as described in your link. If it doesn't work, check with otool -L if you replaced all absolute paths in the executable and bundled libraries. You will have to fix the paths for the bundled libraries, too! (recursively, so to say).
The latest released cmake version (2.8.7) doesn't support XCode 4.3 properly though: Since Xcode 4.3, files previously being installed to /Developer are now in /Applications/Xcode.app/Contents/Developer. cmake still expects them in /Developer. That is fixed in cmake master but not released yet. A workaround is to create a symlink:
ln -s /Applications/Xcode.app/Contents/Developer /Developer
I've downloaded the source for KardsGT, which is written for I think QT 4.6.x onto my Mac OS X 10.6.8 system.
Since KardsGT is not written specifically for Mac OS X (it was meant for GNU/Linux), there is no associated XCode files, etc. When I run qmake on the source, I get lots of error like
WARNING: Ignored (not found) '/src/kardsgt-0.7.1/src/players/players-debug.xcodeproj'
It seems that qmake is thinking I am using XCode for this project? How do I correct this so the code will compile? (I've tried qmake -unix but that didn't change the results)
You do not need Xcode to compile a Qt program. Just run
$ qmake -config release
$ make clean
$ make
and you should be good to go (if the sources do not use any Linux-specific stuff).
I have installed the developer tools. I can compile code via Xcode and according to the docs /usr/bin/gcc & /usr/bin/cc should point to /usr/bin/gcc-4.0. Neither the symlinks or gcc-4.0 exist on my system (Snow Leopard). All I wish to do is compile some C on the terminal! I'm amazed by how complicated this task is. The command GCC is unsurprisingly returning "gcc: command not found".
Can anyone shed some light on this?
No! Reinstalling is the wrong answer!
Newer versions of XCode require you to install the command-line versions of the tools separately. In XCode, go to Preferences | Downloads, check the Components tab, and install them from there:
These binaries should be there after installing xcode. Check your path settings, and if you still don't have these reinstall xcode
Command line tools are no longer included with the latest XCode (even as an add on). Now you can download them here:
https://developer.apple.com/downloads/index.action
Did you install the latest Xcode after installing Snow Leopard, or is this the version of Xcode from a previous OS installation?
On my system with a clean Snow Leopard install the default compiler (and the one symlinked from cc and gcc) is gcc-4.2
I do have gcc-4.0 too, although it's not the default.