MathGL and FLTK cmake on Mac OS X: Not finding symbols - macos

I'm having trouble getting cmake to find and link the necessary libraries for MathGL and FLTK.
Linking CXX executable filter.app/Contents/MacOS/filter
Undefined symbols for architecture x86_64:
"_mgl_create_graph_fltk", referenced from:
_main in filter.cpp.o
"_mgl_fltk_thr", referenced from:
_main in filter.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I'm using the default FLTK finder cmake script, which comes with brewed CMake 3.0.2 on OS X.
Here are the relevant portions of my CMakeLists.txt:
find_package(MathGL 2.2 REQUIRED)
include_directories(${MATHGL2_INCLUDE_DIRS})
find_package(FLTK REQUIRED)
include_directories(${FLTK_INCLUDE_DIR})
#link_directories(${FLTK_LIBRARIES}) # tried it with and without this line
add_executable(filter ${BUNDLE_MODE} src/filter.cpp)
target_link_libraries(
filter
${MATHGL2_LIBRARIES}
${FLTK_LIBRARIES}
${OPENGL_LIBRARIES}
)
If I uncomment the link_directories line, I get an additional error:
CMake Warning (dev) at CMakeLists.txt:73 (link_directories):
This command specifies the relative path
-framework Carbon -framework Cocoa -framework ApplicationServices -lz
as a link directory.
Policy CMP0015 is not set: link_directories() treats paths relative to the
source dir. Run "cmake --help-policy CMP0015" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.
It seems like it's trying to do -L-framework Carbon, etc., when these are already being linked via the BUNDLE_MODE var in add_executable. I suspect this particular FindFLTK2.cmake was not properly tested on OS X, and am not quite sure how to fix it.
Can anyone suggest a simple fix?

Found the problem. It seems that the instructions in both FindMathGL.cmake and FindMathGL2.cmake were incorrect. Here is the corrected cmake instruction set. This also works for Qt, not just FLTK.
find_package(MathGL2 REQUIRED COMPONENTS FLTK) # or Qt instead of FLTK
include_directories(${MATHGL2_INCLUDE_DIRS})
add_executable(filter ${BUNDLE_MODE} src/filter.cpp) # leave out BUNDLE_MODE if not on Darwin
target_link_libraries(
filter
${MATHGL2_LIBRARIES}
${OPENGL_LIBRARIES}
)
Much easier.

Related

Compiling GitHub project runs gcc with -static option on Mac and fails, how do I get around that?

I want to compile the following project that's hosted on GitHub. I'm on MacOs High Sierra 10.13.5.
When I run make on the solver directory, it gives the following error after running gcc with the -static option:
g++ -o dapcstp src/bbnode.o src/bbtree.o src/bounds.o src/cputime.o
src/heur.o src/inst.o src/main.o src/options.o src/prep.o
src/procstatus.o src/sol.o src/stats.o src/timer.o src/util.o -static -
lboost_timer -lboost_system -lboost_chrono -lboost_program_options -
lboost_filesystem
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [dapcstp] Error 1
In the answer to ld: library not found for -lcrt0.o on OSX 10.6 with gcc/clang -static flag it says the following:
This option will not work on Mac OS X unless all libraries (including libgcc.a) have also been compiled with -static. Since neither a static version of libSystem.dylib nor crt0.o are provided, this option is not useful to most people.
Is there a way I could circumvent this limitation and compile the project correctly on Mac ?
Looking at the project, the -static option is superfluous and counterproductive (even on system where static linking is supported). You can just remove it.

Issue when linking lapack and fftw3 libraries

I have a Fortran 90 program which uses lapack subroutines, and is successfully running on my Ubuntu system. Now I want to run it on Mac (OS X Version 10.11.4). I am using gfortran compiler as a part of gcc, installed from homebrew repositories, and lapack library, installed in /usr/local/lib/.
When I try to compile my code, I get the following error:
gfortran my_prog.f90 -L/usr/local/lib/ -llapack
Undefined symbols for architecture x86_64:
"_daxpy_", referenced from:
_zggbal_ in liblapack.a(zggbal.o)
...
"_ztrmv_", referenced from:
_zlarft_ in liblapack.a(zlarft.o)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
After some google search I understood that the problem is because the linking. When I compile it like this, everything works well:
gfortran my_prog.f90 -llapack
Also when llapack from framework accelerate is used, the compiler doesn't complain.
gfortran my_prog.f90 -framework accelerate
The libraries are of x86-64 architecture:
lipo -info *.a
input file libfftw3.a is not a fat file
input file liblapack.a is not a fat file
Non-fat file: libfftw3.a is architecture: x86_64
Non-fat file: liblapack.a is architecture: x86_64
LAPACK is not the only one which gives me an error, later the same problem appears with FFTW3. Could you please give me a hint to the solution to this problem?
FFTW is not part of the accelerate framework. If you want to use it, you need to add -lfftw3 to the compile options as well.
If the libraries are not in the default LIBRARY_PATH, you might need to specify -L/path/to/fftw/libs as well. The same holds for the include path if you are using its modules -I/path/to/fftw/includes.
Note that the vDSP part of the library also provides FFT implementations. You might not need FFTW at all.

