I am getting a compilation error saying:
In file included from glib.c:5:
/usr/include/glib-2.0/glib.h:30:10: fatal error: glib/galloca.h: No such file or directory
30 | #include <glib/galloca.h>
| ^~~~~~~~~~~~~~~~
compilation terminated.
when I try including glib to my C program
#include <stdio.h>
#include <glib-2.0/glib.h>
int main () {
printf("Hello World");
}
I am trying to include the glib header file to my C file but I keep getting complilation error.
I tried compiling with the following commands:
gcc glib.c
This gives me the above error
gcc `pkg-config --libs glib` glib.c
This gives me the below error
gcc: error: unrecognized command-line option ‘--libs’; did you mean ‘--libs=’?
gcc `pkg-config --libs=glib` glib.c
This also gives me an error,
cc1: warning: command-line option ‘-flibs=glib`’ is valid for Modula-2 but not for C
In file included from glib.c:5:
/usr/include/glib-2.0/glib.h:30:10: fatal error: glib/galloca.h: No such file or directory
30 | #include <glib/galloca.h>
| ^~~~~~~~~~~~~~~~
compilation terminated.
I also tried using the full path
#include </usr/include/glib-2.0/glib.h>
yet it gives me the same compilation error
If you run the command pkg-config --libs glib-2.0 on its own, you will see that it only lists the libraries to link with. It give you the linker flags, not the compiler flags needed to compile your program.
To get the compiler flags you need to use the --cflags option:
gcc `pkg-config --cflags glib-2.0` -Wall -Wextra glib.c -o glib `pkg-config --libs glib-2.0`
Note that I separate the compiler and linker flags. That's because libraries needs to be listed last on the command line.
Also note that I added some flags to enable more warnings, which is generally a good idea (and you should really treat and warning you get as an error that must be properly fixed).
It also seems to be an issue with using backtick commands, and the error is typical when using e.g. Fish instead of Bash.
There are two major issues working against you here:
First Fish uses parenthes instead of backticks for subcommands
Then Fish assumes that arguments are separated by newline not space (see https://fishshell.com/docs/current/faq.html#my-command-pkg-config-gives-its-output-as-a-single-long-string)
To solve this we need to use e.g. this instead:
gcc \
(pkg-config --cflags glib-2.0 | string split -n " ") \
-Wall -Wextra glib.c -o glib \
(pkg-config --libs glib-2.0 | string split -n " ")
It might be simpler to use a simple Makefile or other similar built-tools to help you.
Related
I've been trying all day to build and run a simple Ruby inside of C program.
This is a recurring topic here, and none of them are identical to my issue nor have any of the solutions helped me. I have the ruby-dev installed.
The pkg-config command gives this:
$ pkg-config --cflags --libs ruby-2.7
-I/usr/include/x86_64-linux-gnu/ruby-2.7.0 -I/usr/include/ruby-2.7.0 -lruby-2.7 -lm
The compile command gives this:
$ gcc -I/usr/include/x86_64-linux-gnu/ruby-2.7.0 -I/usr/include/ruby-2.7.0 -I. -lruby-2.7 -o hello *.c
/usr/bin/ld: /tmp/ccdKXtnU.o: in function 'main':
hello.c:(.text+0x9): undefined reference to 'ruby_setup'
collect2: error: ld returned 1 exit status
I have tried switching up the order of the includes. I have tried removing one then the other include. I have tried using a Makefile and running it thru make. I have tried breaking the program up into multiple files. I have tried symbolically linking the architecture relative config.h file into the main header file directory.
The only thing I can think of that I haven't tried is putting the name of the ruby object library that needs to be linked in on the command line, but I don't know the name, or location, of that file.
Here's the latest rendition of the program:
#include <stdio.h>
#include <ruby.h>
int main(void)
{
if (ruby_setup()){
puts("Hola!");
}
else{
printf("Hello World\n");
}
return(0);
}
One of the reasons that pkg-config separates cflags and libs is that they go in different places in the command-line (and sometimes different commands).
If you're going to compile and link in one command, it goes like this:
c99 -o hello $(pkg-config --cflags ruby-2.7) *.c $(pkg-config --libs ruby-2.7)
There's a certain logic to this arrangement. First, we tell the compiler where to look for header files (which it must see before it compiles your program), then where to find the program to compile, and finally where to find the libraries which are referred to by the program.
I'm trying to compile a GTK program on my Debian desktop. I installed libgtk-3-dev and all of that, but when I go to compile the program, I get this error:
$ gcc -o client client.c `pkg-config --cflags --libs glib-2.0`
client.c:6:10: fatal error: gtk/gtk.h: No such file or directory
6 | #include <gtk/gtk.h>
| ^~~~~~~~~~~
compilation terminated.
All of the GTK headers actually seem to be in /usr/include/gtk-3.0, but even if I include <gtk-3.0/gtk/gtk.h> I get errors, since the files inside include other GTK headers as if they were in a normal include path. Then if I compile with -I/usr/include/gtk-3.0 I still get errors, this time about glib. Well, glib files are inside /usr/include/glib-2.0 and it's the same problem as before. Finally, if I compile with -I/usr/include/gtk-3.0 -I/usr/include/glib-2.0, I this time get this error:
$ gcc -o client -I/usr/include/gtk-3.0 -I/usr/include/glib-2.0 client.c `pkg-config --cflags $ --libs glib-2.0`
In file included from /usr/include/gtk-3.0/gdk/gdkapplaunchcontext.h:30,
from /usr/include/gtk-3.0/gdk/gdk.h:32,
from /usr/include/gtk-3.0/gtk/gtk.h:30,
from client.c:6:
/usr/include/gtk-3.0/gdk/gdktypes.h:35:10: fatal error: pango/pango.h: No such file or directory
35 | #include <pango/pango.h>
| ^~~~~~~~~~~~~~~
compilation terminated.
Seems like any combination of compile flags I choose, I get some sort of error, all caused by Debian putting the headers in a non-standard subdirectory. This is not me messing with them, this is what apt installs for me.
You are asking pkg-config for glib, you must ask pkg-config for the GTK+ library:
gcc -o client client.c `pkg-config --cflags --libs gtk+-3.0`
You can keep glib-2.0 in the command line, but since GTK+ depends on glib, it's already included.
I am trying to implement a graphic userinterface to my c-programs. To that i have installed the GTK3.0-pacakge to my computer and followed the tutorial. But I am not able to compile a simple c-program that shows a 200*200 px window.
According to the tutorial one should compile like this:
gcc base.c -o base ‘pkg-config --cflags --libs gtk+-3.0‘
Where base.c is the actual program and pkg-config is the program in the bin-folder that tells the compiler where to find the header-files and libraries.
If I just test if the pkg-config-file is there I write its name in the cmd-window:
pkg-config
I get the following answer:
Must specify package names on the command line
So I actually have this config-file.
But when I try to compile base.c with the above syntax that is
gcc base.c -o base pkg-config --cflags --libs gtk+-3.0
I get the following errors
gcc: error: pkg-config: No such file or directory
gcc: error: unrecognized command line option '--clfags'
gcc: error: unrecognized command line option '--libs'
gcc: error: gtk+-3.0: no such file or directory
So why do I get these compilation errors?
Have I missunderstood what is shown in the tutorial? Is the compilation syntax just an abbreviation of what one should do?
You've just wrongly understood the tutorial. In you string disappeared the back ticks which are vital.
That means, the right line is
gcc base.c -o base `pkg-config --cflags --libs gtk+-3.0`
Compare to your (wrong) line:
gcc base.c -o base pkg-config --cflags --libs gtk+-3.0
All the staff starting with pkg-config is an independent command, not a flag for gcc.
Back ticks tell the shell to run its contents in a subshell and substantiate the result of the command run in the gcc command line.
I'm trying to use GraphicsMagick and got odd build errors, so I added #include <magick/magick.h> to
#include <stdio.h>
int main(int argc, char *argv[]){
printf("hello magick");
return 0;
}
just to see WTF was going on. Obviously hello_world compiles fine. Simply adding the magick header causes tons of errors compiling with any of the following:
clang or gcc -o test.o $(pkg-config --cflags --libs GraphicsMagick) test.c
clang or gcc -o test.o $(GraphicsMagick-config --cflags --libs) test.c
From clang:
zsh/2 1791 % clang -o test.o $(pkg-config --cflags --libs GraphicsMagick) test.c
In file included from test.c:2:
/usr/include/GraphicsMagick/magick/magick.h:19:9: error: unknown type name 'Image'
typedef Image
^
/usr/include/GraphicsMagick/magick/magick.h:20:28: error: unknown type name 'ImageInfo'
*(*DecoderHandler)(const ImageInfo *,ExceptionInfo *);
The solution suggested by Mr. Hale (#1) works perfectly for the test. Trying in the real project; gcc spits thousands of line of errors like:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include/f16cintrin.h: In function ‘__m128i mm256_cvtps_ph(__m256, int)’: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include/f16cintrin.h:73:66: error: cannot convert ‘__m256 {aka float}’ to ‘__vector(8) float’ for argument ‘1’ to ‘__vector(8) short int __builtin_ia32_vcvtps2ph256(__vector(8) float, int)’ return (__m128i) __builtin_ia32_vcvtps2ph256 ((__v8sf) __A, __I);
Since the only change from having the project build successfully and the above was uncommenting either one or both of the following:
#include <magick/api.h>
#include <magick/magick.h>
I'm quite sure I've got something wrong with the build settings. I'm not having success finding documentation on what particular restrictions GraphicsMagick places on compiler/linker options. Finding that might well solve the problem.
Use the <magick/api.h> header; this ensures types and forward declarations appear in the correct order.
Changing from using std=c++0x to std=gnu++11 in the project-wide CXXFLAGS seems to have resolved the issue. For whatever reason, it seems that graphicsmagick 1.3.18-3 is not usable from the c/c++ APIs with std=c++0x. I know this is not a complete explanation or answer, but it makes things build.
This has been fixed in GraphicsMagick 1.3.20.
I have found this in the ChangeLog:
2014-06-15 Bob Friesenhahn
wand/magick_compat.h: Use MAGICK_ATTRIBUTE definition from magick/common.h.
magick/common.h (MAGICK_ATTRIBUTE): Don't undefine __attribute__ since this may be used >by system or compiler headers. Define private macro instead. Resolves SourceForge bug #270 "Compile error with g++ -std=c++11".
RHEL/Fedora/CentOS users, check GraphicsMagick update request for EPEL7 in RedHat Bugzilla, Bug ID 1131926
I have used libftdi in the past and compiled using the command:
gcc -lftdi -o i2csend i2csend.c
Everything went fine.
Today, on Ubuntu 12.10 I get many errors such as undefined reference toftdi_init'`
I understand that libftdi was renamed to libftdi1 so I tried the same command with -lftdi1 and got error:
/usr/bin/ld: cannot find -lftdi1
collect2: error: ld returned 1 exit status
Can anyone explain why?
You should typically not directly specify external package's library names.
It's better to use the packaging system's help program, i.e. pkg-config, like so:
$ gcc -o i2csend i2csend.c $(pkg-config --cflags --libs libftdi1)
Note that this assumes that the package name is libftdi1 in pkg-config's database; I'm not sure how to verify this portably. You can run pkg-config --list-all | grep ftdi to find out.
It's generally a good idea to keep the libraries part (-l option) at the end of the command line, which the above is doing. It's somewhat cleaner to factor out the CFLAGS part, but that requires repeating the command:
$ gcc $(pkg-config --cflags libftdi1) -o i2csend i2csend.c $(pkg-config --libs libftdi1)
Here, I've used double spaces to separate the logical parts of the command line for improved clarity.