I've linked all the required libraries and the caffee confige ran smoothly. But when I want to make the library I get this error:
/usr/bin/ld: /usr/local/lib/libgflags.a(gflags.cc.o): relocation R_X86_64_32S against `std::basic_string, std::allocator >::_Rep::_S_empty_rep_storage' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libgflags.a: could not read symbols: Bad value
I found a 'workaround' for this problem at the libgflags and glog troubleshooting websites:
https://code.google.com/p/google-glog/issues/detail?id=201
But I tried them and it doesn't seem to work. Am I missing something? Maybe I haven't uncommented a line in my original Makefile.config file? *I am installing caffe on my laptop with no CUDA or parallel computing for now.
Try recompiling the gflags library with -fPIC compiler flag.
Did the caffe work using gflags shared library instead of using the static one?
Try to choose 'BUILD SHARED LIBS' option when using Cmake
Related
recently came across a problem when compiling caffe on a server, prompts /usr/bin/ld: cannot find -lcudnn
since I don't have root priviledge, I installed CUDA-8.0 in my HOME directory, then download the libcudnn7-dev and manually do dpkg-deb -xv libcudnn-dev*.deb to extract the deb pkg, then I go to the lib directory, then run ar -x libcudnn*.a and gcc -shared *.o -o libcudnn.so, then copy the generated libcudnn.so to ~/cuda/lib64, then add the ~/cuda/lib64 to the LD_LIBRARY_PATH, but the error prompts, I don't know how to fix this, can someone help?
And I don't understand why it is /usr/bin/ld: cannot find -lcudnn, not something like LD_LIBRARY_PATH/=: cannot find -lcudnn
EDIT:
I downloaded the .tgz file and follow the install guide instructions to install cudnn, but it still prompts the error, my ~/.bashrc is configured:
export CUDA_HOME="~/cuda"
export PATH="/home/wangtao/anaconda2/bin:$CUDA_HOME/bin:$PATH"
export LD_LIBRARY_PATH="$CUDA_HOME/lib64:$LD_LIBRARY_PATH"
I find the /etc/ld.so.conf is like this :
include /etc/ld.so.conf.d/*.conf /usr/local/cuda-7.0/lib64
it is not my wanted path of ~/cuda/lib64, but don't know how to modify it since I don't have root priviledge on the server, I have compiled successfully on local machines, but this seems to be hard
We newbies need to learn more, maybe other people sometimes would not help you much, help yourself, learn more!
Turns out that linking is different from dynamic loading, linking done pre to dynamic loading, what LD_LIBRARY_PATH can affect is dynamic loading, which gives the library file path(eg, .so.1.0, not .so which is usually a symlink to .so.1.0 stuffs and is used for linker not loader), so adding the libcudnn.so path to LD_LIBRARY_PATH does not help, what /usr/bin/ld complains is that linker cannot find the cudnn library, so we need to add libcudnn.so path for the linker to find it, which is what LIBRARY_PATH cames to help, just add it to it, then linker can find it, sometimes we are just not on the right direction, do not annoying, just learning more:)
Can someone pinpoint where I'm doing wrong, PLEASE? I'm so exhausted. I installed MinGW 4.7, python2.7.8, numpy 1.7.1 and scipy0.13.2 to an Anaconda (32bit) environment in Windows7.
Also, for user enviroment variables, I set
C_INCLUDE_PATH:
D:\Anaconda2\envs\arc103\MinGW\i686-w64-mingw32\include
Path (User variable):
C:\Program Files (x86)\Microsoft VS code\bin;D:\Anaconda2\Library\bin;D:\Anaconda2\envs\arc103\MinGW\bin
Tying the following commands in Anaconda Prompt
"f2py -c --help-fcompiler" outputs "... Fortran compilers found:
--fcompiler=gnu95 GNU Fortran 95 compiler (4.7.0) ...."
"f2py -c --help-compiler" outputs
"List of available compilers: ...", not specifically compilers found though.
Running "f2py -c fib1.f -m fib1" according to "NumPy v1.12.dev0 Manual" gives me lots of error as below:
D:\Anaconda2\envs\arc103\Scripts\gfortran.bat -Wall -Wall -shared c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-.7\fib1module.oc:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fortranobject.o c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\fib1.o -Ld:\anaconda2\envs\arc103\mingw\lib\gcc\i686-w64-mingw32\4.7.0 -LD:\Anaconda2\envs\arc103\libs -LD:\Anaconda2\envs\arc103\PCbuild -lpython27 -lgfortran -o .\fib1.pyd
c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fib1module.o:fib1module.c:(.text+0x35): undefined reference to `__imp__PyNumber_Int'
c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fib1module.o:fib1module.c:(.text+0x68): undefined reference to `__imp__PyComplex_Type'
c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fib1module.o:fib1module.c:(.text+0x79): undefined reference to `__imp__PyType_IsSubtype'
c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fib1module.o:fib1module.c:(.text+0x93): undefined reference to `__imp__PyErr_Occurred'
... (Thousands of "undefined reference to" errors I didn't put it here) ...
collect2.exe: error: ld returned 1 exit statuserror: Command "D:\Anaconda2\envs\arc103\Scripts\gfortran.bat -Wall -Wall -shared c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fib1module.o
c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fortranobject.o
c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\fib1.o -Ld:\anaconda2\envs\arc103\mingw\lib\gcc\i686-w64-mingw32\4.7.0 -LD:\Anaconda2\envs\arc103\libs
-LD:\Anaconda2\envs\arc103\PCbuild -lpython27 -lgfortran -o .\fib1.pyd" failed with exit status 1
Sorry for the mess. I have spent almost a few months finding out the fix, but it's too hard for me and all gone to no avail. It would be hugely appreciated if you can help me out. Thanks.
Since this is a couple month old, I am not sure if these tips will still help, but I found when building a Fortran to Python module on Win 10, that only compiling for 32bit worked, and you need to use a signature file, i.e. something along the lines of:
f2py.py -c cuncsd.pyf cuncsd.f
Instead of using the i686-w64-mingw32 toolchain I used a straight mingw32 one (to reduce the risk that I accidentally end up with anything 64bit).
I also found that you need to install a special Visual Studio for Python instance as described here:
Microsoft Visual C++ Compiler for Python 3.4
If you are using Python 2.7 this VSC version should do the trick for you, only newer version (3.5, 3.6) are left out at this time.
For reference here is my complete f2py invocation on the console that I ended up using (neither python nor f2py were on the execution PATH):
python C:\Python34\Scripts\f2py.py -c cuncsd.pyf --opt="-frecursive -fmax-stack-var-size=66560" cuncsd.f -llapack -lrefblas -ltmglib
This particular module depends on 32 bit LAPCK shared libraries that I compiled previously, and we found it even works on XP systems.
I later went back and tried to compile this for 64 bit, but eventually gave up, when I always encountered ld errors. I think going forward for Windows 10 it will be much easier to use the embedded Ubuntu to execute and extend Python.
(See How to enable Bash in Windows 10 developer preview? and Getting PyCharm to recognize python on the windows linux subsystem (bash on windows))
I'm a modest user of Linux; but I appear to have hit a wall here when building Octave.
I need to use Octave 4.0.0 on (64-bit) Ubuntu 14.04, and it seems the only option for me (so far) is to build from source (as the repos apparently don't offer anything prebuilt for this version yet). Anyway, I do
./configure
make
...and then get this:
/usr/bin/ld: /usr/local/lib/libGraphicsMagick.a(magick_libGraphicsMagick_la-analyze.o): relocation R_X86_64_32 against `.gomp_critical_user_GM_GetImageDepthCallBack' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libGraphicsMagick.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
I figured this was because my graphicsmagick install wasn't build with -fPIC. So I downloaded graphicsmagick and did
./configure --with-shared
and built out a new graphicsmagick (make install). Still the same error. So I tried to "force it" by doing the following to graphicsmagick:
./configure CCSHARED="-fPIC" CXXFLAGS="-fPIC"
This time I did a search within the generated Makefile and found -fPIC was, indeed, added to the CXXFLAGS. But after making and install the new graphicsmagick, I still get the same error.
This seems like a build chain problem that I've caused. Any thoughts?
Try with:
./configure --enable-shared --disable-static
My problem is that I cannot compile a CUDA example. I believe I've got CUDA 4.0 installed correctly ( I need the old version b/c I'm trying to run GPGPU-Sim). I downloaded an NVIDIA cuda sample, namely conjugateGradient. If I cd to it and run
make
it doesn't work:
macair93278:7_CUDALibraries r8t$ cd conjugateGradient/
macair93278:conjugateGradient r8t$ ls
Makefile main.cpp
macair93278:conjugateGradient r8t$ make
Makefile:36: findcudalib.mk: No such file or directory
make: *** No rule to make target `findcudalib.mk'. Stop.
I've changed my path so that running
nvcc -V
doesn't produce an error, but gives me the version. So I think that's right.
Thanks for any help.
-bb
findcudalib.mk is missing because the individual sample you downloaded is not designed to be a complete, standalone sample. It requires a framework of other files and probably other libraries that need to be built around it.
To fix this, download the CUDA 4.0 SDK (GPU Computing SDK) from here.
Install that package. Once you have installed it, and assuming your CUDA install is otherwise intact, you should be able to change into the toplevel directory and issue make. This will build all the samples. For convenience, you may wish to issue make -k.
I'm getting this error while trying to run sample codes in CUDA SDK. I have CUDA 2.3 and Visual studio 2008
LINK : fatal error LNK1181: cannot open input file 'cutil32D.lib'
Any pointers how to solve this?
Since you're compiling the SDK samples, the project files are probably correct. Far more likely is that you haven't built the cutil library. Go to the SDK install directory, then into the "C" directory. You'll see a "common" directory, in there open the cutil.sln solution (or cutil_vc90.sln for VS2008) and build it in release and debug modes for your platform.
Then try your sample again.
The cutil library is used to avoid replicating the same code through all the samples, if you're starting your own project I'd avoid reusing the cutil library and write your own checker. For example, you should probably fail gracefully if you detect a CUDA error rather than just calling exit() as done in cutil.
The cuda.rules file included in the SDK is highly recommended! Using this you can just add .cu files to any project and Visual Studio will know how to compile them and link them in to the final executable. Easy!
Your MSVC project needs to include the library cutil32D.lib to link. Once you specify it as a library the linker needs to include in the final binary artifact this problem will go away. It would seem the library is missing at the location the linker is going to look for it. You'll have to change the library search paths or move that file to a directory in which the linker is already looking.
I ran into the same issue. It turned out not only did I need to build the cutil project but also the shrUtils project under the SDK's shared folder.