Sorry for the newbie question, this is my first time working with GTK in Linux.
Found several ok tutorials on making my first program using GTK in Linux. For the sake of this question I am referring to this tutorial https://developer.gnome.org/gtk3/stable/gtk-getting-started.html. So I copied and pasted the code, and then tried running it from the command line with
gcc `pkg-config --cflags gtk+-3.0` -o example-0 /home/username/project/example-0.c `pkg-config --libs gtk+-3.0`
On the first example (in that link) it seems to do nothing, and allows me to enter more commands. For the second example is gives me a cursor (>) like it is looking for input. Both should open a GUI window, but they don't.
I got a gut feeling the files need to be in a certain directory. But none of the tutorials really go into where the files should be placed.
I tried a few other tutorials and got the exact same results. So I have to assume something on my end is setup wrong.
I am certain GTK 3 is installed
sudo apt-get install libgtk-3-dev
And I checked that pkg-config is installed (saw this suggested while looking for answers)
UPDATE
Ok I think I have partially sorted it out. I was under the impression that gcc would output the result of the code. It appears it creates a file, that is places in /home/username/. I guess I need to know if gcc is able to show the output? If not how do I run that file? I am not see a way to execute the file it makes.
Ok after digging around in C++ tutorials I think I found the solution. The problem is I did not realize how gcc works combined with a bit of ignorance on how Linux does some stuff. Those GTK "beginner" tutorials are for people with a good working knowledge of programming in C++ in Linux. I had done C++ but in Visual Studio in windows, and even then that was 6 or 7 years ago.
So basically gcc makes a new compiled file, the -o option lets you name the file (otherwise gcc names it "a.out") and gcc allows you to specify the directory the compiled file is saved to (important detail). Then you use ./filesname to run it, that is if you are in the correct directory (cd).
So what I did is first change the directory that I am on, in the terminal, to where I am saving my programs files. Below is an example of what my terminal looks like leading up to successfully opening of a GTK GUI window (note I ditched the "example-0" naming as is seems to cause an issue)
username#pcname:~$ cd /somefolder/projects
username#pcname:~/somefolder/projects$ gcc `pkg-config --cflags gtk+-3.0` -o myprog myprog.c `pkg-config --libs gtk+-3.0`
username#pcname:~/somefolder/projects$ ./myprog
And just like that all is working.
Just for clarity here is each command separated out, one just needs to change the folder and file names
cd /somefolder/projects
gcc `pkg-config --cflags gtk+-3.0` -o myprog myprog.c `pkg-config --libs gtk+-3.0`
./myprog
Related
I tried to compile my context.c file with "gcc $(pkg-config --cflags --libs glib-2.0)" context.c.
But it doesn't work because it does not find galloca header file:
context.c:3:10: fatal error: galloca.h: file or directory not found #include <galloca.h>
I tried "gcc $(pkg-config --cflags --libs glib-2.0 glib)" where galloca.h is located /usr/include/glib-2.0/glib. But after adding glib to the compile command, it does not even find glib.h anymore, which is in /usr/include/glib-2.0.
I tried to add the all necessary paths to PKG_CONFIG_PATH with "export PKG_CONFIG_PATH=/usr/include/glib-2.0/gio/pkgconfig" and so on.... without success.
I also added all necessary library paths to /etc/ld.so.conf and sudo ldconfig -v, also without success.
It is not the first time i face the problem, that necessary libraries can't be found on this system while compiling, but as we in germany say: "i am at the end of my latin", so i have no more clue how to solve this issue and would be gratfull for any help.
Thanks in advance.
PS: I use a raspberry pi 4B 8GB and raspbian linux.
Your library path will not help it to find include file.
Maybe you want -I/usr/include/glib-2.0 -I/usr/include/glib-2.0/glib
Maybe your build script accept CFLAGS environment variable where you can put this option.
Or maybe you change (edit) source code,
#include <galloca.h>
become
#include <glib/galloca.h>
because already it looks correctly in /usr/include/glib-2.0, only the subdirectory is wrong
Afterwards you discover if you must set some path also for libraries. But one thing by one, first compile, then worry about the link. You talk about ld.so.conf. Really this is for runtime, but OK, at build it is last option after trying everything else (see at man ld and search ld.so.conf). Really for build time library path you want -L option maybe with LDFLAGS environment variable. But as I say, first try compile and then discover if link problem.
Wer mit seinem Latein am Ende ist, muss Griechisch sprechen.
There's a TL;DR at the end if the context is too much!
Context
I am trying to update the version of glibc a project uses to 2.23 (I know it's old, that's another issue). In order to do this, I need to swap out the libraries and use the associated interpreter.
I encountered some issues when swapping out the interpreter that looked like an ABI change, so I figured it was probably because the header files had changed somehow and started working on getting those included into the project.
At first I tried using -I to include the headers, but got an error (see below). Later I tried setting --sysroot, but this quickly felt like the wrong way of doing things since I was essentially reinventing what g++ already did with system headers. I later found another mechanism that looked more promising (see Problem section).
Could this be an XY issue? Absolutely, but either way, the problem I'm seeing seems odd to me.
Problem
I looked into whether there was a different mechanism to include headers for system libraries, such as glibc, in gcc and g++. I found the flag -isystem:
-isystem dir
Search dir for header files, after all directories specified by -I but before the standard system directories. Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. If dir begins with "=", then the "="
will be replaced by the sysroot prefix; see --sysroot and -isysroot.
I figured that this was probably wanted and set about intergrating this flag into the build system for the project. The resulting g++ command looks like this (simplified and broken onto multiple lines):
> /path/to/gcc-6.3.0/bin/g++
-c
-Wl,--dynamic-linker=/path/to/glibc-2.23/build/install/lib/ld-linux-x86-64.so.2
-Wl,--rpath=/path/to/glibc-2.23/build/install/lib
-isystem /path/to/glibc-2.23/build/install/include
-I.
-I/project-foo/include
-I/project-bar/include
-o example.o
example.cpp
This leads to the following error, followed by many similar ones:
In file included from /usr/include/math.h:71:0,
from /path/to/gcc-6.3.0/include/c++/6.3.0/cmath:45,
from example.cpp:42:
/path/to/glibc-2.23/build/install/include/bits/mathcalls.h:63:16: error: expected constructor, destructor, or type conversion before '(' token
__MATHCALL_VEC (cos,, (_Mdouble_ __x));
Looking into this, it appears that this particular math.h is incompatible with this version of glibc. The fact it tries to use it surprises me, because the math.h file exists in the glibc directory I specified; why didn't it use that? Here's how I verified that file exists:
> ls /path/to/glibc-2.23/build/install/include/math.h
/path/to/glibc-2.23/build/install/include/math.h
Research
I searched around on the internet for people with a similar issue and came across the following relevant things:
https://github.com/riscv/riscv-gnu-toolchain/issues/105
https://askubuntu.com/questions/806220/building-ucb-logo-6-errors-in-mathcalls-h
-isystem on a system include directory causes errors
The last of these is the most promising; it talks about why -isystem won't work here stating that the special #include_next traverses the include path in a different way. Here, the solution appears to be "don't use -isystem where you can help it", but since I've tried using -I only get get the same problem again, I'm not sure how I'd apply that here.
Original issue
When compiling with the new glibc, I get the following error (our build process ends up running some of the programs it compiles to generate further source to be compiled, hence this runtime error whilst compiling):
Inconsistency detected by ld.so: get-dynamic-info.h: 143: elf_get_dynamic_info: Assertion `info[DT_RPATH] == NULL' failed!
I found a couple of relevant things about this:
https://www.linuxquestions.org/questions/linux-software-2/how-to-get-local-gcc-to-link-with-local-glibc-404087/
https://www.linuxquestions.org/questions/programming-9/inconsistency-detected-by-ld-so-dynamic-link-h-62-elf_get_dynamic_info-assertion-621701/
The only solution I see there is completely recompiling gcc to use the new glibc. I'd like to avoid that if possible, which is what lead me down the include route.
Eliminating the complex build system
To try and eliminate the complex build system on the "real" project, I reproduced the problem using the following test.cpp file:
#include <cmath>
int main() {
}
Compiled using:
> /path/to/gcc-6.3.0/bin/g++ test.cpp -Wl,--dynamic-linker=/path/to/glibc-2.23/build/install/lib/ld-linux-x86-64.so.2 -Wl,--rpath=/path/to/glibc-2.23/build/install/lib
Running yields the same original issue:
> ./a.out
Inconsistency detected by ld.so: get-dynamic-info.h: 143: elf_get_dynamic_info: Assertion `info[DT_RPATH] == NULL' failed!
Trying to use the newer headers yields the same include issue:
> /path/to/gcc-6.3.0/bin/g++ test.cpp -Wl,--dynamic-linker=/path/to/glibc-2.23/build/install/lib/ld-linux-x86-64.so.2 -Wl,--rpath=/path/to/glibc-2.23/build/install/lib -isystem /path/to/glibc-2.23/build/install/include
In file included from /usr/include/math.h:71:0,
from /path/to/gcc-6.3.0/include/c++/6.3.0/cmath:45,
from test.cpp:1:
/path/to/glibc-2.23/build/install/include/bits/mathcalls.h:63:16: error: expected constructor, destructor, or type conversion before '(' token
__MATHCALL_VEC (cos,, (_Mdouble_ __x));
TL;DR
How can I get g++ to include the headers from my glibc build correctly, without it accidentally including incompatible files from /usr/include?
In your GCC version,<cmath> uses #include_next, which means that you need to make sure that the directory which contains the cmath file comes before (on the include search path) the directory with the proper math.h for the version of glibc you are building against.
You can use g++ -v to view the search path. In your case, it probably looks like this:
#include "..." search starts here:
#include <...> search starts here:
.
/project-foo/include
/project-bar/include
/path/to/glibc-2.23/build/install/include
/usr/include/c++/6
/usr/include/x86_64-linux-gnu/c++/6
/usr/lib/gcc/x86_64-linux-gnu/6/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
If you configure glibc with --prefix=/usr and install it with DESTDIR=/path/to/glibc-2.23/build/install, its header files will be installed into the directory /path/to/glibc-2.23/build/install/usr/include. This means you should be able to use the -isysroot option, which rewrites the default /usr/include directory, resulting in the right ordering of the search path:
#include "..." search starts here:
#include <...> search starts here:
.
/project-foo/include
/project-bar/include
/usr/include/c++/6
/usr/include/x86_64-linux-gnu/c++/6
/usr/include/c++/6/backward
/usr/lib/gcc/x86_64-linux-gnu/6/include
/usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
/path/to/glibc-2.23/build/install/usr/include
I am trying to make the PCA-SIFT code (pcasift-0.91nd.tar.gz) in this webpage: http://www.cs.cmu.edu/~yke/pcasift/. After running ./configure which is OK, the make command report that the C compiler can not find header pgm.h:
image.cc:18:22: fatal error: pgm.h: No such file or directory
#include
^ compilation terminated.
There is a webpage in internet which discussed this issue: http://ubuntuforums.org/showthread.php?t=1918422. A solution was stated at the end:
Apparently, the header files are in the directory /usr/include/pgm-5.1
- the preferred way to get this into your include directories when compiling is to use pkgconfig. You will need to add something like
pkg-config --cflags openpgm-5.1 at the end of your compilation
command to get the right headers and add pkg-config --libs
openpgm-5.1 to your linking command.
, but I cannot understand it. Specifically, what does "add pkg-config --cflags openpgm-5.1 at the end of your compilation command" mean? What should I do, to add pkg-config --cflags openpgm-5.1 literally or the results this command returns in terminal? And add to what file? The Makefile is generated by ./configure. Should I add to Makefile or ./configure? I have successfully install libpgm-dev and they are really in /usr/include/pgm-5.1. The command pkg-config --cflags openpgm-5.1 returns -I/usr/include/pgm-5.1 -I/usr/lib/x86_64-linux-gnu/pgm-5.1/include and command pkg-config --libs openpgm-5.1 returns -lpgm -lpthread -lm.
Since that thread was closed, I have to ask here. Hoping someone familiar with Linux compiling process could help me with this issue. Thanks a lot.
I solved the problem myself.
Everything in the ubuntuforums.org webpage mentioned in the original question is wrong; that's why I met with so many problems.
Wrong 1: It's wrong to install libpgm-dev using sudo apt-get install libpgm-dev.
We should download Netpbm, and run the following command after uncompression:
./configure //type none on prompt if you don't have JPEG, TIFF, etc. libraries
make
sudo make package pkgdir=netpbmpkg
sudo ./installnetpbm
sudo rm -f -r /netpbmpkg/
Then Netpbm is installed on Ubuntu.
Wrong 2. The include path returned by pkg-config --cflags is wrong
By default, The include path shold be /usr/local/netpbm/include and the lib path is /usr/local/netpbm/lib.
Wrong 3. The linking option -lpgm returned by pkg-config --libs is wrong
The correct linking option should be -lnetpbm.
Following the right way, I can successfully compile the project in Netbeans (forget about command line make).
I'm trying to compile and run the book's online code from http://www.cs.unm.edu/~angel/BOOK/INTERACTIVE_COMPUTER_GRAPHICS/SIXTH_EDITION/CODE/, but they only seem to have Mac and Windows versions; how do I run this on Linux? I've spent hours trying to get the dependencies and things right just to build the simple examples in chapter 2!
I'm Tony from the future! If you continue on the path you're on, you'll end up spending several more hours before figuring this out - the good news is that I've already done it, and have compiled the following steps to help you out!
sudo apt-get install freeglut3 freeglut3-dev libglew1.5 libglew1.5-dev
From http://www.cs.unm.edu/~angel/BOOK/INTERACTIVE_COMPUTER_GRAPHICS/SIXTH_EDITION/CODE/, download the following files:
CHAPTER02/WINDOWS_VERSIONS/ [I just put these files in CHAPTER02/]
Common/InitShader.cpp
Everything in include/ (although CheckError.h was unnecessary)
(So, your base directory should now have the following folders: CHAPTER02, Common, and include.)
cd CHAPTER02
g++ ../Common/InitShader.cpp example1.cpp -I../include -lglut -lGL -lGLU -lc -lm -lGLEW -o example1.out
Make some changes to resolve errors:
add #include <stdio.h> to include/mat.h
If you get "X Error of failed request: GLXBadFBConfig", comment out these two lines in example1.cpp:
//glutInitContextVersion( 3, 2 );
//glutInitContextProfile( GLUT_CORE_PROFILE );
If you get "error: GLSL 1.50 is not supported." change the first lines of fshader21.glsl and vshader21.glsl to say "#version 130" instead of 150
./example1.out
Rejoice at finally seeing the Sierpinski Gasket!
I am trying to cross-compile a C++ program for the Raspberry Pi using gtkmm in Eclipse under Linux (Ubuntu). I initially set up the cross-compiler using the guide found here, which worked perfectly.
When I then added #include <gtkmm.h> to a program, Eclipse could not find the library. This was fixed by going to (project)Properties->C/C++ Build->Settings, then adding pkg-config gtkmm-3.0 --cflags --libs to Cross G++ Compiler->Miscellaneous->Other flags, selecting verbose(-v) and adding pkg-config gtkmm-3.0 --cflags --libs to Cross G++ Linker->Miscellaneous->Linker Flags. (Both flag additions are enclosed by `, not ', symbols in Eclipse though this doesn't show here.)
Now Eclipse gives the following error: /usr/include/cairo/cairo-ft.h:46:22: fatal error: ft2build.h: No such file or directory. The file ft2build.h exists on my computer in /usr/include, but Eclipse cannot see it and I have had no luck searching for a solution. Any advice?
Thanks
UPDATE: After a lot more searching, I disabled freetype fonts in the cairo library used by gtkmm. This was done by commenting out #define CAIRO_HAS_FT_FONT 1 in cairo-features.h. The next problem was that Eclipse could not find the libraries used by gtkmm, so I added \usr\libs to (project)Properties->C/C++ General->Paths and Symbols->Library paths. After doing all this, it returns the following error when trying to build: /usr/lib//libgtkmm-3.0.so: file not recognized: File format not recognized. This file format seems to be standard though, so what is going wrong now?
I created a new project, set up for cross-compiling as before. I then installed gtkmm on my Raspberry Pi, before copying the /usr/ and /lib/ folders from the Pi's SD card to my laptop. Once this was done I went to (project)Properties->C/C++ Build->Settings. I then added all of the includes listed by pkg-config gtkmm-3.0 --cflags to Cross G++ Compiler->Includes, and all of the libraries listed by pkg-config gtkmm-3.0 --libs to Cross G++ Linker->Libraries - BUT I changed the paths to point to the Pi's library files.
As before, I had to disable freetype fonts in cairo. It still didn't build though, because the included libraries have others they depend on in turn. So the final step was to find and include all of the listed libraries in the Pi files I had copied over. The simple gtkmm example now builds in Eclipse and can be run on the Pi!