Trying to understand why Cocotron isn't creating Framework DLLs - cocotron

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

Related

runtime error ‘symbol not found in flat namespace’ on macOS 12 but not macOS 10.15, with both Xcode and CMake builds

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.

How link OpenSSL's libcrypto.a to Firebreath plugin in XCode

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.

Clear CMake's internal cache

I am sure there is a simple command for this.
I had installed opencv 2.4.3 manually in /usr/local.
Then I removed it and installed OpenCV 2.4.5 from the arch community(I am using Arch linux) which gets installed in /usr
Now when I try to use OpenCV in a cmake project, cmake returns the old paths from /usr/local.
I did some digging around and found that if remove "CACHE" from the line:
get_filename_component(OpenCV_CONFIG_PATH ="${CMAKE_CURRENT_LIST_FILE}" PATCH CACHE)
in /usr/share/opencv/OpenCVConfig.cmake I get the correct path.
This points to my question. How do I clear the cmake cache?I am talking about cmake's internal cache not the application's cache which can be deleted by removing CMakeCache.txt. Is there a command? Or where is the cmake cache directory/file located? I am sure there's a simple answer for this.
I know how to set/unset a CACHE variable, but don't know how to clear the complete cache.
The problem was with pkg-config settings. I hadn't removed the old .pc file and adjusted the PKG_CONFIG_PATH. pkg-config was using the opencv.pc file present in /usr/local/lib/pkgconfig rather than the one present in /usr/lib/pkgconfig. There isn't any cache that cmake uses internally, i think.
Recompiling the dependency library solved my problem.
I have a project that depends on Opencv. When I still using Xcode 7.2beta, the path of SDK of MacOSX is "/Applications/xcode7.2beta.app/Content/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk". So, the cmake generated and compiled opencv libraries with MacOSX10.11.sdk under "/Applications/xcode7.2beta.app/".
A few days ago, I upgraded my xcode to 8.0, the new path of xcode and its SDK is "/Applications/xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk". But anyway, when cmake generates my project, the reference to opencv always points to the old xcode.
Later I realized that opencv was generated using the old Xcode, so I re-compiled the opencv with the new Xcode, and my project was compiled correctly.

Library not found OpenCV

I'm on mac 10.7.5, using xcode 4.6.2 and working with the OpenCV 2.4.3 library. I went through the process of making the build directory with the cmake files in terminal and did the download.
I added the .dylib files in Xcode and changed the header path, changed C++ Library to libstdc++, but when I compiled I got this error :
ld: library not found for -lopencv_calib3d.2.4.3
clang: error: linker command failed with exit code 1
I have libopencv_calib3d.2.4.3.dylib added in the project so I have no idea what else it needs.Any ideas?
If your "make back-end" is Cmake you should stick to using it. Local config changes in Xcode can "secretly" be overwritten when the cmake is rerun (which for example happens after you make changes to it) creating weird build errors and forcing you to remember all the manual changes you made.
Your problem seems to be that the generated project doesn't seem to know where to look for opencv.
Assuming you installed opencv using macports you should add a line saying
link_directories(/opt/local/lib)
to your CMakeLists.txt. (if you installed it using brew, or compiled it manually just replace /opt/local/lib for /usr/local/lib or the path to your compiled libraries)
Also make sure to link against opencv_calib3d instead of opencv_calib3d.2.4.3 (unless you have a very particular reason for bypassing this, but that usually means that something else is weird in the setup :) )
Final pointer that you might already know of: As you are already using Cmake you should add the libraries to link against using TARGET_LINK_LIBRARIES(...) in Cmake rather than manually adding them in Xcode (referring to my previous argument).

Qt, Google BreakPad and MacOs

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.

Resources