Trouble compiling, similar to AreTomo2 issue #7

[mpm896]

Hi Shawn,

I'm running into issues when compiling. After a while, it throws the error relocation R_X86_64_32 against '.XYZ' can not be used when making a PIE object; recompile with -fPIE. This is pretty similar to this Github issue from AreTomo2, however passing the -no-pie flag doesn't work with nvcc and throws a fatal error: nvcc fatal : Unknown option '-fPIE'.

I've tried adding -Xlinker=-pie and -Xlinker=-no-pie (sort of blindly following StackOverflow issues), as well as the -fPIE flag but to no avail.

I'm not familiar with C++/cuda/compiling etc, so any help would be appreciated. Thanks!

[szhengczii]

This is most likely related to precompiled binaries in LibSrc/Lib (libutil.a, libmrcfile.a). Recompiling them on your system should fix the problem. These are the steps: 1) cd LibSrc/Util and then run make clean followed by make all 2) Do the same thing in Mrcfile directory.

[mpm896]

After doing so and rebuilding from makefile11, I get the following errors after it finishes compiling AreTomo/Recon/GWeightProjs.cpp:

/usr/bin/ld: cannot find -lcufft
/usr/bin/ld: cannot find -lcudart
/usr/bin/ld: cannot find -lcuda
/usr/bin/ld: cannot find -lnvToolsExt
/usr/bin/ld: /opt/local/miniconda3/lib64/libcudart_static.a(cudart_static.o): in function `__cudart516':
(.text+0x1d782): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
collect2: error: ld returned 1 exit status
make: *** [makefile11:267: exe] Error 1

After running make clean and make all in LibSrc/Util and then in LibSrc/Mrcfile directories, I ran make clean and make all from the AreTomo3 directory. Let me know if I should have done something differently, thanks!

[DcShepherd]

I had the same issue. I solved it (I think) by adding -Xcompiler -no-pie to line 267 in the makefile11.

This gives you

@$(NVCC) -g -G -Xcompiler -no-pie -m64 $(OBJS) \

You will get an error when you try to add the-no-pie flag to nvcc because it’s a compiler option, not an nvcc option so you have to use -Xcompiler -no-pie instead

Hope this helps

[szhengczii]

@mpm896, this error is associated with the incorrect setting of LD_LIBRARY_PATH, an environment variable that must have an entry for the cuda libraries. Try the following: 1) run which nvcc on the command line. This is what I got after running it: /hpc/apps/x86_64/cuda/12.0.0_525.60.13/bin/nvcc 2) add a line in your .bashrc file like below export LD_LIBRARY_PATH="/hpc/apps/x86_64/cuda/12.0.0_525.60.13/lib64:$LD_LIBRARY_PATH" 3) You should replace the cuda library path in 2) with yours. I am using bash shell that uses .bashrc file for configuration. Another possible shell is C shell that uses .cshrc. The setup will be different and I do not have a machine using C shell.

[mpm896]

@szhengczii @DcShepherd Thank you both for the tips. @DcShepherd 's advice helped with the compile, however when running the AreTomo3 executable I now get the following error:

./AreTomo3: /usr/local/ParticleRuntime/R2022b/bin/glnxa64/libtiff.so.5: version 'LIBTIFF_4.0' not found (required by ./AreTomo3)

I find it a bit odd that it's looking in the Matlab Runtime directory for this file (which is part of the LD_LIBRARY_PATH for PEET to function properly). The cuda libraries are properly set in the LD_LIBRARY_PATH, so I'm not sure how AreTomo3 ended up looking in the Matlab Runtime directory? I've included my LD_LIBRARY_PATH below.

/usr/local/cuda/lib64:/usr/local/ParticleRuntime/R2022b/runtime/glnxa64:/usr/local/ParticleRuntime/R2022b/bin/glnxa64:/usr/local/ParticleRuntime/R2022b/sys/os/glnxa64:/usr/local/ParticleRuntime/R2022b/extern/bin/glnxa64:/usr/local/ParticleRuntime/R2022b/sys/opengl/lib/glnxa64:/usr/local/nvidia/lib:/usr/local/nvidia/lib64

Let me know if there's something I've done wrong, thanks for the help!

[mpm896]

I should also mention that I'm running this in a conda environment, and cuda is installed through conda via cudatoolkit-dev

EDIT: It seems that cudatoolkit-dev from the conda-forge channel doesn't ship with libtiff. This was overcome by linking $CUDA_HOME/lib64/libtiff.so.5 to /usr/libe64/x86_64-linux-gnu/libtiff.so.5