When compiling some CUDA code, I get the error, that the libcutil cannot be found even though I checked that the paths are correct.
Example
$ nvcc mycudacode.cu -lcutil -o mycudaproject -I ~/NVIDIA_GPU_Computing_SDK/C/common/inc -L ~/NVIDIA_GPU_Computing_SDK/C/lib
/usr/bin/ld: cannot find -lcutil
compilation terminated.
Even though:
$ ~/NVIDIA_GPU_Computing_SDK/C/lib$ ls
libcutil_x86_64.a libparamgl_x86_64.a librendercheckgl_x86_64.a
I have tried the following:
cp $(HOME)/NVIDIA_GPU_Computing_SDK/C/lib/libcutil_x86_64.a /usr/local/cuda/lib/libcutil.a
and it works.
From the NVIDIA Forums:
On linux 64bit one has to rename libcutil_x86_64.a into libcutil.a.
So cd into the folder $(HOME)/NVIDIA_GPU_Computing_SDK/C/lib/ (or where you installed CUDA) and enter: cp libcutil_x86_64.a libcutil.a
DISCLAIMER
As I already stumbled over this problem twice I added the question and the answer as a form of documentation.
Related
I am using dbus in my programme, but when i include
#include <dbus-1.0/dbus/dbus.h>
I am getting error :
dbus-1.0/dbus/dbus.h:29:10: fatal error: 'dbus/dbus-arch-deps.h' file not found
In the folder dbus there is no dbus-arch-deps.h file.
I can see this file in a folder lib64/dbus-1.0/include/dbus/dbus-arch-deps.h
Can any one please help me to compile this?
Or any suggestion, as I am stuck badly here.
Since I didnt get the answer from any one, but I finally solved the issue.
So would like to post the solution if some one faces similar problem.
I solved the problem, by adding -I/usr/lib64/dbus-1.0/include/ in cflags.
Late answer. However This may be helpful for somebody who's working on WSL (Windows sub system ) with ubuntu (18.04 lts).
The includ folders are
/usr/lib/x86_64-linux-gnu/dbus-1.0/include
/usr/include/dbus-1.0
Also Link with :
-ldbus-1
In case if you find nothing in there try : sudo apt-get install dbus-x11
The problem is that dbus needs two different include paths. In any case, the best approach is to use pkg-config here. The pkg-config file dbus-1.pc, in fact, includes these cflags:
Cflags: -I${includedir}/dbus-1.0 -I${libdir}/dbus-1.0/include
So, on Manjaro for instance, you'd get:
pkg-config --cflags dbus-1
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include
On an arm debian you'd get:
pkg-config --cflags dbus-1
-I/usr/include/dbus-1.0 -I/usr/lib/arm-linux-gnueabihf/dbus-1.0/include
As it's been answered here, if you're using CMake, just add
target_include_directories(ProjectName PRIVATE /usr/lib/x86_64-linux-gnu/dbus-1.0/include/ /usr/include/dbus-1.0/)
target_link_libraries(ProjectName PRIVATE dbus-1)
lines after the add_executable line, where ProjectName - is the name of your project
Try
sudo cp /usr/lib/x86_64-linux-gnu/dbus-1.0/include/dbus/dbus-arch-deps.h /usr/include/dbus-1.0/dbus/.
I'm using OSX command line gcc and attempting to build a dynamic library. when I do the build I get the following warning. How is it it is not finding this library given /usr/lib is well known? And /usr/lib does indeed exist on my machine
this is what I am using:
gcc -arch i386 cata/*.c -dynamiclib -o build/cata.dylib -LC_ID_DYLIB=/usr/lib
Thanks
the way i solved it was to make it so the string that got stuck in the library (on where to find the library at runtime) was relative to nowhere -- if that makes sense. so it would be forced to use the LD_LOAD_PATH.
I was using the other flags because someone suggested I use them.
so the gcc i ended up using is this:
# my tree is like this
# cata/*.c
# build/*.dylib
#
cd build
gcc -arch i386 ../cata/*.c -dynamiclib -o cata.dylib
Doing this compiles/makes a library in the same directory where it thinks it is 'used' (basically having no path). I am now free to put it somewhere else. When it is later linked at compile time by a different program and then examined using
otool -L
it appears with no path in front of the library name. This is apparently preferable as now when the system goes to try to find it it resorts to looking at the standard libraries and eventually finds it (because I install it to one of the standard locations).
In the original way, otool -L was showing it having a required path of
'build/cata.dylib'
This made it un-findable and which is why i was trying to use the apple documentation to get around the problem.
This doesn't really solve why LC_ID_DYLIB doesn't work. I looked into the Loader.h file (line 643) and it has room for an identifier(0xd), a path, and a structure, so I don't really understand why my path wasn't getting picked up. but its two different topics. Loader.h is runtime and the other is gcc AFAIK. I'm still learning apple.
I set up this toolchain on my Windows machine for my Pi (raspberry-gcc4.6.3-nosysroot.exe) and then I followed the instructions here to synchronize my sysroot.
I use a library called WiringPi in my project, and I have confirmed that it is in the synchronized sysroot:
Then I attempt to compile it:
arm-linux-gnueabihf-gcc -Wall -O -c main.c
But I get the following error:
fatal error: wiringPi.h: No such file or directory
What do I have to do to make the compiler find the header file? I thought the whole point of synchronizing the sysroot was to make this kind of thing work?
You'll have to let gcc know where to look for the include files via the -I argument. In the case above, -IC:\SysGCC\Raspberry\...\usr\local. You may have to add more than one include path, depending on where the required files are scattered. You can also try to set gcc's environment variable(s).
Finding out the correct include path can be a little tedious (see above: should it be local\ or local\include\?). Maybe you can find the environment setting for all default include paths on your Pi and just copy it over to your Windows machine.
Edit: Think I got it: echo | gcc -v -E -
I have installed eCos OS on a linux system (Ubuntu 13.02). After installation, the eCos files are located in opt/ecos.
As I read the eCos tutorial, I see hello.c is stored in opt/ecos/ecos-3.0/examples/hello.c (And I notice that maybe all main eCos system files store in the ecos-3.0 directory).
I have followed the eCos tutorial found on the official website, but I still cannot successfully compile hello.c.
More detail. When I try to run :
$ export INSTALL_DIR=BASE_DIR/ecos-work/arm_install
$ TARGET-gcc -g -IBASE_DIR/ecos-work/install/include hello.c \
-LBASE_DIR/ecos-work/install/lib -Ttarget.ld -nostdlib
I get the error : TARGET-gcc : command not found
I have tried some other tutorials, but I'm still having issues (too messy to list here).
I am looking for step-by-step instruction on compiling hello.c in eCos system. I see the eCos manual lacking in this area.
Thanks :)
It appears that you've missed a subtle convention in the eCos documentation. Items in italics are provided by you! They are variables.
The documentation mentions this here:
Note: Remember that when this manual shows TARGET-gcc you should use
the full name of the cross compiler, e.g. i386-elf-gcc, arm-elf-gcc,
or sh-elf-gcc. When compiling for the synthetic Linux target, use the
native gcc which must have the features required by eCos.
Replace TARGET with the appropriate value and BASE_DIR with (I think, in your case) /opt/ecos. You should verify the include directory before moving forward:
$ ls -l /opt/ecos/ecos-work/install/include
If that doesn't list directory contents, then you simply need to locate ecos-work
The Ecosconfig on Windows and Linux Quick Start section of the docs has you create the BASE_DIR directory (below is a snippet that I am quoting ... italics will not display).
$ mkdir BASE_DIR/ecos-work
$ cd BASE_DIR/ecos-work
So, this could be the correct invocation.
$ export INSTALL_DIR=/opt/ecos/ecos-work/arm_install
$ arm-elf-gcc -g -I/opt/ecos/ecos-work/install/include hello.c \
-L/opt/ecos/ecos-work/install/lib -Ttarget.ld -nostdlib
you need to do
# source /opt/ecos/ecosenv.sh
Then you can try to compile by changing TARGET=
$ TARGET-gcc -g -IBASE_DIR/ecos-work/install/include hello.c \
-LBASE_DIR/ecos-work/install/lib -Ttarget.ld -nostdlib
I have a makefile in Mac OS X and the last command line for the final compilation is:
gcc count_words.o lexer.o -lfl -o count_words
but it responds:
ld: library not found for -lfl
collect2: ld returned 1 exit status
I found that the library libfl.a is in /opt/local/lib/ and that modifying the command line to read:
gcc count_words.o lexer.o -L/opt/local/lib/ -lfl -o count_words
it works perfectly, but I've read when a prerequisite of the form -l is seen, GNU make searches for a file of the form libNAME.so; if no match is found, it then searches for libNAME.a. Here make should find /opt/local/lib/libfl.a and proceed with the final action, linking, but this is not happening.
I tried using LD_LIBRARY_PATH, then realized that as I'm working on Mac I have to use DYLD_LIBRARY_PATH, I exported the variable pointing to /opt/local/lib and tried running the makefile again, didn't work. Found another environment variable called DYLD_FALLBACK_LIBRARY_PATH, exported, didn't work.
What should I do?
DYLD_LIBRARY_PATH (and LD_LIBRARY_PATH on other unices) provides search paths for the loader, to resolve linked libraries at runtime. LIBRARY_PATH is the relevant var for providing paths that the compiler will pass to the linker at link time.
However, OS X's linker ld64 has no way to prefer static linking over dynamic in the presence of both kinds of libraries, which means your only option is to pass the full path to the archive anyway.
gcc count_words.o lexer.o /opt/local/lib/libfl.a -o count_words
Which is really all that -l does after it searches the paths and expands the lib name.
make does not search for the library at all. make just invokes other tools that do that. (ld, which is invoked by gcc) All you need to do is pass the proper flags to gcc from make. Possibly, this just means adding
LDFLAGS=-L/opt/local/lib
to your Makefile (or editing the command directly, as it appears you have done during testing), but it is difficult to tell without seeing the Makefile.
Probably this question Library not found for -lfl is relevant. For some reason if you try -ll instead of -lfl it works on OS X. Also see http://linux-digest.blogspot.hk/2013/01/using-flex-on-os-x.html