I met the following error while compiling z3. It seems to be an error for ld. I wonder what I can do to make it compile. It is a problem from the opt branch in git. I am on iMac with OS X 10.9.2 (13C1021)
I am with xcode Version 5.1.1 (5B1008) with xcode-select tools installed to version 2333. I use port with version 2.2.1 with ld installed.
The problem seems to be a linking problem. I am using link loader as: ld64 #136_2+llvm33 (active)
My gcc is gcc (MacPorts gcc48 4.8.2_0) 4.8.2
Thank you very much!
g++ -o z3 shell/datalog_frontend.o shell/dimacs_frontend.o
shell/gparams_register_modules.o shell/install_tactic.o shell/main.o
shell/mem_initializer.o shell/smtlib_frontend.o shell/z3_log_frontend.o api/api.a opt/opt.a parsers/smt/smtparser.a tactic/portfolio/portfolio.a tactic/ufbv/ufbv_tactic.a tactic/smtlogics/smtlogic_tactics.a muz/fp/fp.a muz/duality/duality_intf.a muz/bmc/bmc.a muz/tab/tab.a muz/clp/clp.a muz/pdr/pdr.a muz/rel/rel.a muz/transforms/transforms.a muz/base/muz.a duality/duality.a qe/qe.a tactic/sls/sls_tactic.a smt/tactic/smt_tactic.a tactic/fpa/fpa.a tactic/bv/bv_tactics.a smt/user_plugin/user_plugin.a smt/smt.a smt/proto_model/proto_model.a smt/params/smt_params.a ast/rewriter/bit_blaster/bit_blaster.a ast/pattern/pattern.a ast/macros/macros.a ast/simplifier/simplifier.a ast/proof_checker/proof_checker.a parsers/smt2/smt2parser.a cmd_context/extra_cmds/extra_cmds.a cmd_context/cmd_context.a interp/interp.a solver/solver.a tactic/aig/aig_tactic.a math/subpaving/tactic/subpaving_tactic.a nlsat/tactic/nlsat_tactic.a tactic/arith/arith_tactics.a sat/tactic/sat_tactic.a tactic/core/core_tactics.a math/euclid/euclid.a math/grobner/grobner.a parsers/util/parser_util.a ast/substitution/substitution.a tactic/tactic.a model/model.a ast/normal_forms/normal_forms.a ast/rewriter/rewriter.a ast/ast.a math/subpaving/subpaving.a math/realclosure/realclosure.a math/interval/interval.a math/simplex/simplex.a math/hilbert/hilbert.a nlsat/nlsat.a sat/sat.a math/polynomial/polynomial.a util/util.a -lpthread -fopenmp
0 0x1079c1a68 __assert_rtn + 144
1 0x107a3bccd mach_o::relocatable::Parser<x86_64>::parse(mach_o::relocatable::ParserOptions const&) + 1039
2 0x107a2b899 mach_o::relocatable::Parser<x86_64>::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 313
3 0x107a290f0 mach_o::relocatable::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 208
4 0x107a18797 archive::File<x86_64>::makeObjectFileForMember(archive::File<x86_64>::Entry const*) const + 795
5 0x107a182b3 archive::File<x86_64>::justInTimeforEachAtom(char const*, ld::File::AtomHandler&) const + 139
6 0x1079c5d46 ld::tool::InputFiles::searchLibraries(char const*, bool, bool, bool, ld::File::AtomHandler&) const + 210
7 0x107a0b772 ld::tool::Resolver::resolveUndefines() + 200
8 0x107a0d6e1 ld::tool::Resolver::resolve() + 75
9 0x1079c1d44 main + 370
A linker snapshot was created at:
/tmp/z3-2014-03-25-110931.ld-snapshot
ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse, file src/ld/parsers/macho_relocatable_file.cpp, line 1555.
collect2: error: ld returned 1 exit status
make: *** [z3] Error 1
It is because we used port and installed gcc and ld and other packages.
Another possibility is that ld was depend on llvm 3.3 rather than llvm 3.4. The problem was solved after updating ld.
Related
I tried to build WebKit GTK on my ARM Mac, but the linking process fails:
Undefined symbols for architecture arm64:
"_u_charDirection_67", referenced from:
WTF::StringImpl::stripWhiteSpace() in libWTFGTK.a(StringImpl.cpp.o)
WTF::StringImpl::simplifyWhiteSpace() in libWTFGTK.a(StringImpl.cpp.o)
WTF::StringImpl::defaultWritingDirection(bool*) in libWTFGTK.a(StringImpl.cpp.o)
int WTF::toIntegralType<int, char16_t>(char16_t const*, unsigned long, bool*, int) in libWTFGTK.a(WTFString.cpp.o)
unsigned int WTF::toIntegralType<unsigned int, char16_t>(char16_t const*, unsigned long, bool*, int) in libWTFGTK.a(WTFString.cpp.o)
long long WTF::toIntegralType<long long, char16_t>(char16_t const*, unsigned long, bool*, int) in libWTFGTK.a(WTFString.cpp.o)
unsigned long long WTF::toIntegralType<unsigned long long, char16_t>(char16_t const*, unsigned long, bool*, int) in libWTFGTK.a(WTFString.cpp.o)
...
"_u_foldCase_67", referenced from:
WTF::StringImpl::foldCase() in libWTFGTK.a(StringImpl.cpp.o)
"_u_strFoldCase_67", referenced from:
WTF::StringImpl::foldCase() in libWTFGTK.a(StringImpl.cpp.o)
"_u_strToLower_67", referenced from:
WTF::StringImpl::convertToLowercaseWithoutLocale() in libWTFGTK.a(StringImpl.cpp.o)
WTF::StringImpl::convertToLowercaseWithLocale(WTF::AtomString const&) in libWTFGTK.a(StringImpl.cpp.o)
"_u_strToUpper_67", referenced from:
WTF::StringImpl::convertToUppercaseWithoutLocale() in libWTFGTK.a(StringImpl.cpp.o)
...
WTF::normalizedNFC(WTF::StringView) in libWTFGTK.a(StringView.cpp.o)
"_unorm2_isNormalized_67", referenced from:
WTF::normalizedNFC(WTF::StringView) in libWTFGTK.a(StringView.cpp.o)
"_unorm2_normalize_67", referenced from:
WTF::normalizedNFC(WTF::StringView) in libWTFGTK.a(StringView.cpp.o)
"_utext_close_67", referenced from:
WTF::setTextForIterator(UBreakIterator&, WTF::StringView) in libWTFGTK.a(TextBreakIterator.cpp.o)
WTF::acquireLineBreakIterator(WTF::StringView, WTF::AtomString const&, char16_t const*, unsigned int, WTF::LineBreakIteratorMode) in libWTFGTK.a(TextBreakIterator.cpp.o)
WTF::TextBreakIteratorICU::TextBreakIteratorICU(WTF::StringView, WTF::TextBreakIteratorICU::Mode, char const*) in libWTFGTK.a(TextBreakIterator.cpp.o)
"_utext_setup_67", referenced from:
WTF::openLatin1UTextProvider(WTF::UTextWithBuffer*, unsigned char const*, unsigned int, UErrorCode*) in libWTFGTK.a(UTextProviderLatin1.cpp.o)
WTF::openLatin1ContextAwareUTextProvider(WTF::UTextWithBuffer*, unsigned char const*, unsigned int, char16_t const*, int, UErrorCode*) in libWTFGTK.a(UTextProviderLatin1.cpp.o)
WTF::uTextLatin1Clone(UText*, UText const*, signed char, UErrorCode*) in libWTFGTK.a(UTextProviderLatin1.cpp.o)
WTF::openUTF16ContextAwareUTextProvider(UText*, char16_t const*, unsigned int, char16_t const*, int, UErrorCode*) in libWTFGTK.a(UTextProviderUTF16.cpp.o)
WTF::uTextCloneImpl(UText*, UText const*, signed char, UErrorCode*) in libWTFGTK.a(UTextProvider.cpp.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/WebKitWebDriver] Error 1
I'm not sure why this is happening. It compiled just fine on my Intel Mac. Any ideas on how to fix this?
I would like to run a bitcode with address sanitizer argument, but I have a problem with that, if I run it, the segmentation fault will happen.
$cat sample.c
#include <stdlib.h>
void *p;
int main() {
p = malloc(7);
return 0;
}
$clang -emit-llvm -fsanitize=address -c -g sample.c
$lli sample.bc
Stack dump:
0. Program arguments: lli sample.bc
0 lli 0x000000010c112d9c llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1 lli 0x000000010c11319e SignalHandler(int) + 192
2 libsystem_platform.dylib 0x00007fff603e2b3d _sigtramp + 29
3 libsystem_platform.dylib 000000000000000000 _sigtramp + 2680280288
4 lli 0x000000010be3ff74 llvm::ExecutionEngine::runStaticConstructorsDestructors(llvm::Module&, bool) + 310
5 lli 0x000000010beac842 llvm::MCJIT::runStaticConstructorsDestructors(bool) + 388
6 lli 0x000000010bb715c6 main + 8866
7 libdyld.dylib 0x00007fff601f7ed9 start + 1
Segmentation fault: 11
Sanitized code requires special runtime support which is implemented in Asan runtime library. lli does not load this library by default (because users normally don't need it) so you need to request it explicitly via LD_PRELOAD=libasan.so.VER. Note libasan.so is GCC convention, for Clang you may need something like libclang_rt.asan.XXX. You can determine full library paths via
GCC_ASAN_PRELOAD=$(gcc -print-file-name=libasan.so)
CLANG_ASAN_PRELOAD=$(clang -print-file-name=libclang_rt.asan-x86_64.so)
I am trying to offload code the GPU using OpenMP 4+ directives. I am using ubuntu 16.04 with GCC 7.2 and for general cases it is working fine. My problem comes when I am trying to offload a code that has a call to the sqrtf function that is defined in "math.h". The troubeling code is this:
#pragma omp target teams distribute \
map(to:posx[:n],posy[:n],posz[:n]) \
map(from:frcx[:n],frcy[:n],frcz[:n])
for (int i = 0; i < n; i++) {
frcx[i] = 0.0f;
frcy[i] = 0.0f;
frcz[i] = 0.0f;
for (int j = 0; j < n; j++) {
float dx = posx[j] - posx[i];
float dy = posy[j] - posy[i];
float dz = posz[j] - posz[i];
float distSqr = dx*dx + dy*dy + dz*dz + SOFTENING;
float invDist = 1.0f / sqrtf(distSqr);
float invDist3 = invDist * invDist * invDist;
frcx[i] += dx * invDist3;
frcy[i] += dy * invDist3;
frcz[i] += dz * invDist3;
}
}
When I try to compile it with:
$ gcc -Wall -O2 -march=native -mtune=native -fopenmp -o nbody_cpu_arrays_parallel_gpu common_funcs.c nbody_cpu_arrays_parallel_gpu.c -lm
unresolved symbol sqrtf
collect2: error: ld returned 1 exit status
mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-7 returned 1 exit status
compilation terminated.
lto-wrapper: fatal error: /usr/lib/gcc/x86_64-linux-gnu/7//accel/nvptx-none/mkoffload returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
How can I make use of square root operations (or other mathematical functions) when offloading OMP code to GPUs?
I encountered a similar issue. https://github.com/bisqwit/cpp_parallelization_examples/blob/master/README.md very helpfully describes the solution:
When offloading, you may get linker problems from math functions if
you do an optimized build. To resolve, add -foffload=-lm
-fno-fast-math -fno-associative-math
For reference, the errors I got with sqrt:
libgomp: Link error log ptxas application ptx input, line 138; error : Label expected for argument 0 of instruction 'call'
ptxas application ptx input, line 138; fatal : Call target not recognized
ptxas <macro util>, line 9; error : Illegal modifier '.div' for instruction 'mov'
ptxas fatal : Ptx assembly aborted due to errors
libgomp: cuLinkAddData (ptx_code) error: a PTX JIT compilation failed
libgomp: Cannot map target functions or variables (expected 2, have 4294967295)
And with sqrtf:
unresolved symbol sqrtf
collect2: error: ld returned 1 exit status
mkoffload: fatal error: x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1 exit status
compilation terminated.
lto-wrapper: fatal error: gcc/x86_64-pc-linux-gnu/7.3.0//accel/nvptx-none/mkoffload returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
clang 9.0 now has the feature that replace the standard math library function with equivelant version of ptx code (nvidia gpu ), which is not yet supported by gcc 9.0.
Compile and run: https://www.hahnjo.de/blog/2018/10/08/clang-7.0-openmp-offloading-nvidia.html
commit of clang : https://reviews.llvm.org/D61399
I'm trying to build a basic FANN (Fast Artificial Neural Network) project on Windows with MinGW. However, whenever I try to link the executable, I run into a bunch of undefined reference to errors. Interestingly, if I don't link the library at all, I get more errors, implying that at least some of the library is working. The code for the file I'm trying to compile and link is:
#include "doublefann.h"
int main() {
const unsigned int num_input_neurons = 9;
const unsigned int num_output_neurons = 1;
const unsigned int num_layers = 3;
const unsigned int num_hidden_neurons = 9;
const float desired_error = (const float) 0;
const unsigned int max_epochs = 500000;
const unsigned int epochs_between_reports = 1000;
struct fann *ann = fann_create_standard(num_layers,
num_input_neurons,
num_hidden_neurons,
num_output_neurons);
fann_set_activation_function_hidden(ann, FANN_SIGMOID_SYMMETRIC);
fann_set_activation_function_output(ann, FANN_SIGMOID_SYMMETRIC);
fann_train_on_file(ann,
"titanic-training.data",
max_epochs,
epochs_between_reports,
desired_error);
fann_save(ann, "titanic.net");
fann_destroy(ann);
return 0;
}
and the command I'm using to compile and link is:
gcc -Wall -Ifann\src\include titanic-train.c -Lfann\bin -lfanndouble -o titanic-train.exe
The errors I'm getting back are:
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0x7f): undefined reference to `fann_set_activation_function_hidden'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0x93): undefined reference to `fann_set_activation_function_output'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0xbf): undefined reference to `fann_train_on_file'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0xd3): undefined reference to `fann_save'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0xdf): undefined reference to `fann_destroy'
c:/fragileprograms/mingw-native/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o: bad reloc address 0x64 in section `.rdata'
c:/fragileprograms/mingw-native/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status
If I don't link the library at all, I instead get:
C:\Users\kunkelwe\AppData\Local\Temp\ccyOO3jL.o:titanic-train.c:(.text+0x67): undefined reference to `fann_create_standard'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0x7f): undefined reference to `fann_set_activation_function_hidden'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0x93): undefined reference to `fann_set_activation_function_output'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0xbf): undefined reference to `fann_train_on_file'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0xd3): undefined reference to `fann_save'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0xdf): undefined reference to `fann_destroy'
c:/fragileprograms/mingw-native/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o: bad reloc address 0x64 in section `.rdata'
c:/fragileprograms/mingw-native/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status
Edit:
As per Haroogan's request, I ran nm fanndouble.lib. The output is rather extensive, so rather than paste it all here, I've made it available via pastebin here: http://pastebin.com/raw.php?i=vybFhEcX
I'm not familiar with nm, but it appears that the missing symbols do exist in the file.
Edit #2:
The contents of doublefann.h are: http://pastebin.com/mrHKJi8C
and the contents of fann.h, which it includes are: http://pastebin.com/gTrHCYAg
Could the problem just be solved by recompiling the library with MinGW?
Edit #3:
Making the changes that Haroogan suggested worked! In addition to those changes, I had to modify the CMakeLists.txt file for FANN by adding:
if (WIN32)
ADD_DEFINITIONS(-DFANN_DLL_EXPORTS)
endif (WIN32)
Then, running cmake -G "MinGW Makefiles" and then mingw32-make in the root of the project produced a file, libdoublefann.dll, that when linked against and included in the directory of the .exe, allowed me, finally, to run my program.
In doublefann.h on the line #116:
#if (_MSC_VER > 1300)
change to:
#if (_MSC_VER > 1300) || defined(__MINGW32__) || defined(__MINGW64__)
Furthermore, on the line #121:
#if defined(_MSC_VER) && (defined(FANN_USE_DLL) || defined(FANN_DLL_EXPORTS))
change to:
#if (defined(_MSC_VER) || defined(__MINGW32__) || defined(__MINGW64__)) && \
(defined(FANN_USE_DLL) || defined(FANN_DLL_EXPORTS))
When I try to compile example1.cpp that comes with Armadillo 2.4.2, I keep getting the following linking error:
/tmp/ccbnLbA0.o: In function `double arma::blas::dot<double>(unsigned int, double const*, double const*)':
main.cpp:(.text._ZN4arma4blas3dotIdEET_jPKS2_S4_[double arma::blas::dot<double>(unsigned int, double const*, double const*)]+0x3b): undefined reference to `wrapper_ddot_'
/tmp/ccbnLbA0.o: In function `void arma::blas::gemv<double>(char const*, int const*, int const*, double const*, double const*, int const*, double const*, int const*, double const*, double*, int const*)':
main.cpp:(.text._ZN4arma4blas4gemvIdEEvPKcPKiS5_PKT_S8_S5_S8_S5_S8_PS6_S5_[void arma::blas::gemv<double>(char const*, int const*, int const*, double const*, double const*, int const*, double const*, int const*, double const*, double*, int const*)]+0x68): undefined reference to `wrapper_dgemv_'
/tmp/ccbnLbA0.o: In function `void arma::blas::gemm<double>(char const*, char const*, int const*, int const*, int const*, double const*, double const*, int const*, double const*, int const*, double const*, double*, int const*)':
main.cpp:(.text._ZN4arma4blas4gemmIdEEvPKcS3_PKiS5_S5_PKT_S8_S5_S8_S5_S8_PS6_S5_[void arma::blas::gemm<double>(char const*, char const*, int const*, int const*, int const*, double const*, double const*, int const*, double const*, int const*, double const*, double*, int const*)]+0x7a): undefined reference to `wrapper_dgemm_'
collect2: ld returned 1 exit status
Can someone help? I manually installed
latest version of BLAS
lapack-3.4.0
boost-1.48.0
latest version of ATLAS
I'm using Ubuntu 11.04 on the MacBook Pro 7,1 model
Thank you so much to osgx! After reading his comment, I took a second look at the README file! It turns out I was missing '-O1 -larmadillo' in the command!
Here's the command I used to get it working:
g++ example1.cpp -o example1 -O1 -larmadillo
Stupid mistake, I know.... It just goes to remind you how important it is to read the README.
The README also mentions:
If you get linking errors, or if Armadillo was installed manually
and you specified that LAPACK and BLAS are available, you will
need to explicitly link with LAPACK and BLAS (or their equivalents),
for example:
g++ example1.cpp -o example1 -O1 -llapack -lblas
I didn't have to include '-llapack -lblas' but maybe this will help anyone else who's having similar problems.
As of 5.0.0 (might also apply to earlier versions)
You actually need -larmadillo, on Fedora 21 -llapack and -lopenblas are not excplicitly necessary anymore.
There's an oddity I just discovered by comparing previously working compilations of code with the very problem of this thread, stressing the involvement of the gnu cc (I'm no expert in this): on my machine compilation success depends on the order of parameters to the gcc/g++ where
g++ infile -o outfile -libarmadillo ... worked, but
g++ -libarmadillo infile -o outfile ... didnt with (almost) the same error as mentioned above.
(hope that helps).