I am pretty new to linux and i wanted to try to make a small opengl
program just as a test. I'm using glfw and i made a very easy test:
#include <iostream>
#include <GL/glew.h>
#include <GLFW/glfw3.h>
using namespace std;
int main()
{
if (!glfwInit())
{
return -1;
}
GLFWwindow *window = glfwCreateWindow(800, 600, "Het werkt", NULL, NULL);
if (!window)
{
glfwTerminate();
}
glfwMakeContextCurrent(window);
while (!glfwWindowShouldClose(window))
{
glfwPollEvents();
glfwSwapBuffers(window);
}
}
Now if i try to run this in Code::Blocks itself, it runs fine, debug, release, it doesn't matter, it works. But when i try to execute it outside Code::Blocks, it goes wrong. If i double click the executable nothing happens, and if i ./ExecutableName in the terminal it gives me this error:
error while loading shared libraries: libglfw.so.3: cannot open shared object file: No such file or directory
All of the libs are in the same directory as the executable, so i don't get why it gives this error.
By the way i'm working on Linux Mint.
Thanks in advance for your help!
You should place those libraries in your $PATH. Issue a echo $PATH command and see if you can find the libraries in there (within those paths) - if not, you will have to put them in there someway. I'm not sure if you can just copy-paste the libraries in there, so probably you may want to search for them using your linux distribution's package management system. As you are using Linux Mint, maybe you could try searching with sudo aptitude search glfw and then try installing the corresponding packages.
Related
I am looking for a way to use cufft.h a CUDA toolkit which perform GPU parallelization of fast fourier transform.
First of all, I downloaded cuda library and cufft through synaptic.
Then I used the sample program from the cufft documentation from NVidia.
my cuda library is located at /usr/local/cuda-9.0 on my laptop.
I added those include :
1 #include <iostream>
2 #include <cstdio>
3 #include "/usr/local/cuda-9.0/include/cuda.h"
4 #include "/usr/local/cuda-9.0/include/cuda_runtime_api.h"
5 #include "/usr/local/cuda-9.0/include/cufft.h"
I compile like this :
g++ -Wall main.cpp -o main
and get undefine references error for each cuda-like functions (cudaMalloc,cudaGetLastError, etc...)
I am pretty young about library implementation and I don't understand what should I do to include properly this cuda-cufft library...
The nvidia documentation talk about filename.cu but I don't know what this is about...
Thank you for your time :)
n.b : I added cuda.h and cuda_runtime_api.h after reading a forum (I forgot which it was). Apparently, only cuda_runtime_api.h is necessary (I tried without cuda.h and get the same errors).
Here is a complete sample code (that doesn't do anything useful) and a sample g++ compile command that will properly compile and link the code:
$ cat t1338.cpp
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <cuda_runtime.h>
#include <cufft.h>
int main() {
size_t work_size;
int fft_sz = 32; // Size of each FFT
int num_ffts = 1; // How many FFTs to do
cufftComplex *in_buf_h, *in_buf_d, *out_buf_d;
// Allocate buffers on host and device
in_buf_h = new cufftComplex[fft_sz*num_ffts];
cudaMalloc(&in_buf_d, fft_sz*num_ffts*sizeof(cufftComplex));
cudaMalloc(&out_buf_d, fft_sz*num_ffts*sizeof(cufftComplex));
cudaMemset(out_buf_d, 0, fft_sz*num_ffts*sizeof(cufftComplex));
// Fill input buffer with zeros and copy to device
memset(in_buf_h, 0, fft_sz*num_ffts*sizeof(cufftComplex));
cudaMemcpy(in_buf_d, in_buf_h, fft_sz*num_ffts*sizeof(cufftComplex), cudaMemcpyHostToDevice);
// Plan num_ffts of size fft_sz
cufftHandle plan;
cufftCreate(&plan);
cufftMakePlan1d(plan, fft_sz, CUFFT_C2C, num_ffts, &work_size);
// Execute the plan. We don't actually care about values.
cufftExecC2C(plan, in_buf_d, out_buf_d, CUFFT_FORWARD);
// Sync the device to flush the output
cudaDeviceSynchronize();
return 0;
}
$ g++ t1338.cpp -I/usr/local/cuda/include -L/usr/local/cuda/lib64 -lcudart -lcufft
$
Your include statements are probably OK as-is, but I have used a format that says "search on the standard path for this file" and then I identify an addition to the standard path with
-I/usr/local/cuda/include
However your compile command is definitely missing the necessary link apparatus. You need to specify where to find the libraries (the path) with -L and then indicate the specific libraries to include, which are both the CUDA runtime library (-lcudart) and also the CUFFT library (-lcufft):
-L/usr/local/cuda/lib64 -lcudart -lcufft
The CUDA toolkit normally gets installed with sample codes which will have sample Makefiles you can inspect, or just compile those projects to see typical compilation command usage.
As I mentioned, this source code is incomplete. It doesn't do anything useful. It is just to demonstrate proper compilation behavior. In particular, I've omitted proper error checking, which I recommend you include in your actual codes.
Depending on whether your install created a symbolic link or not, you may need to change the above paths to:
-I/usr/local/cuda-9.0/include
and
-L/usr/local/cuda-9.0/lib64 -lcudart -lcufft
I just want to try c++ coding with Visual Studio code. I have installed vscode 1.18.1 to my laptop (Win10-64).
I got errors by typing following code:
#include <iostream>
using namespace std;
int main()
{
std::cout << "Hello world!" <<endl;
return 0;
}
Should happen no Error. C:\Users\Harri\OneDrive\Tiedostot\Demo2.vscode\c_cpp_properties.json -content:
"path": [
"/usr/include",
"/usr/local/include",
"${workspaceRoot}"
],
Problems/Errors for row 1:
" #include errors detected. Please update your includePath. IntelliSense features for this translation unit (C:\Users\Harri\OneDrive\Tiedostot\Demo2\Calc.cpp) will be provided by the Tag Parser. "
" cannot open source file "iostream" "
The main problem is cygwin paths
You have cygwin paths like /usr/include in your c_cpp_properties.json file. That is a problem because VSCode does not understand cygwin paths. At a cygwin shell you can run:
$ cygpath -w /usr/include
D:\cygwin64\usr\include
to get the equivalent Windows path. Put that into c_cpp_properties.json instead. Remember that you have to double the backslashes when you copy this into a JSON string.
Other suggestions
This SO answer describes how to set up VSCode with cygwin gcc. I haven't tried those instructions but they look reasonable.
Beyond that, I highly recommend going through the Get Started with C++ tutorial on the VSCode site. It might directly answer your question, but even if it doesn't, having a working setup to compare to is valuable.
Also, look at the C/C++ diagnostics: View → Command Palette... → C/C++: Log Diagnostics. This will show things like which compiler VSCode is trying to emulate and what it thinks the #include paths are.
Finally, to get lots of useful information directly from your compiler to compare with what VSCode thinks, if you are using gcc, run at a cygwin or bash prompt:
$ touch empty.c
$ gcc -v -E -dD empty.c > compiler-info.txt
That will write to compiler-info.txt all the predefined macros, #include search paths, default target, etc.
For some reason iosteam is a typo
Try using instead. It worked for me.
Working Code Screenshot
I tried to build simple kernel module (using source downloaded from developer.sonymobile.com) but after compiling i can't insmod it: Unknown symbol __gnu_mcount_nc so i founded a solution and I wrote another module using assembler and I exported this function. After this module insmoded correctly but I see in lsmod that all modules are permament. I have a problem with simple filesystem (Permission denied - default action when pointer is null), on PC this code works without any errors.
I guess the config is wrong in source code, (probably offset of some fields in structure is another than in device).
Version of built is: 24.0.A.5.14 (downloaded from developer.sonymobile.com site).
Can I do anything to get this same configuration as in device?
I had not /proc/config.gz so I can't get it easily.
Module source:
#include <linux/module.h>
#include <linux/kernel.h>
int __init example_init(void)
{
printk("Hello world!\n");
return 0;
}
void __exit example_exit(void)
{
printk("example module exit\n");
}
module_init(example_init);
module_exit(example_exit);
And I see Hello World! in dmesg but module is still permament.
Source of __gnu_mcount_nc i found here: http://doc.ironwoodlabs.com/arm-arm-none-eabi/html/getting-started/arm-mcount.html
Do you compile with with profile enable -pg flag when you build the kernel module? It looks that way.
The kernel module Makefile for CFLAGS.
I'm trying to compile glfw as static link on Linux Mint (based on Ubuntu 10.04) using GCC 4.4.3.
Inside my project directory i got "external/glfw" which contains glfw 2.7.1 source. I've compiled it by running "make x11-install" which gives:
/usr/local/include/GL/glfw.h
/usr/local/lib/libglfw.a
/usr/local/lib/pkgconfig/libglfw.pc
i also got this simple code in test.c:
#include <stdio.h>
#include <stdlib.h>
#include "external/glfw/include/GL/glfw.h"
int main( int argc, char const* argv[] )
{
if( !glfwInit() ){
fprintf( stderr, "glfwInit Failed\n" );
}
glfwOpenWindowHint( GLFW_FSAA_SAMPLES, 4 );
glfwOpenWindowHint( GLFW_OPENGL_VERSION_MAJOR, 3 );
glfwOpenWindowHint( GLFW_OPENGL_VERSION_MINOR, 1 );
glfwOpenWindowHint( GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE );
// Open a window and create its OpenGL context
if( !glfwOpenWindow( 1024, 768, 0,0,0,0, 32,0, GLFW_WINDOW )){
fprintf( stderr, "glfwOpenWindow failed\n" );
glfwTerminate();
return -1;
}
return 0;
}
i'm trying to compile glfw as static link and compiled the code using gcc with flags:
/usr/bin/gcc `pkg-config --cflags libglfw` -o test test.c \
`pkg-config --libs libglfw` -lXrandr -lX11 -lGLU -lGL -pthread -lm
and it doesn't give me any error. but when i try to execute the binary it shows that i've failed to call glfwOpenWindow.
could any one help me please? thank you for your time guys!
cheers!
P
EDIT 1: I think the problem lies with the linking process and not the code. Because if i have libglfw2 and libglfw-dev installed (ubuntu packages), then the executable runs just fine. What i want here is to have glfw statically linked and not to rely on distro package share libs for the binary to run.
EDIT 2 as per datenwolf suggestion i tried to debug with gdb. i never use gdb before but i use perl debugger a lot. somehow they share a lot of similarities. i recompile glfw and my test.c with -ggdb.
flowing with gdb it shows that my code goes into glfwOpenWindow() which is in "window.c" in glfw source code. since i'm new to gdb i don't know how to evaluate expression or get the value of variables. based on quick search on google all i know is "whatis" to see the date type. but i think my code stops when it reached line 484 in "window.c"
if( wndconfig.glProfile &&
( wndconfig.glMajor < 3 || ( wndconfig.glMajor == 3 && wndconfig.glMinor < 2 ) ) )
{
// Context profiles are only defined for OpenGL version 3.2 and above
return GL_FALSE;
}
now i'm not sure how come using static link glfw thinks i'm not on OpenGL 3.2 and above, while having libglfw2 installed it works just fine?
thanks for your help guys! especially datenwolf!
EDIT 3 Thanks for the help guys. After some help from people in stackoverflow and old nabble I manage to write it down what needs to be done to statically linked GLFW and GLEW and put it on http://www.phacks.net/static-compile-glfw-and-glew/
So your error is that the call to glfwOpenWindow failed? No unresolved symbol or shared object not found messages before even main() gets called? Then you successfully linked against GLFW statically.
I think your problem lies in the parameters you pass to glfwOpenWindow:
glfwOpenWindow( 1024, 768, 0,0,0,0, 32,0, GLFW_WINDOW )
So you're requesting zero red, green or blue bits per channel, but 32 depth bits. I doubt your system supports that. I'd try
glfwOpenWindow( 1024, 768, 8,8,8,0, 24, 8, GLFW_WINDOW )
that's what most systems support well.
Your example program requests OpenGL 3.1 and a context profile. Profiles are only defined for OpenGL 3.2 and above, which is most likely why glfwOpenWindow fails in this case. To fix this, either request a version above or equal to 3.2, or remove the request for a context profile.
For more information about modern OpenGL context creation with GLX, upon which this part of GLFW is a thin layer, see
http://www.opengl.org/registry/specs/ARB/glx_create_context.txt .
I copied clang_complete.vim to plugin, but when I typed . after some variable, it says:
pattern not found
I searched this issue, and somebody said I should configure g:clang_complete_auto: and g:clang_complete_copen:. How can I do this?
I had the same problem and resolved it by adding the following to my .vimrc
let g:clang_user_options='|| exit 0'
Try opening a sample file
vim /tmp/sample.cpp
and enter some cpp code
#include <iostream>
int main() {
std:: // <-- this should complete
}
Note that you actually need to include the headers, since completion is done with the compiler. If this works, but your project still keeps saying "Pattern not found" then clang++ is probably not able to compile your project. Do you use any -I switches when you compile your code? Add them to a file named .clang_complete in your project directory.
For me this works fine with my .vim/plugin folder containing only the clang_complete.vim file that is available for download:
$ find .vim
.vim
.vim/plugin
.vim/plugin/clang_complete.vim
... but in this issue report https://github.com/Rip-Rip/clang_complete/issues/39 it is suggested that you might need more than that file (additional files are in the git repo).
The following got things working for me on Cygwin using clang version 3.0 (tags/RELEASE_30/final), as well as on Windows using the Clang build instructions and a version checked out from trunk (usually stable, as I've read) yesterday (clang version 3.1 (trunk 154056)) and built with Visual Studio 2010:
" clang_complete
let g:clang_complete_auto = 0
let g:clang_complete_copen = 1
" :h clang_complete-auto_user_options
if has('win32unix') " Cygwin
" Using libclang requires a Vim built with +python
let g:clang_use_library = 1
" Mit der Option "gcc" kriege ich Fehler.
" Remove "gcc" option as it causes errors.
let g:clang_auto_user_options='path, .clang_complete'
elseif has('win32') " Windows
let g:clang_auto_user_options='path, .clang_complete'
let g:clang_use_library = 1
let g:clang_library_path='D:\Sourcen\LLVM\build\bin\Debug'
endif
Note that the Windows version may have sporadic assertion failures but works fine, although not exactly like the Cygwin version. Guess it's to do with using MSVC versus GCC header files.
The Cygwin version has an initial error: release unlocked lock, but it works regardless.
Did you try to compile the code outside Vim, by explicitly invoking Clang on the command-line?
I had the same problem with my code, but it turns out Clang was not able to compile my code due to usage of the MPI libraries (mpich2). Maybe a similar problem is causing Clang to fail in your case? In my case, if I remove the MPI-dependencies, everything works fine, for example in something like:
#include <iostream>
#include <string>
int main() {
std::string myString("test string");
std::cout << myString.size() << std::endl; // After typing the dot, I get a list of std::string methods
}
By-the-way, I still miss clang_complete in my MPI code. Did anyone find a solution for this?
To configure Vim, you must find or create your .vimrc file:
$ vim ~/.vimrc
Then enter:
let g:clang_complete_copen = 1