Trying to run a simple program and it fails with the issue
note: ld: framework not found Security
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I tried to do some investigation and I see that chrono 0.4.19 in cargo.toml points to that. Once I remove that dependency, it stays building. I am new to the mac world and have seen various suggestion but I am very much clueless about the issue.
I tried to dockerise it and it works fine then on container, but doesn't on my mac. Can anyone please point me to the correct direction?
Have you tried adding "-framework Security" to the command line arguments when building? "-framework" is an argument that causes the linker (ld) to see out Dylibs in /System/Library/Frameworks defined as "frameworks". They're technically just dynamic libraries, but require this switch since they're put into a versioned bundle (framework_name.framework/framework_name).
Related
I am trying to build a haskell project from Ludum Dare, but whenever I attempt the build I get an error message saying the object file has too many sections. Here is the error:
C:\Users\REDACTED\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.2\lib\../mingw/bin\ld.exe: .stack-work\dist\a3a5fe88\build\HSsingletons-2.7-J1xRPYS9ah3kGEIOoeLuX.o: too many sections (90295)
singletons > C:\Users\REDACTED\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.2\lib\../mingw/bin\ld.exe: final link failed: file too big
-- While building package singletons-2.7 using:
C:\Users\REDACTED\AppData\Local\Temp\stack-5ba10ebdb151d9fa\singletons-2.7\.stack-work\dist\a3a5fe88\setup\setup --builddir=.stack-work\dist\a3a5fe88 build --ghc-options " -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
I am using stack 2.3.3 and Windows 10. The project uses the vulkan library.
I tried adding -opta-mbig-obj, but gcc then failed with error: unrecognized command line option '-mbig-obj'
It looks like you may need to try explicitly using the “large object” file format, which I believe you can do by adding -opta-mbig-obj or -Wa,-mbig-obj to the GHC flags in the project’s build config (package.yaml or .cabal file) to add -mbig-obj to the assembler options. You may also need to add --oformat pe-bigobj-x86-64 to the linker flags, using (I think) -optl--oformat -optlpe-bigobj-x86-64 or -Wl,--oformat,pe-bigobj-x86-64. Are you using a 32-bit MinGW? I would expect MinGW64 to handle this by default. (And I’m not actually sure whether 32-bit supports these flags, so you may need to upgrade anyway.)
Since about a year ago (https://gitlab.haskell.org/ghc/ghc/-/commit/1ef90f990da90036d481c830d8832e21b8f1571b) GHC already uses the -mbig-obj and --oformat,pe-bigobj-x86-64 when assembling and linking on 64 bit MinGW. Adding these flags manually will not help on recent GHC versions.
I was able to replicate this problem for both the sdl2 and vulkan Haskell packages using Stack, however neither of them exhibit this issue when compiled with Cabal (and --enable-split-sections) on Windows; this looks to be a bug in stack.
I import j2objc to my project, but I still get error like Undefined symbols for architecture x86_64: "_OBJC_CLASS_$_Test (public class Test in java source). I found something about wrong linking static library to project (libjre_emul.a). I found possible official solution add to Other Linker Flags flag "-l jre_emul".
Problem is I get error ld: library not found for -l jre_emul what does it mean? How can I fix this?
I tried extended command:
"-l jre_emul -ObjC -force_load ${PROJECT_DIR}/lib/libjre_emul.a"
Error library not found still remains. Any idea?
Thanks.
I think you have a spelling error in your other linker flags. Try to use something like:
-l"jre_emul"
The -force_load flag is no longer necessary. The issue is that the linker can't find the library because the path to it is not defined in your project (it's probably not in ${PROJECT_DIR}/lib, unless you explicitly put it there). The Update the Build Settings wiki section describes how to add the J2ObjC distribution path to your project's Library Search Paths build setting.
I'm working in OSX and I'm attempting to run a make file and when I try I get the following:
ld: library not found for -lgsl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [harm] Error 1
Earlier I found out the I needed to get the gsl library and I used mac ports and typed:
sudo port install gsl
into my command line window and it seemed to isntall okay. Is the missing lgsl not configured correctly or does it not come with gsl? I tried googling lgsl but didn't get much. I've only been at programming a few days and I don't know if I was supposed to set a path, or even really how to do that.
Thanks for any help you guys could offer.
I just wanted to say that I had the exact problem on OSX. Rather than setting an environment variable, I used an additional compiler flag -L/opt/local/lib, which then lets one use -lgsl. I reference this answer.
I got the same issue and here is how I fixed it:
export LIBRARY_PATH=/usr/local/Cellar/gsl/1.16/lib/
I had previously installed gsl using:
brew install gsl
You need to add the path for where the macports installed the gsl library to your LD_LIBRARY_PATH environment variable (or most likely into the build script environment). I believe macports stores things in /opt/local/lib
I have another OSX application problem. I want to bundle in my final application several dylibs, all of them needed by the application and by other dylibs.
I change its references using the install_name_tool, but some of the libraries couldn't be changed properly, having this error:
install_name_tool: changing install names or rpaths can't be redone for: aLibrary.dylib (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)
So I added the headerpad_max_install_names option flag on the linker flags of the xcode project (Project Properties-Build Settings-Linking-Other Linker Flags). Also I verified in the build log, if the option flag was included, and the option flag was included properly.
But still having the same error in the last dylibs.
Is there any way to bundle all the libraries needed in a unique Framework? Or am I doing something wrong in the building process?
Hope I'm clear with the main problem.
Thanks!
I had this same problem, using C++ and Code::Blocks, and I fixed it by switching from g++ to clang++
I'm on freebsd and trying to run uhd from: http://www.ettus.com/download This should normally run under freebsd, but I encounter problems when I try to build it like specified here:
http://www.ettus.com/uhd_docs/manual/html/build.html#build-instructions-unix
I get:
[ 73%] Building CXX object examples/CMakeFiles/benchmark_rx_rate.dir/benchmark_rx_rate.cpp.o
Linking CXX executable benchmark_rx_rate
../lib/libuhd.so.003.000: undefined reference to `uhd::set_thread_priority(float, bool)'
collect2: ld returned 1 exit status
*** Error code 1
Now this seems to be a linker error, but how to get rid of it? I tried setting the path using ldconfig but this hasn't changed a thing. Maybe some of you have an idea where I could continue searching.
If i get it right, libuhd get's built earlier by this CMake script. If it's true, this error indicates bug in their CMakeLists.txt files.
It looks like you are building examples of using libuhd. I doubt you are need them. So, either look for switches in your CMakeCache.txt and regenerate Makefiles or hack CMakeLists.txt to not include examples dir.
Another thing you may try - set CMAKE_EXE_LINKER_FLAGS to -L/usr/local/include.
This is a perfect situation for creating a FreeBSD port. Since FreeBSD has its own consistent filesystem layout, compiler and linker flags often need to be modified (as noted by arrowdodger) slightly.
The ports system is a framework for persistently capturing those configuration changes and making any software package as easy to install as typing the commands:
cd /usr/ports/category/application-name && make install clean
In a perfect world, you would create the UHD port, submit it for review and addition to the tree. If you need help learning how to do that, the FreeBSD Porter's Handbook and the freebsd-ports mailing list are excellent resources.