Xcode "ld: library not found [...] for architecture x86_64"

I want to include libgpg-error and libgcrypt in my swift-project and created the following module.modulemaps:
libgpgerror:
module libgpgerror {
header "/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgpgerror/gpg-error.h"
link "'/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgpgerror/libgpgerror-1.21.dylib'"
export *
}
libgcrypt:
module libgcrypt {
header "/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgcrypt/gcrypt.h"
link "'/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgcrypt/libgcrypt-1.6.5.dylib'"
export *
}
I also added the "Swift Compiler - Search Path/Import Paths": /Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/** to both project and target.
The modules are found, the paths are correct.
However if I want to compile the project I get the following error:
ld: library not found for -l'/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgpgerror/libgpgerror-1.21.dylib' for architecture x86_64
But if I do
file /Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgpgerror/libgpgerror-1.21.dylib
I get the output
/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgpgerror/libgpgerror-1.21.dylib: Mach-O 64-bit dynamically linked shared library x86_64
So it seems the library is in the correct place and also has the correct architecture.
Edit
I found a workaround: I removed the link-directive from the modulemaps and linked the libraries manually; this seems to work. But why?
module libgpgerror {
header "/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgpgerror/gpg-error.h"
export *
}
The link directive specifies only the name of the linked library. That is it should specify the suffix of the linker flag for the library. It appears that the directive take "-l" and concatenates the name to produce the linker flag.
This means that the correct way to specify your module map is as follows.
module CGcrypt {
header "/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgcrypt/gcrypt.h"
link "gcrypt"
export *
}
This will generate the linker flag -lgcrypt which is the correct linker flag.
However, there is another problem which is that the linker needs to be able to find the dylib file for gcrypt and by default it only looks on certain paths. Those paths can be found by running clang -Xlinker -v. The output for me looks like this:
tylercloutier$ clang -Xlinker -v
#(#)PROGRAM:ld PROJECT:ld64-264.3.101
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
Library search paths:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib
... more stuff ...
Now I'm not sure, but I suspect that the normal search paths are probably
/usr/lib
/usr/local/lib
but I think that Xcode has altered my search paths to point the the MacOSX10.11.sdk/usr/lib, which, incidentally, has basically the same set of files as /usr/lib (they are not symlinked). Indeed, in El Capitan, because of System Integrity Protection even sudo will not allow you to edit /usr/lib.
Thus the problem that I am having is that even though I've installed my libraries to /usr/local/lib, clang is not able to link them. In order to fix that I can specify the search path explicitly.
swift build -Xlinker -L/usr/local/lib/
And we're off to the races. I can even generate an xcodeproj which will have the appropriate linker flag already set in Other Linker Flags.
swift build -Xlinker -L/usr/local/lib/ --generate-xcodeproj
If you leave out the link directive in the module map file, you can specify it as a flag:
module CGcrypt {
header "/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgcrypt/gcrypt.h"
export *
}
Like so
swift build -Xlinker -L/usr/local/lib/ -lgcrypt
How to change the default library search paths, I don't know. But it would be great if someone else could shed light on this matter!

Clang Code Coverage - Mac OS X - Linker Error

I could successfully get code coverage information on our C++ code base on Linux using the GCC features of GCOV and the LCOV tool.
But I am having trouble in Mac OS X.
As Apple does not have the classic GCC compiler anymore, and we fear that the LLVM-GCC compiler would one day disappear too (LLVM-GCC is not even available as an option in Xcode 5.0) - we have decided to use Clang to compile our code.
While using the Clang compiler I am passing in these flags -->
-g -fprofile-arcs -ftest-coverage to generate the Code Coverage information.
I can see the .gcno files getting generated along with the object files.
When it comes to linking - "-lgcov” linker flag which works with GCC is not supported.
The code coverage on Clang / LLVM is now supported by the “profile_rt” library.
Unfortunately it’s a bit tricky to find this library because Apple for whatever reason decided not to include it in the default library path. Instead you’ll have to manually navigate to /usr/lib/ to link against it:
And as specified am linking against libprofile_rt.a library.
But i have linker issues.
But i keep getting these linker errors
Undefined symbols for architecture x86_64:
"_llvm_gcov_init", referenced from:
___llvm_gcov_init in Iso9660Reader.o
___llvm_gcov_init in AutoExtractCreator.o
___llvm_gcov_init in TempFilePath.o
___llvm_gcov_init in TempPath.o
___llvm_gcov_init in ReadDirectory.o
___llvm_gcov_init in OpenDirectory.o
___llvm_gcov_init in SpltPath.o
...
ld: symbol(s) not found for architecture x86_64
I also tried linking against the dynamic library - libprofile_rt.dylib found in
/usr/lib folder - But i still get the same issue.
This is Clang Version running on Mountain Lion.
clang --version
Apple LLVM version 5.0 (clang-500.2.75) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
I also have Xcode 5.0 and Developer Tools installed.
I solved this.
I was missing the following Linker Flags
-Wall -fprofile-arcs -ftest-coverage
Other Linker Flag -fprofile-arcs fixes the issue for me.
Build Settings > Other Linker Flags > -fprofile-arcs
The above answer did not work for me on OSX Yosemite (10.10.3) with Xcode 6.3.1. It seems that Apple moved these libraries around. I was able to get it to work with the following compile options:
-lclang_rt.profile_osx
-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0/lib/darwin

How can I compile and use Haskell as a C library using Xcode LLVM compiler?

I want to set up a project to take my .hs code, and my main .c program, and result in a statically linked executable through the use of LLVM compiler. I can get things working via ghc command line options to build a .hs, produce the stubs, and compile and link a driver application using ghc entirely. However, I get various issues within Xcode.
My first issue was that I of course need to use 32 bit compiling environment in Xcode. That solved, I had to fiddle with paths to explicitly include the HsFFI.h. That solved, I get a linker error:
Ld "build/Debug/FFI Test.app/Contents/MacOS/FFI Test" normal i386
cd "/Users/rcl/TestXCodeProjects/FFI Test"
setenv MACOSX_DEPLOYMENT_TARGET 10.6
/Developer/usr/bin/clang -arch i386
-isysroot /Developer/SDKs/MacOSX10.6.sdk
"-L/Users/rcl/TestXCodeProjects/FFI Test/build/Debug"
"-L/Users/rcl/TestXCodeProjects/FFI Test/FFI Test"
"-F/Users/rcl/TestXCodeProjects/FFI Test/build/Debug"
-filelist "/Users/rcl/TestXCodeProjects/FFI Test/build/FFI Test.build/
Debug/FFI Test.build/Objects-normal/i386/FFI Test.LinkFileList"
-mmacosx-version-min=10.6 -framework Cocoa
"/Users/rcl/TestXCodeProjects/FFI Test/FFI Test/ForeignExportCost.a"
-o "/Users/rcl/TestXCodeProjects/FFI Test/build/Debug/FFI Test.app/
Contents/MacOS/FFI Test"
Undefined symbols for architecture i386:
"_hs_init", referenced from:
-[FFI_TestAppDelegate applicationDidFinishLaunching:] in FFI_TestAppDelegate.o
"_simpleFunction", referenced from:
-[FFI_TestAppDelegate applicationDidFinishLaunching:] in FFI_TestAppDelegate.o
"_hs_exit", referenced from:
-[FFI_TestAppDelegate applicationDidFinishLaunching:] in FFI_TestAppDelegate.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The "simpleFunction" is in "ForeignExportCost.a" library which I compile using ghc like this:
ghc -no-hs-main -fPIC -c ForeignExportCost.hs
ghc -no-hs-main -shared ForeignExportCost.o -o ForeignExportCost.a
What am I missing or doing wrong?
Ugh - it looks like the answer to my question is detailed here, telling me how to painfully add a ton of .a's to my project. And this blog post gave some helpful tips to getting on the way.
Although if someone tells me "hey wait, there's an easier way than iteratively figuring out failed deps" that would be awesome. Because I want to reuse this framework several times and this is a real pain of a way to get things up and going!

Resources