My OS X app uses the OpenSSL libraries, both the libssl and libcrypto libraries. The specific version of OpenSSL libraries it has been using is the one provided in OS X, namely /usr/lib/libssl.dylib and /usr/lib/libcrypto.dylib and currently at version OpenSSL 0.9.8zg, and my app has been working fine.
Since I want to use TLS 1.2 in my app, and the OpenSSL libraries provided in OS X, at version OpenSSL 0.9.8zg, do not support it, I want to use the OpenSSL libraries at version OpenSSL 1.0.2d, available in source at the OpenSSL site, in my app.
Toward the goal of upgrading the OpenSSL libraries in my app to version OpenSSL 1.0.2d, I built the OpenSSL libraries from source and compiled my app with them successfully. However, the resulting app didn't function properly, and I don't know why. Running the resulting app, SSL_connect() always returned an error, and the subsequent call to SSL_get_error() always returned SSL_ERROR_SSL. This was the case for the libraries being dynamic libraries or static libraries. More strangely, I got the same result when I used OpenSSL 0.9.8zg libraries built from the source in building my app.
Anyone have a solution or explanation to the problem I am facing?
It turned out that there was actually no problem in the OpenSSL libraries I built. The problem I encountered was caused by a cert. For some reason, the problem only occurred when the new version of OpenSSL was used. Replacing the cert removed the problem.
Related
I need to use a new version of SQLite3 in a project built using CMake. To find external dependencies we usually use the FIND_PACKAGE() command which tends to work fine. However, FIND_PACKAGE(SQLite3) finds the very old version shipped with the OS rather than the up-to-date version provided by Homebrew. Homebrew refuses to relink to its own headers, binaries and libraries. I guess I could do that manually, but I am hesitant if Homebrew so strongly discourages it (refuses even when --force flag is given).
Any pointers on how to control where CMake looks for SQLite3 would be very appreciated.
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 don't know exactly when, but assume with upgrade from Snow Leopard to Lion (10.7.3) my system configuration seems to be messed up. When trying to install ree-1.8.7 I am running into the same problem whatever way I try:
Checking for required software...
* Non-broken C compiler... found at /usr/bin/gcc-4.2
* Non-broken C++ compiler... found at /usr/bin/g++-4.2
* The 'make' tool... found at /usr/bin/make
* The 'patch' tool... found at /usr/bin/patch
* Zlib development headers... found
* OpenSSL development headers... not found
* GNU Readline development headers... found
Some required software is not installed.
This happens when using rvm, rbenv or running the ree installer (went through all options). Though openssl is installed and working:
openssl version
OpenSSL 0.9.8r 8 Feb 2011
I tried brewing openssl but that did not help either, so did remove it again.
I am quite desperate as I am not able to get it running. Any hints are appreciated.
EDIT: I missed the detail that I have only the xcode command-line tools installed instead of the full xcode package.
you need to tell the ./configure script where to find openssl headers
RVM forwards any --with* flags to configure, so you can pass --with-openssl-dir=... to rvm command -> https://rvm.beginrescueend.com/packages/openssl/
Using --with-openssl-dir=/usr should do the trick, but there are more options: --with-openssl-include-dir=/usr/include/openssl --with-openssl-lib-dir=/usr/lib (this might be nonstandard installation)
Also very important - ./configure will claim this flags are not recognized, it will be used in make command - check make.log in case of RVM.
Don't forget to install the proper libraries via https://github.com/kennethreitz/osx-gcc-installer. Obviously, the xcode-command-line tools that I used are missing the correct development headers.
With the answer of mpapis it should have been possible to tell the compiler the correct location, but it seems that these options are ignored in latest installer. See this forum thread (Point 3 in first post): http://discuss.joyent.com/viewtopic.php?id=25862
I am trying to install dph-examples in mac os x version 10.7.2 and I got this error. How ever on ghci , I can see
ghci>import Data.Array.Parallel.
Data.Array.Parallel.Base Data.Array.Parallel.Base.DTrace Data.Array.Parallel.Base.TracePrim Data.Array.Parallel.Stream
but not Data.Array.Parallel , Data.Array.Parallel.Prelude and Data.Array.Parallel.Prelude.Double. I copied the example ( it uses these libraries ) given on Data-Parallel-Haskell and its working fine. My program is compiling and running so my question is, why i am not able to see these library at ghci prompt. Also i am not able to find the reference for sumP function at the Data-Array-Parallel. I am using ghc-7.2.1.
GHC depends on Xcode 3.2:
The package requires Xcode 3.2 (in particular, the "Unix Development Support") to be already installed.
— GHC 7.2.1 download page
Xcode 3.2 should already come with LLVM, so if it's not already installed, installing it should fix things. If you already have it installed, then your installation might be broken somehow; you could try reinstalling it to make sure. I think Xcode 4 isn't fully supported by GHC yet, so if you have it installed, that might be the problem; you could try uninstalling it and installing 3.2 instead.
Warning: Couldn't figure out LLVM version!
Make sure you have installed LLVM
Perhaps you didn't install LLVM? Go install LLVM.
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