I'm trying to compile an older objective C app for the mac on XCODE 4.2
I'm getting a link error when trying to compile
cannot link directly with /usr/lib/libssl.0.9.7.dylib for architecture x86_64
any idea why that is and how to fix it?
After migration, you'll want to link to symlink libcrypto.dylib instead of the version-numbered dylib (libcrypto.0.9.7.dylib) if you do not need to maintain backward compatibility. The symlink will resolve to the proper version OS X 10.6+, but not to 10.5 or previous.
If you need any lib*.0.9*.dylib in your program, you'll need to manually preserve those libraries and put them into your program. You can find information on this solution in this answer: https://stackoverflow.com/a/2620698/571506
Related
I have problems building an executable file for a simple disease-transmission model implemented in C++, using cmake under macOS Monterey (v12.6.1). When I build the executable file, I obtain the following error when I try running it:
dyld[5281]: symbol not found in flat namespace (_cblas_caxpy) Abort trap: 6
The problem persists when I try to use XCode (v14.0.1) instead, resulting in the same error message.
Interestingly, my friend is able to build (& run) the executable file under macOS v10.15.7 without any problems.
Does anybody know what is going on here and how this issue can be resolved? The C++ project is publicly available on GitHub: https://github.com/AnnaMariaL/DengueSim
Any help would be very much appreciated.
Thanks!
Anna
tried: build an executable file with cmake, and Xcode under MacOS v12.16.1
expected: executable file
the program runs fine when launched under Xcode itself, but if I try to run the built executable from Xcode on the command line, that fails with the same error as for the CMake executable. So Xcode itself is, somehow, magically able to get this linker issue to resolve.
Your title/post is very confusing, however the issue isn't with cmake. It's with your cblas library and/or your linker. Look at the bug closely:
dyld[5281]: symbol not found in flat namespace (_cblas_caxpy) Abort trap: 6
Your linker is telling you that it can't find a function (symbol) in the given namespace. This is either due to the fact that your linker doesn't know where to find the correct library or you are linking against a wrong version of the library that doesn't have the symbols. The other issues might be related to how the library was built and with what it was built (architecture, compiler, etc...). This we can't answer because we don't have enough information to know for sure.
I am newbie. I have compiled OpenSSL's libcrypto.a in shell, but could not link it to my Firebreath plugin.
I have added in CMakeLists.txt:
target_link_libraries(${CURPROJECT} /path/to/libcrypto.a)
But CMake gives error:
Cannot specify link libraries for target
"/path/to/libcrypto.a" which is not build by this project
I am using MacOSX 10.9, XCode 5.1.1, FireBreath 1.7, OpenSSL 1.0.1i.
Please explain to me, how could I link libcrypto.a to my plugin?
Have you already tested the "experimental" built-in openssl support described here:
Firebreath libraries
The error message you're getting indicates that it thinks you're trying to add a link library for the project /path/to/libcrypto.a, not that you are trying to add the link library /path/to/libcrypto.a to the project $(CURPROJECT).
This might be because you need to do ${CURPROJECT} (cmake variables use {} not ()). It could also be that the variable CURPROJECT isn't defined.
Your command is correct, but the parameters you are passing into it are not. You might also consider using find_library to find libcrypto.a.
Of course, with Mac OS you should already have openssl available, so you shouldn't need to specify the path. Also, as #hasa mentioned, you are probably better off just using the firebreath openssl stuff, which is experimental but really just on windows -- mac OS it just uses the existing ones. It's only marked experimental because I'm not willing to provide support for the windows binaries.
I'm attempting to use Cocotron to build the Foundation framework. GCC 4.3.1 for Windows compiled fine, and it's creating valid Windows executable files, which I confirmed by making a "Hello, world" executable.
So what I don't understand is why, with Xcode 5.0.2, when I use either xcodebuild or build the Foundation project within Xcode itself, it isn't creating dll files.
So, it seems that as of Xcode 5, Apple no longer supports any compilers that are not derived from clang. To fix this issue, I had to copy the pbcomspec files from /Library/Application Support/Shared/Xcode/Specifications to ~/Library/Application Support/Shared/Xcode/Specifications and edit the file that declares that the compiler is based on llvm-gcc to declare that it's based on com.apple.compilers.llvm.clang.1_0. Then it should at least try to build.
I try to use hpc gcc instead clang and get same results. I found that cocotron needs additional libraries zlib, libjpeg and libpng and in xcode 4.x build failed without they, but in xcode 5.x its only warnings and build marks as success. I didn't try fix it because we began use virtual machine with xcode 3.2, but maybe it is cause that libraries are not created
BTW I use this post and this plugin
Is here anyone who successfully build Google Breakpad on MacOS using standard Qt tool chain without xcode?
I'm trying to get work this library for two days now and still without success. I already successfully compiled it and ran it on Windows and Linux. (from original Google-git repository).
But MacOS version of library has missing makefile for libbreakpad_client.a and generated libbreakpad.a does not contain the exception handler.
http://screencast.com/t/V0mNiM3kZ
I found few topic about this issue on here on a stackoverflow but advice with updated makefiles didn't work for me (or I didn't copy makefiles correctly).
I also tried to download updated version directly from Mozilla repository (version 10 and 11beta). But when I tried to compile Mozilla version, there was another errors with undefined symbols (on Mac and also on Linux).
I also found AlekSi - breakpad-qt but this version also works correctly only under Win and Linux. Under Mac there is some errors about "Unknown architecture -- are you on a PDP-11?"
I will be gratitude to anyone who can point me how to compile it and get it work under Mac or who can send me a packed version of breakpad which can be compiled under MacOS using standard make and used in Qt application.
Thank you
Ludek
AlekSi's breakpad-qt is three years old, and the breakpad source in it doesn't support 64 bits on OSX.
Failing to detect your processor type is what makes it complain about "Unknown architecture -- are you on a PDP-11?".
You definitely need a more recent breakpad version, either from their svn, or from my breakpad-qt fork at: https://github.com/webitup/qt-breakpad
Now, if you intend on supporting 10.6 (MACOSX_DEPLOYMENT_TARGET=10.6) as well, you need to patch breakpad source using this https://github.com/webitup/qt-breakpad/commit/71a9fdedd827e5939ba66bfcc0cd6c1c9fbbc87b (-> I don't think 10.6 has PPC support)
Then:
You apparently managed to compile directly from source, so, good for that way.
Now, if you want to build a framework from breakpad instead, and link to that from your qt app/lib, then Dave Mateer suggestion is the way to go (and he deserves the credit). The following worked for me:
cd $BREAKPAD_SOURCE_TREE
xcodebuild -sdk macosx10.7 -project src/client/mac/Breakpad.xcodeproj -configuration Release -target Breakpad ARCHS=x86_64 ONLY_ACTIVE_ARCH=YES MACOSX_DEPLOYMENT_TARGET=10.6 GCC_VERSION=com.apple.compilers.llvmgcc42
Note that I'm only building target Breakpad instead of All (it seems you only need that - and a test is failing for me using All, though it does produce a usable framework either way).
And note that you don't require XCode per-se - just the command line builds tools.
In order to use that framework in your QT project:
mac {
QMAKE_LFLAGS += -F$$BREAKPAD_PATH/client/mac/build/Release/
LIBS += -framework Breakpad
}
And you should be set.
Finally: I also pushed a number of changes in my breakpad-qt fork source itself to have it at least compile (on OSX!) against the updated breakpad version, but I have no idea yet if it does work properly.
I'm just starting with that fork - if you want to share experience and/or commit some stuff in there, just ask.
I have a unix command line app (with big nasty makefile) that I'm trying to run on a mac. I am compiling it on a 10.6 system, with all of the appropriate libraries of course. The deployment environment is a 10.5 system, with no extra libraries.
I compiled without -dynamic, and it appears to have static libraries, correctly. When I run it on the 10.6 system, it works. However, when I run it on the 10.5 system, I get:
dyld: unknown required load command 0x80000022
I got this same error when I compiled things for the 10.6 system using the 10.5 xcode, so it looks like a version mis-match type problem. However, I used gcc-4.0, and
$CFLAGS = -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5
so it SHOULD be set up for 10.5... any ideas?
thanks
Editing an ancient question:
I have the exact same problem on a different computer. This time I am at 10.5.8, fully update, the same executable works on 10.6 still.
Has anyone had any luck with this in the months since I asked this?
The reason for the dyld 0×80000022 error can be that, you are linking on OS X 10.6, and OS X 10.6 will use a load command (LC_DYLD_INFO_ONLY = 0×80000022) that OS X 10.5 does not understand.
To fix this, make sure you are using a deployment target by setting the environment variable just before your link command:
export MACOSX_DEPLOYMENT_TARGET=10.5
(or setenv MACOSX_DEPLOYMENT_TARGET=10.5)
You can always check if your executable uses the right load command like this:
otool -l executable
It will either show LC_DYLD_INFO_ONLY (without deployment target) commands or LC_DYLD_INFO (with deployment target).
I have been searching for the same issue, as I develop on 10.6 but must have a version that works on 10.5. In addition to the compiler flags above, you should add:
-no_compact_linkedit
It is described here:
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/ld.1.html
where it says:
Normally when targeting Mac OS X 10.6, the linker will generate compact information in the __LINKEDIT segment. This option causes the linker to instead produce traditional relocation information.
I got there from a discussion on the xcode-users mailing list about "unknown required load command 0x80000022".
i was able to solve this by passing -mmacosx-version-min=10.5 to the linker, e.g. --extra-ldflags="-mmacosx-version-min=10.5" passed to configure for ffmpeg which i was building shared. more info: http://lists.apple.com/archives/xcode-users/2009/Oct/msg00530.html
Depending on how many libraries you use, it may be difficult to get all of them linked statically. What does "otool -L your_binary' tell you?
In order to get a self-contained package for an application of my own, I made a custom MacPorts install in a non-standard directory, so that I could dynlink with the libraries from that directory and only be constrained in asking people to install the whole thing in the same place on their computers. Not great, not the Mac spirit at all, but it's an Unix app and you need to be familiar with Unix to use it anyway.
Good luck
Pascal
It turns out that there is a dynamic library load function (0x22) that got added at 10.5.6. The system I was running on was 10.5.5. I upgraded to 10.5.8, and everything runs!
Ok, SECOND solution, and NOT very satisfying, is to find a 10.5.8 computer, install the developer packages and re-compile... same for powerPC... sad but it will work...