I'm new to Allegro, Ubuntu, and C++ ... sorry in advance...
I just installed Allegro 4. Something from the ubuntu software manager. I then followed the directions of this page to install Allegro 5. I don't think my libs are linked correctly, but I don't exactly know how to manually change that.
My code:
#include <allegro.h> //the allegro 4 header?
#include <allegro/allegro5.h> //the allegro 5 header?
int main(){
allegro_init();
}
END_OF_MAIN()
My compile line:
g++ allegro_test.cpp -o output.out `pkg-config --libs allegro5.0`
My output:
allegro_test.cpp (.text+0x2a) undefined refrence to '_install_allegro_check_version'
I assume it is similar to this question, but I cannot figure out how to get the library linked. I'd like to have it know automatically.
I know it's too late to answer this, but there might be someone somewhere seeking for an answer.
the header file is wrong; it should be like this:-
#include <allegro5/allegro.h>
From the question you linked:
gcc foo.c -o foo $(pkg-config --libs allegro-5.0)
However, the source code you've posted is Allegro 4. Allegro 5 is not backward compatible. The A5 equivalent is:
#include <allegro/allegro5.h>
int main() {
al_init();
return 0;
}
Related
This is puzzling me...
I have a code that looks like this:
#include <stdio.h>
#include <pbs_ifl.h>
int doSomeStuff()
{
char *server_name;
int c;
server_name = pbs_default();
c = pbs_connect(server_name);
printf("pbs_errno %d\n",pbs_errno);
// do some stuff
pbs_disconnect(c);
}
When I compile it with:
gcc -static -o executablename sourcefile.c -ltorque
It works allright, compiling with '-static'. pbs_errno is 0 and I can do my stuff.
But if I remove the '-static' flag it starts giving me this message when I run it:
munge: Error: Unable to access "/var/run/munge/munge.socket.2": No such file or directory
So... I start the munge service (munged) and it stops complaining about it, but instead I get pbs_errno=15033 and can't get anything from the cluster (do my stuff).
Any ideas?
I don't know if I delete de question or answer it, but it seems so be solved... so I'm posting the solution here.
I had 2 versions of the lib installed, one via yum other via source.
Since only the compiled code had the static libs, when I was linking -static gcc was linking with the compiled code and when I was linking dynamic it was linking with the yum version.
I just had to enforce the linking with the right libs adding the following flag when liking:
-Wl,-rpath=/usr/local/lib
I'm really a Python developer exclusively, but I'm making my first foray into C programming now, and I'm having a lot of trouble getting started. I can't seem to get the hang of compilation and including libraries. At this point, I'm just identifying the libraries that I need and trying to compile them with a basic "hello, world" app just to make sure that I have my environment setup to do the actual programming.
This is a DBus backend application that will use GIO to connect to DBus.
#include <stdlib.h>
#include <gio/gio.h>
int
main (int argc, char *argv[])
{
printf("hello, world");
return 0;
}
Then, I try to compile:
~$ gcc main.c
main.c:2:21: fatal error: gio/gio.h: No such file or directory
#include <gio/gio.h>
I believe that I've installed the correct packages as indicated here, and gio.h exists at /usr/include/glib-2.0/gio/gio.h.
I found a command online to add a search directory to gcc, but that resulted in other errors:
~$ gcc -I /usr/include/glib-2.0/ main.c
In file included from /usr/include/glib-2.0/glib/galloca.h:34:0,
from /usr/include/glib-2.0/glib.h:32,
from /usr/include/glib-2.0/gobject/gbinding.h:30,
from /usr/include/glib-2.0/glib-object.h:25,
from /usr/include/glib-2.0/gio/gioenums.h:30,
from /usr/include/glib-2.0/gio/giotypes.h:30,
from /usr/include/glib-2.0/gio/gio.h:28,
from main.c:2:
/usr/include/glib-2.0/glib/gtypes.h:34:24: fatal error: glibconfig.h: No such file or directory
#include <glibconfig.h>
^
compilation terminated.
There has to be some relatively simple method for being able to set some options/variables (makefile?) to automatically include the necessary headers. I'm also going to use Eclipse-CDT or Anjuta as an IDE and would appreciate help to fix the import path (or whatever it's called in C).
Any help is greatly appreciated.
Use pkg-config (and make). See exactly this answer to a very similar question. See also this and that answers. Don't forget -Wall -g flags to gcc ..
You don't need an IDE to compile your code (the IDE will just run some gcc commands, so better know how to use them yourself).
I have:
-cygwin 1.7.25 on windows 7/32bit
-g++ --version --> g++ (GCC) 4.8.2
-libstdc++.a --> gcc-g++-4.8.2-1
Tried to make a c++
Hello World:
#include <string>
int main()
{
std::string s = "123";
int i = std::stoi(s);
}
compiling gives:
$ g++ -std=c++11 main.cpp
main.cpp: In function ‘int main()’:
main.cpp:6:10: error: ‘stoi’ is not a member of ‘std’
int i = std::stoi(s);
I searched for hours but I still could not find a solution. What's the issue here?
That's a bug, possibly an incomplete port of some library code to cygwin (it's a cplusplus11 feature) - some stuff has to be changed after all. Make sure to report it.
The solution is easy of course: #include <cstdlib> strtol(s.c_str(),0,10);
www.cplusplus.com/.../strtol
A similar mingw bug is mentioned also here
std::stoi doesn't exist in g++ 4.6.1 on MinGW
I have the same problem yesterday. "error: 'stoi' is not a member of 'std'."
First, I made sure c++11 was enabled. Then, I updated the g++ compiler to the newest version. After that, this error disappeared.
The compiler is not being taken seriously. On windows your best bet is to probably use visual studio, as it is always kept up to date . The bug here is that the macro defs are wrong to begin with. The problem starts from iomanip.h and iosbase . So they would have to changed all of there code. There are user made patches for this but I would not trust them at all, as they may contain even more bugs then the original copies. But it's up to you , I just stick with visual studio express edition.
stoi works correct only on mingw64 for me.
If you use Codeblocks, don't forget to check if your projects compiler is set to mingw64.
Well, I am working with -std=c++98, not -std=c++11 but I solved it with the following:
int i = std::atoi(input.c_str());
atoi() is waiting for c type null-terminated string, c_str() makes it null-terminated char*. To use atoi I also() added the following library:
#include <cstdlib>
my system is:
Ubuntu 22.04.1 LTS
I just spent a frustratingly long time getting openCV to link properly in Ubuntu 12.04 and thought I would share what I learned for the benefit of others.
OpenCV is now available in the Ubuntu repositories as
sudo apt-get install libopencv-dev
which is great, but I believe (please correct me if I'm wrong) that this version of opencv has a different naming convention for the libraries. The main difference is that in c++ the include line should read
#include "opencv2/opencv.hpp"
That will get your code compiling to object but not linking. The other difference is that the static libraries have also been renamed from libcv* to libopencv*. For example binaries can now be located at
/usr/lib/libopencv_core.so
/usr/lib/libopencv_highgui.so
.
.
.
To fix this I needed to explicitly tell the linker about the new library names by changing my compiler command to
g++ main.cpp -lopencv_core -lopencv_highgui ...
Or in CMake
target_link_libraries(main opencv_core opencv_highgui ...)
I hope this helps. And if anyone knows more than me I'd love to find out what's going on here.
-Mike
Personally, I'm using 'pkg-config' to get the compilation flags.
g++ `pkg-config --cflags opencv` main.c `pkg-config --libs opencv` -o main
Example of main:
#include <stdio.h>
#include <cv.h>
int main(void)
{
printf("%s\r\n", CV_VERSION);
printf("%u.%u.%u\r\n", CV_MAJOR_VERSION, CV_MINOR_VERSION, CV_SUBMINOR_VERSION);
}
I have an example code:
#include <quadmath.h>
int main()
{
__float128 foo=123;
cosq(foo);
return 0;
}
I tried to compile it with the following commands:
g++ f128.cpp -lquadmath
g++ f128.cpp /usr/lib64/gcc/x86_64-suse-linux/4.6/libquadmath.a
g++ f128.cpp /usr/lib64/gcc/x86_64-suse-linux/4.6/libquadmath.a /usr/lib64/libquadmath.so.0
g++ f128.cpp /usr/lib64/gcc/x86_64-suse-linux/4.6/libquadmath.a /usr/lib64/libquadmath.so.0 /usr/lib64/gcc/x86_64-suse-linux/4.6/libquadmath.a
All these commands produce one and the same error:
f128.cpp:(.text+0x1b): undefined reference to `cosq(__float128)'
I also tried to declare cosq as follows, without inluding quadmath.h. Declarations of such style are used in C++ interface to fortran subroutines in other programs, and they work well.
extern "C" __float128 cosq_(__float128 *op);
extern "C" __float128 cosq_(__float128 op);
extern "C" __float128 cosq(__float128 *op);
...and so on...
Result was the same.
Then I tried to use cosq in Fortran:
PROGRAM test
REAL*16 foo
REAL*16 res
foo=1;
res=cos(foo)
PRINT *,res
END
This program compiles and executes well (prints the answer with lots of digits), so cosq works in it. This program was compiled with no options: gfortran f128.f90.
OS is OpenSUSE 12.1, gcc version is 4.6.2. *.h, *.a and *.so files mentioned are provided by gcc46-fortran and libquadmath46 packages.
What is the proper way to use cosq and other quadmath functions in C++? I wouldn't like to write Fortran wrappers for them.
First, according to Nikos C. advise, I boot up OpenSUSE 12.2 liveCD (which has gcc 4.7.1) on another machine, but got the same error.
Then I posted this question to OpenSUSE forums.
Martin_helm's answer shows that the problem is distro-independent and the solution is trivial:
extern "C" {
#include <quadmath.h>
}
This works fine on all my machines. Program can be compiled with g++ prog.cpp -lquadmath.