I'm trying to get mpich 3.0.4 installed right on my system (Mac OS X 10.10.2) from the shell (which I use with tcsh). So I tar-ed it, then configured (./configure --prefix=$DIR/mpich) it, and then entered make.
All seemed to go well, but at the end, I've got those two warnings appearing :
ld: warning: directory not found for option '-L./src/mpl'
ld: warning: directory not found for option '-L./src/openpa/src'
and when I test it later (with a test from the tutorial, so the error does not come from here), it prints the following :
ld: targeted OS version does not support use of thread local variables in _MPIU_Thread_CS_enter_lockname_recursive_impl_ for architecture x86_64
I would be very grateful for any kind of advice (having in mind that I am rather a beginner).
Thank you !
edit : for information, I'm using this tutorial : http://www2.mmm.ucar.edu/wrf/OnLineTutorial/compilation_tutorial.php#STEP2
This immensely frustrating bug hit several platforms, including MVAPICH. Fortunately, it has been fixed -- though I can't tell you exactly how:
http://trac.mpich.org/projects/mpich/ticket/1840
http://mailman.cse.ohio-state.edu/pipermail/mvapich-discuss/2013-April/004359.html
If you try 3.1.4 this problem should go away.
Related
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).
I'm working on touching up homebrew's (OS X package manager) llvm formula. Unfortunately, something about the parts I added broke the build in a way I just cannot figure out.
tl;dr ld asks for a library containing a _wordexp symbol for iOS simulator, and I have absolutely no clue where it is, if it exists
Compilation consistently fails for me when the compiler is attempting to link the address sanitizer dylib for iOS Simulator.
Reproduction steps (OS X only as far as I know, don't have *nix systems handy):
install homebrew if it isn't already installed
replace homebrew's llvm formula with the WIP one above
Run brew install llvm --with-clang --with-lldb --verbose --debug
wait for the build to fail and ask you what to do
Drop into a debug shell
cd to projects/compiler-rt/lib/asan/CMakeFiles/clang_rt.asan_iossim_dynamic.dir
add the following line to link.txt
-Wl,-syslibroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk
go back up to asan
Run make
At this point on my machine, something like this pops up:
Undefined symbols for architecture x86_64:
"_wordexp", referenced from:
_wrap_wordexp in asan_interceptors.cc.o
substitution_wordexp in asan_interceptors.cc.o
(maybe you meant: _wrap_wordexp)
ld: symbol(s) not found for architecture x86_64
I thought that it was just a matter of adding another folder to the linker search path. Turns out it isn't that simple:
wordexp.h is in <path-to-iPhoneSimulator.sdk>/usr/include, but running
find . -type f -name "*.dylib" -print0 | xargs -0 nm | grep -n "T _wordexp" -B <large number> | less
in Xcode-beta.app showed that the only .dylibs in Xcode that exported a _wordexp symbol were in the WatchSimulator.platform folder
Running the same command in /usr showed that 3 libraries in /usr/lib/system exported _wordexp (libsystem_asl, libsystem_c, and libsystem_blocks), but the linker doesn't seem to care when I add /usr/lib/system to the search path even when the code is the x86_64 code it wants, and the corresponding dylibs I found for other platforms didn't contain _wordexp
Googling about about this particular symbol missing turned up mostly stuff about Apple implementing wordexp() with Perl
I think I remember seeing something in the llvm-dev mailing list archives about *BSD/OSX not implementing wordexp, but the header file is definitely there, wordexp() shows up in the manpages, and the functions declared in the header file seem to work just fine when compiling for OSX
The symbol is not in the libc++(abi) dylibs compiled earlier in the build
Every other part of the build compiles just fine except for the asan folder and its parents
What am I missing? Given that this error does not seem to be particularly common, there could be a chance it's my machine, but I'm hoping the chances are pretty low, because I wiped and reinstalled my computer this weekend.
(OS X 10.11, Xcode/CLT 7.1, mid-2012 Retina pro)
If more info is needed I'll be happy to provide it.
Edit 1: Simplified link.txt fix. Turns out setting sysroot for clang++ doesn't do so for ld
Turns out the error was a result of the way homebrew processed compiler flags. That and a few other problems have been fixed since, so this probably isn't too useful any more.
For those curious about how exactly this broke, homebrew tries to change compiler flags to suppress warnings and create a more consistent building experience. One of these changes was to remove any -isysroot or -system flags, because that was added by homebrew itself at a later stage. Unfortunately, homebrew assumed that only the OS X SDK would be used, so when the build expected to build something with the iPhone simulator SDK it was pointed to the OS X SDK.
After updating a new Mac (OS 10.8), my colleague and I are unable to compile a C++ code that we have been using. We are not experienced with coding and would be very grateful if someone could point us in the right direction at a newbie level. We see that there are many posts on this type of error, but if any of them are relevant, we don't see how, except that the posts all seem to say that this is likely to be a linker problem.
When we do "make," there is a lot of output. The first part is this:
Us$ make g++ -o ourProg 1.o main.o 2.o -L/Prog/libraries
-L/Prog/support_libraries -l_codea -l_codeb ... Undefined symbols for architecture x86_64:
The final part is this:
ld: symbol(s) not found for architecture x86_64 clang: error: linker
command failed with exit code 1 (use -v to see invocation) make: ***
[ourProg] Error 1
Unfortunately, a condition of using the code is that we can't post it online, so it may be that there is not enough information that anyone can help.
The thing that stands out for me is that it looks like Clang is being used for linking, even though we have specifically said we want g++ to be used for compiling. In the makefile, we have said:
CC = g++
(Answered by the OP in a question edit. Converted to a community wiki answer. See Question with no answers, but issue solved in the comments (or extended in chat) )
The OP wrote:
Thanks everyone; the problem is solved. I'm not sure whether to indicate this anywhere in the question, sorry. I'd like to describe how we fixed it, in case any other newbies are having trouble understanding the more sophisticated posts on this problem!
First, we followed the advice here by updating to OS 10.9 and installing the new command line tools. Then we came across a forum post that discussed where the linking problem comes from. In OS 10.8 and 10.9, the C++ default standard libraries are different. So we first added a new include to our makefile:
/usr/bin/clang++
Then we added to the compiler flag line and the libraries:
-stdlib=libstdc++
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'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.