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.
Related
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
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
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 have successfully built and installed the opencv lib. Now I am trying to use these libs in my application but I keep getting link errors. I am using:
pkg-config --libs opencv
When I run this on the command line I can see the output. It list a lot of libraries but not all of them are listed with the absolute path specified. For example, here is a partial output:
libippcc_l.a libippvm_l.a tbb rt pthread m dl /usr/lib/libXext.s stdc++
And when I build my app I get link errors. Here is a partial output:
g++: libipps_l.a: No such file or directory
g++: libippi_l.a: No such file or directory
g++: libippcv_l.a: No such file or directory
g++: libippcc_l.a: No such file or directory
g++: libippvm_l.a: No such file or directory
g++: tbb: No such file or directory
g++: rt: No such file or directory
g++: pthread: No such file or directory
g++: m: No such file or directory
g++: dl: No such file or directory
g++: stdc++: No such file or directory
It appears that the linker cannot resolve the libraries that do not include an absolute path which seems reasonable. But my confusion is why dosn't the output from pkg-config include the absolute path for all of its libs? When I do NOT use "pkg-config --libs opencv" on the build line, the libraries for intel ipp, pthread, m, stdc++, etc gets resolved properly and the app builds fine because I also have them specified on the link line as: "-lpthread -lstdc++" ... etc. These are positioned on the link line AFTER the I specify: "pkg --libs opencv"
But using "pkg-config --libs opencv" screws up the resolution.
I have run "ldconfig" from the command line to update all of the symbolic links in my libs directories but this did not resolve this problem.
Any help would be greatly appreciated.
If pkg-config --libs opencv is outputting that, then you have a problem. Maybe a previous installation of OpenCV broke it, or maybe you are not using a version recent enough, or maybe it wasn't compiled successfully, or maybe there's a problem with the newest version from the repository.
Anyway, I'm using OpenCV 2.3.1 on Mac OS X and pkg-config --libs opencv outputs the following info:
-L/usr/local/lib -lopencv_core -lopencv_imgproc -lopencv_highgui -lopencv_ml -lopencv_video -lopencv_features2d -lopencv_calib3d -lopencv_objdetect -lopencv_contrib -lopencv_legacy -lopencv_flann
You can try to compile your application by hand to see if anything else is broken:
g++ test.cpp -o test -I/usr/local/include/opencv -I/usr/local/include -L/usr/local/lib -lopencv_core -lopencv_imgproc -lopencv_highgui -lopencv_ml -lopencv_video -lopencv_features2d -lopencv_calib3d -lopencv_objdetect -lopencv_contrib -lopencv_legacy -lopencv_flann
Note that your install might have placed OpenCV headers and libraries in different directories.
I think that your problem may be related to the one I'm having, and the subject of this pull request to opencv. My guess is: you are installing from source on a linux machine? Does your situation change if you find your opencv.pc file (probably at /usr/local/lib/pkgconfig/opencv.pc), and add -l before the offending words there (rt pthread etc)?
NB: Installing from source will make a new (bad) opencv.pc that overwrites the one where you made the changes I'm suggesting, so if you go through more rebuild-install cycles, do remember to go fix up opencv.pc again before trying to rebuild your program.
This is caused - usually in my practice - by new CMake or a misbehaving one :) It's quite simple to solve - edit by hand opencv.pc and add missing "-l" prefixes to the names. That's it! All other problems are disappearing after this fix. Second usual trouble is the PKG_CONFIG_PATH itself - add it in your shell GLOBAL(!!) profile script and re-launch the shell and verify it via printenv command or something like that.
You can try searching for "opencv.pc" to find the path. For me, the package was in
/Applications/opencv-2.4.11/build/unix-install/
Thus, for me the command that worked was:
pkg-config --libs /Applications/opencv-2.4.11/build/unix-install/opencv.pc
I am attempting to install an application. During compilation it fails with the following error:
/usr/bin/ld: cannot find -lemu
I have installed the libemu library, and it now currently resides in /opt/libemu/. However, when I try and compile my application the library is not found. Is there any way to correct this?
EDIT: It also looks like the make is resulting in:
It also looks like the make file is compiling with the following:
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.6/libemu_module.o
-L/opt/libemu/lib -lemu -o build/lib.linux-x86_64-2.6/libemu.so
I have tried setting my LD_LIBRARY_PATH to /opt/libemu, still doesn't work - fails with the error mentioned above.
You need to tell the linker where it is:
gcc stuff -L/opt/libemu -lemu
or:
gcc stuff /opt/libemu/libemu.a
where stuff is your normal compile/link options files etc.
You can also specify library paths in the LIBRARY_PATH environment variable:
LIBRARY_PATH=/opt/libemu
export LIBRARY_PATH
before you run your build. Yet another option is to see where gcc looks for libraries by running:
gcc --print-search-dirs
and put your library in one of the listed directories.
Edit: It is really not clear from your latest info what you are trying to build. Are you trying to turn a static library into a shared library? Most important - What is the exact filename of the library file you have copied into the /opt/libemu directory?
The environment variable LD_LIBRARY_PATH should include (but probably does not by default) /opt/libemu.
try running:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/libemu
make install