ARM Platform Compilation Error - arm

I am trying to compile the NAS NPB benchmarks on ARM 64 platform running
Ubuntu 14.04, using MVAPICH 2.1. I keep getting an error
"/usr/bin/ld: ../common/print_results.o: Relocations in generic ELF (EM: 62)
/usr/bin/ld: ../common/print_results.o: Relocations in generic ELF (EM: 62)
../common/print_results.o: error adding symbols: File in wrong format
"
While trying to compile these benchmarks using mpif77 and mpicc. Can anybody help me resolve this error?
Thanks.

Related

Cross Compiling for x64 on ARM (Apple Silicon)

It is definitely possible to target Intel when compiling on an Apple Silicon (ARM64) system, as Xcode does that all the time when building universal bundles of an app. However, I am unable to replicate this compiling a C program with make (specifically Stockfish).
What I've tried
I'm invoking make like so: make build ARCH=x86-64-modern COMP=clang (the same command works when I substitute x86-64-modern for apple-silicon). I've tried using the gcc compiler, which also worked when targeting the apple-silicon arch.
The problem
The make build command terminates with a bunch of errors, most importantly:
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Above the error is a bunch of lines complaining that a file was built for an "unknown bitcode architecture:
ld: warning: ignoring file <name>.o, lto file was built for unknown bitcode architecture which is not the architecture being linked (x86_64): <name>.o
So, it seems like the compilation phase succeeds, but the linking phase fails due to missing symbols. How would I acquire and provide the missing symbols to ld such that it can link successfully?

CBLAS mac OS X Undefined symbols for architecture x86_64 error

I'm trying different C linear algebra libraries for my projects and now I want to learn BLAS (CBLAS). I am trying to follow the tutorial here. I realised that cblas is already built in the xcode and by adding the flag
gcc foo.c -framework Accelerate
or
gcc foo.c -lcblas
I can remove most of the errors I had before. however there is a final error which I can not find anywhere on the internet.
Undefined symbols for architecture x86_64:
"_printVector", referenced from:
_main in blas1C-63e43d.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 not sure where I'm making the mistake but there are a number of possibilities:
I need to instal BLAS/CBLAS from the netlib website. I actually tried to do this but I could manage to build the library from the source code! it would be great if somebody could make a Homebrew formula. then if the original CBLAS library installed then I need to learn about the gcc flags for compiling and how to link the libraries.
or there are syntax differences between the original CBLAS from netlib and the one built in the xcode and I need to change the code.
thanks for your help in advance.
P.S. I'm trying to compile the codes blas1C.c, blaio.c, blaio.h from the page I mentioned.
edit 1: oh my! I just realised that I have made a horrible mistake. the printVector function missing is not part of CBLAS but a function made by the author of the blog. the only thing I had to do was just to compile the blaio.c file as well. so the correct gcc command should be
gcc blas1C.c blaio.c -lcblas
or
gcc blac1C.c blaio.c -framework Accelerate
That function comes from the blasio.c in the website and declared in blasio.h
You need to build blasio and link to it

s2n library not linking with arm

When I am trying to compile a package on arm64, It gives me the error
hidden symbol 'pthread_atfork' in /usr/lib/aarch64-linux-gnu/libpthread_nonshared.a (pthread_atfokr.oS) is referenced by DSO. fatal link failed:Bad value.
gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-19ubuntu1)
I tried replacing -lpthread with -pthread in make file which of no use. I also tried to cross-compile the package and then run on arm which even resulted in the same error.I have been searching for a solution couldnot find any. The package works well with linux-x86. …
Let me know if you need any more information.
Thanks in advance.
extracting pthread_atfork.o form libpthread.a and including the file pthrea_atfork.o in makefile made s2n work on ARM.

Generate LLVM IR for httpd

I am trying to compile apache2 with LLVM, to generate final binaries in LLVM IR.
I used flto option in compiling and linking and passed "also-emit-llvm" to the linker through clang.
It seems to work for most steps, however I had two concerns
1) Earlier I used LLVM 3.6, whose gold plugin doesn't accept also-emit-llvm, but has emit-llvm only, basically it will emit only elf or llvm. Which the Autotools build system doesn't like. The configure and make script want binaries, while I want llvm. Any solutions to this?
2) So I shifted to LLVM 3.5.2, the build process goes well, I can generate both httpd.bc and httpd elf binaries, but the linker doesn't want to link for modules (it was able to link for binaries)
Specifically, I get this error
`
/usr/share/apr-1.0/build/libtool --silent --mode=link /home/rbhatia/Desktop/llvm-newbuild/bin/clang -pthread -flto -o mod_authn_file.la -rpath /home/rbhatia/Desktop/httpd-2.4.12/llvm/modules -module -avoid-version mod_authn_file.lo
/usr/bin/ld: error: .libs/mod_authn_file.o:1:3: invalid chaenter code hereracter
/usr/bin/ld: error: .libs/mod_authn_file.o:1:3: syntax error, unexpected $end
/usr/bin/ld: error: .libs/mod_authn_file.o: not an object or archive
collect2: error: ld returned 1 exit status
`
I can see that mod_authn_file.o is a valid LLVM IR file which I can disassemble with llvm-dis.
Also, just before this step, the linker is able to link httpd and httpd.bc
Any help on what the error is?
Take a look at
https://github.com/SRI-CSL/whole-program-llvm
we use this tool to build quite large projects into bitcode. Our
biggest so far was FreeBSD 10.0, so size is not usually an issue.
Our travis build check is actually
apache, as is our tutorial. Hope that helps.

Problem using C file and Cocoa classes together

I have imported the ffmpeg and SDL libraries into my Xcode project for a Cocoa application.
My project builds and runs successfully with these libraries when my project contains only Cocoa classes, but when I include a C file in my project, the build fails with one warning and 35 errors:
The warning is:
ld: warning: in /Developer/SDKs/MacOSX10.6.sdk/usr/lib/gcc/powerpc-apple-darwin10/4.2.1/libgcc.a, file was built for unsupported file format which is not the architecture being linked (x86_64)
and the errors:
"___gedf2", referenced from:
_eval_expr in libavcodec.a(eval.o)
_quantize_lpc_coefs in libavcodec.a(lpc.o)
_rc_2pass2_before in libxvidcore.a(plugin_2pass2.o)
"___ledf2", referenced from:
_qp2bits in libavcodec.a(ratecontrol.o)
_get_qscale in libavcodec.a(ratecontrol.o)
"___umodsi3", referenced from:
_vorbis_parse_setup_hdr_codebooks in libavcodec.a(vorbis_dec.o)
_vorbis_parse_setup_hdr_codebooks in libavcodec.a(vorbis_dec.o)
For running the code, these are the configuration settings:
Active architecture: x86_64
Architecture in project setting: Standard (32/64_bit universal)
Mac OS X version: 10.6.3
Xcode version: 3.2.3
Also, the same code is building and running successfully with the same settings on my other system, a Mac Mini.
If anyone has any idea what I am missing then please help. Thanks.
Read the error message carefully (emphasis mine):
ld: warning: in /Developer/SDKs/MacOSX10.6.sdk/usr/lib/gcc/powerpc-apple-darwin10/4.2.1/libgcc.a, file was built for unsupported file format which is not the architecture being linked (x86_64)
Looks like you're mixing PowerPC and Intel libraries somehow. You're compiling for x86_64 but you're picking up a libgcc.a for PowerPC.
Those symbols with all the leading underscores are probably supposed to come from libgcc.a but you're not linking the x86_64 version of libgcc.a so they're missing in action and chaos ensues. Sounds like something in your xcode configuration is confused.

Resources