Sage is supposed to be able to create compiled code using Cython. I have never been able to get this to work. The problem appears to be with my Sage installation, since compiling fails on the included example. I don't believe I did anything special during installation, but apparently I something wrong. The Sage tutorial says
In order to make your own compiled Sage code, give the file an .spyx extension (instead of .sage). If you are working with the command-line interface, you can attach and load compiled code exactly like with interpreted code (at the moment, attaching and loading Cython code is not supported with the notebook interface). The actual compilation is done “behind the scenes” without your having to do anything explicit. See $SAGE_ROOT/examples/programming/sagex/factorial.spyx for an example of a compiled implementation of the factorial function that directly uses the GMP C library. To try this out for yourself, cd to $SAGE_ROOT/examples/programming/sagex/, then do the following:
sage: load "factorial.spyx"
When I try I get the following message:
Compiling ./factorial.spyx...
Error compiling cython file:
Error compiling ./factorial.spyx:
running build
running build_ext
building '_home_oliver_Desktop_sage_4_7_1_linux_32bit_ubuntu_10_04_lts_i686_Linux_examples_programming_sagex_factorial_spyx_0' extension
creating build
creating build/temp.linux-i686-2.6
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local/include/csage/ -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local/include/ -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local/include/python2.6/ -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local/lib/python2.6/site-packages/numpy/core/include -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/devel/sage/sage/ext/ -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/devel/sage/ -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/devel/sage/sage/gsl/ -I. -I/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local/include/python2.6 -c _home_oliver_Desktop_sage_4_7_1_linux_32bit_ubuntu_10_04_lts_i686_Linux_examples_programming_sagex_factorial_spyx_0.c -o build/temp.linux-i686-2.6/_home_oliver_Desktop_sage_4_7_1_linux_32bit_ubuntu_10_04_lts_i686_Linux_examples_programming_sagex_factorial_spyx_0.o -w -O2
creating build/lib.linux-i686-2.6
gcc -pthread -shared build/temp.linux-i686-2.6/_home_oliver_Desktop_sage_4_7_1_linux_32bit_ubuntu_10_04_lts_i686_Linux_examples_programming_sagex_factorial_spyx_0.o -L/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local//lib/ -L/home/wstein/build/sage-4.7.1/local/lib -lmpfr -lgmp -lgmpxx -lstdc++ -lpari -lm -lcurvesntl -lg0nntl -ljcntl -lrankntl -lgsl -lgslcblas -latlas -lntl -lcsage -lpython2.6 -o build/lib.linux-i686-2.6/_home_oliver_Desktop_sage_4_7_1_linux_32bit_ubuntu_10_04_lts_i686_Linux_examples_programming_sagex_factorial_spyx_0.so -L/home/oliver/Desktop/sage-4.7.1-linux-32bit-ubuntu_10.04_lts-i686-Linux/local//lib
/usr/bin/ld: cannot find -lstdc++ collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
Any suggestions? Thanks.
Per DSM's comment, I reinstalled g++-multilib, and now everything works fine.
Related
I've been trying to convert a cpp file to wasm without emscripten recently and I've been running with some errors, for example, when I run these commands:
clang++ --target=wasm32 -nostdlib -O3 -o public/main.o -c src/*.cpp
wasm-ld --no-entry --export-all --lto-O3 --allow-undefined --import-memory public/main.o -o public/main.wasm
it gives me this error:
wasm-ld: error: unknown file type public/main.o
Here are the versions of clang and lld that I currently have:
clang version 12.0.1
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nix/store/jp4r5v8pla63qam5w34jvfyfmq8p74am-clang-12.0.1/bin
LLD 12.0.1
Also, I'm running the code on replit
Thank you
Ok, with this commands it works :D
clang++ --target=wasm32 -emit-llvm -c -S -o public/files/main.ll src/main.cpp
llc -march=wasm32 -filetype=obj -o public/files/main.o public/files/main.ll
wasm-ld --no-entry --export-all -o public/main.wasm public/files/main.o
The only thing is that you need to create some new files (main.ll and main.o) but it doesn't matter.
The place where I obtained the solution is here: https://surma.dev/things/c-to-webassembly/index.html
It was really useful
I have just started experimenting with XDP in an VM. I tried to build for bpf and I face an error, how can I resolve this?
# clang -O2 -Wall -target bpf -c all_dropper.c -o dropper.o
error: unknown target triple 'bpf', please use -triple or -arch
This issue is resolved, I had to upgrade the clang version to 3.9.
I'm trying to build a UDF library using rake:
task :compile do
system("gcc -L/usr/local/lib -lgmp -lpaillier `mysql_config --cflags` -c -fPIC #{FILE}.c")
system("ar -x /usr/local/lib/libpaillier.a")
system("gcc -shared *.o -L/usr/lib/x86_64-linux-gnu/ -lgmp -o #{LIBFILE}")
system("sudo mv #{LIBFILE} /usr/lib/mysql/plugin/")
end
but I'm getting this error:
/usr/bin/ld: paillier.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
paillier.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Here:
gcc -L/usr/local/lib -lgmp -lpaillier `mysql_config --cflags` -c -fPIC #{FILE}.c
you are compiling an object file whose name will be the value of #{FILE}.o -
let's say it is aa.o - and you are compiling it with Position-Independent Code
(-fPIC). Your linker flags:
-L/usr/local/lib -lgmp -lpaillier
serve no purpose here and are ignored because no linking is being done.
Here:
ar -x /usr/local/lib/libpaillier.a
you are extracting all of the object files from the static library /usr/local/lib/libpaillier.a. There is in fact just
one object file in the library, paillier.o
Here:
gcc -shared *.o -L/usr/lib/x86_64-linux-gnu/ -lgmp -o #{LIBFILE}
you are building a shared library whose name will be the value of #{LIBFILE}
- let's say it is libfoo.so - linking the object files aa.o, paillier.o,
plus libgmp.
Extracting the object file paillier.o from libpaillier.a to link it with libfoo.so
achieves nothing different from not extracting it and simply linking
libpaillier.a itself, i.e nothing different from:
gcc -shared #{FILE}.o -L/usr/local/lib -lpaillier -L/usr/lib/x86_64-linux-gnu/ -lgmp -o #{LIBFILE}
And the linkage library paths:
-L/usr/local/lib -L/usr/lib/x86_64-linux-gnu/
are superflous because both of those paths are default linker search paths on your system.
But a shared library must be built entirely from PIC object code. aa.o was compiled
with -fPIC, in your first step. However, paillier.o was not not. So the linkage fails and the linker
advises you that paillier.o must be recompiled with -fPIC.
So do that:-
Delete your existing /usr/local/lib/libpaillier.a and /usr/local/include/paillier.h
Go back to your libpaillier source directory (where you built it first time).
Clean it up:
$ make clean
Reconfigure the autotools build system to compile PIC code:
$ ./configure CFLAGS=-fPIC [and whatever other options you used before]
Rebuild:
$ make
Reinstall:
$ sudo make install
Now you again have a header /usr/local/include/paillier.h and
a static library /usr/local/lib/libpaillier.a but this time
the paillier.o in the library is PIC code.
Then you can build your plugin with:
task :compile do
system("gcc `mysql_config --cflags` -c -fPIC #{FILE}.c")
system("gcc -shared #{FILE}.o -lpaillier -lgmp -o #{LIBFILE}")
system("sudo mv #{LIBFILE} /usr/lib/mysql/plugin/")
end
I am trying to configure and make install package nap6.4 for tcl, but it fails in during "make" with the following error:
cc -shared -o libnap6.4.so cart_proj.o eval_tree.o function.o geometry.o land_flag.o land_flag_i.o linsys.o nap.o napChoice.o napDyad.o napDyadLib.o napImgNAO.o napInit.o napLib.o napMonad.o napParse.tab.o napParseLib.o napPolygon.o napSpatial.o nap_get.o nap_hdf.o nap_netcdf.o nap_ooc.o triangulate.o -L/usr/local/lib -lnetcdf -L/usr/local/lib -lmfhdf -ldf -ljpeg -lz -L/usr/local/lib -lproj -L. -ltclstub8.4 -ltkstub8.4 -lieee -lm -lX11
/usr/bin/ld: /usr/local/lib/libmfhdf.a(mfsd.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with - fPIC
/usr/local/lib/libmfhdf.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [libnap6.4.so] Error 1
So I was told to recompile with -fPIC, which I did in the following way from the terminal:
export CFLAGS=-fPIC
./configure --prefix/lib/ActiveTcl --enable-shared
make
but this does not work. I have also tried with --disable-shared, make clean, and
export CFLAGS="-fPIC -DHAVE_NETCDF"/ export CFLAGS="-fPIC" etc..
along with other not-working versions of CFLAGS.
So I am wondering how do I recompile with -fPIC? Is there some special syntax that I'm missing here?
I'm just trying to build an old project of mine using cuda 5.0 preview.
I get an Error when linking, telling me that certain cuda functions can not be found. For example:
undefined reference to 'cudaMalloc'.
My linking command includes the following options for cuda :
-L/usr/local/cuda/lib64 -L/home/myhome/NVIDIA_CUDA_Samples/C/lib -L/home/myhome/NVIDIA_CUDA_Samples/C/common/lib/linux -lcudart
ls -lah /usr/local/cuda/lib64/ gives me 8 cuda libraries including libcudart.so.5.0.7 with symlinks using only the .so-file-ending.
ls /home/myhome/NVIDIA_CUDA_Samples/C/lib/ gives me an empty directory, which is kind of strange?
ls /home/myhome/NVIDIA_CUDA_Samples/C/common/lib/linux/ gives me two directories: i686 and x86_64 both containing only libGLEW.a
I have no idea which way to look for a solution. Any help is appreciated!
EDIT:
Here is my complete linking command (TARGET_APPLICATION is my binary and x86_64/Objectfiles.o stands for all (23) object files including the object file compiled with nvcc):
/home/myhome/nullmpi-0.7/bin/mpicxx -CC=g++ -I. -I/home/myhome/nullmpi-0.7/src -I/usr/lib/openmpi/include -L/usr/local/cuda/lib64 -L/home/myhome/NVIDIA_CUDA_Samples/C/lib -L/home/myhome/NVIDIA_CUDA_Samples/C/common/lib/linux -lcudart -o TARGET_APPLICATION x86_64/Objectfiles.o /usr/lib/liblapack.so /usr/lib/libblas.so /home/myhome/nullmpi-0.7/lib/libnullpmpi.a -lm
I use nullmpi for compilation and linking (project uses MPI and CUDA), which internally uses g++ as can be seen by -CC=g++, i wanted to keep this stuff out.
The compilation command for my cuda object file:
/usr/local/cuda/bin/nvcc -c -arch=sm_21 -L/home/myhome/NVIDIA_CUDA_Samples/C/lib -O3 kernelwrapper.cu -o x86_64/kernelwrapper.RELEASE.2.o
echo $LD_LIBRARY_PATH results in:
/usr/local/cuda/lib64:/usr/local/cuda/lib:
echo $PATH results in:
otherOptions:/usr/local/cuda/bin:/home/myhome/nullmpi-0.7/bin
I'm building 64-bit. For the sake of completeness I'm building on Ubuntu 12.04. (64bit).
Building the CUDA Samples works fine.
SOLUTION (thanks to talonmies for pointing me to it):
This is the correct linking command:
/home/myhome/nullmpi-0.7/bin/mpicxx -CC=g++ -I. -I/home/myhome/nullmpi-0.7/src -I/usr/lib/openmpi/include -L/usr/local/cuda/lib64 -L/home/myhome/NVIDIA_CUDA_Samples/C/lib -L/home/myhome/NVIDIA_CUDA_Samples/C/common/lib/linux -o TARGET_APPLICATION x86_64/Objectfiles.o /usr/lib/liblapack.so /usr/lib/libblas.so /home/myhome/nullmpi-0.7/lib/libnullpmpi.a -lcudart -lm
You have your linking statements in the incorrect order. It should be something more like this:
/home/myhome/nullmpi-0.7/bin/mpicxx -CC=g++ -I. -I/home/myhome/nullmpi-0.7/src \
-I/usr/lib/openmpi/include -L/usr/local/cuda/lib64 \
-L/home/myhome/NVIDIA_CUDA_Samples/C/lib \
-L/home/myhome/NVIDIA_CUDA_Samples/C/common/lib/linux \
-o TARGET_APPLICATION x86_64/Objectfiles.o \
/home/myhome/nullmpi-0.7/lib/libnullpmpi.a -llapack -lblas -lm -lcudart
The source of your problem is that you have specified the CUDA runtime library before the object file that contains a dependency to it. The linker simply discards libcudart.so from the linkage because there are no dependencies to it at the point when it is processed. Golden rule in POSIX style compilation statements: linkage statements are parsed left-to-right; so objects containing external dependencies first, libraries satisfying those dependencies afterwards.