I've recently downloaded the gtk+ all-in-one bundle downloaded from the GTK+ website, which works fine and allows me to build gtk+ applications on Windows using the MinGW compiler.
However, when now looking at the *.pc files for pkg-config in lib/pkgconfig, I noticed something weird. Here's how the beginning of glib-2.0 looks like:
prefix=c:/devel/target/059c48de6b739307c37648aba3005b29
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
My gtk+ folder resides on a different drive than C:\ and I don't have a C:\devel folder at all. So what does this prefix stand for? What prefix would I use if I decided to write a *.pc file for easily linking my own application?
Surprisingly enough, using pkg-config works as expected and returns the correct path the libraries and headers inside the gtk+ folder.
The version of pkg-config that comes with the all in one package basically ignores the prefix. It knows to look in ../lib/pkgconfig for the pkg-config files. You don't need to do anything special for your pkgconfig files other than either put them in that pkgconfig directory, or set some environment variables so pkg-config knows where to look for your *.pc files.
Related
I'm working on a C++ project that requires libpng. So far I've worked on Linux and everything is smooth. I installed libpng, CMAKE picks it up and everything is alright. Now move to Windows.
Here I first installed zlib (required by libpng) and libpng. When I say install, I mean I downloaded the source files, and then built them and install them using msbuild.
I noticed that by doing so, I got new folders under c:\program files (x86):
c:\program files (x86)\zlib
c:\program files (x86)\libpng
Seemed all right to me. Now when I configure my project with CMAKE zlib is picked up:
-- Found ZLIB: C:/Program Files (x86)/zlib/lib/zlib.lib (found version "1.2.13")
but there's no way CMAKE finds the PNG library:
Could NOT find PNG (missing: PNG_LIBRARY PNG_PNG_INCLUDE_DIR)
Now I tried to have a look at the FindPNG and I noticed this line:
find_path(PNG_PNG_INCLUDE_DIR png.h PATH_SUFFIXES include/libpng)
Does this mean that CMAKE expects the file png.h to be in a directory ending in include/libpng? If so, then it will never find it because in my case png.h is placed in libpng/include. But this is also the "official" installation from the source code just downloaded from http://www.libpng.org/pub/png/libpng.html.
So now I am superconfused. How things are supposed to work in Windows? Should I "create" a folder structure with the correct files for every library so that CMAKE is happy? In a way I hoped things in Windows were similar to what happens in Linux: libraries go in a standard folder, they are detected by CMAKE.. everything is ok. But apparently this is not the case. So my question in general is: how do you ship a package like this to a Windows user so that he can builds it without having to go through all this?
Thanks so much
Fabrizio
This would be the right one to use:
find_package(PNG)
You can tell CMake to look in the location where you installed it by adding the libpng base install location to CMAKE_PREFIX_PATH. Without this, CMake doesn't know where you put it.
cmake "-DCMAKE_PREFIX_PATH=C:/Program Files (x86)/libpng" ...
Note that FindPNG first looks for zlib and will fail if zlib could not be found.
I recently downloaded goattracker2 on Windows 10 and after making some changes to the source code, I need to recompile the program to test it.
I don't have any experience with recompiling.
I had a look at the documentation included in the readme-file:
Recompiling
To recompile for Win32, you need the MinGW development environment,
use the file src/makefile.win as makefile.
To recompile for Linux, use src/makefile.
In both cases you need the SDL development libraries in addition to
the SDL runtime, see http://www.libsdl.org.
Compile first the utilities (datafile & dat2inc) from the src/bme
directory, and place them to your path.
This leaves me with several questions, like
Which programs do I need to download
How do I run or execute the makefile
Where do I need to install the SDL libraries
If anyone has experience with recompiling goattracker, can they provide a step by step tutorial for how to do it?
Get MinGW (I recommend 32bit version) and install.
Download and unpack the SDL Libraries from https://www.libsdl.org/ (depending on your version you might need SDL 1.x)
The SDL Libraries (the *.a files) have to be added in the lib directory of MinGW installation directory (this might be different from the lib dir of MinGW, see this issue)
The header files from SDL (SDL2/ directory MinGW) have to be put where MinGW can find them (this might be different from the include dir of MinGW, see this issue)
Go to the src directory of goattracker and type make -f makefile.win
Hi I got a problem with my newly installed Fedora linux distribution. pkg-config is supposed to provide linker flags, something like pkg-config --cflags libboost-dev. But pkg-config cannot find most of the library packages. pkg-config --list-all shows that it can find only a few packages.
I searched online and learned that pkg-config finds packages by searching in the pre-defined paths for the *.pc files. However for most packages (both pre-installed and user-installed), there are no such .pc file. So the *.pc file is not generated everytime when a package installs.
1, How can I provide a .pc file for each of the packages that has already been installed?
2, How can I make sure that for each time a new package is installed, the .pc file is provided?
The Fedora packaging guidelines give information about the way in which packages should be created, and the files they should contain.
The section about -devel packages is particularly relevant.
To highlight some parts
There are some types of files which almost always belong in a -devel package:
Header files (foo.h), usually found in /usr/include
Static library files when the package does not provide any matching shared library files. See Packaging:Guidelines#Packaging_Static_Libraries for more information about this scenario.
Unversioned shared system library files, when a matching versioned shared system library file is also present.
In the next section, regarding Pkgconfig Files, the page informs the reader that
The placement of pkgconfig(.pc) files depends on their usecase. Since they are almost always used for development purposes, they should be placed in a -devel package.
A reasonable exception is when the main package itself is a development tool not installed in a user runtime, e.g. gcc or gdb.
As a result, in order to get either header files to #include, or .pc files to tell you compiler flags, you will need the xyz-devel package, where xyz is the name of the standard package.
A useful website to find the appropriate names of packages to install, if you can't/don't want to guess them, is the Fedora Packages search page.
I have a CMake project that uses FindCurses.cmake. I am on OS X where the OS ships with an older version of ncurses (and doesn't appear to include the C++ bindings) and the code I'm trying to build requires ncurses 5.9. I've used homebrew to install 5.9, but like a good neighbor, homebrew doesn't overwrite the curses/ncurses resources that ship with the OS (nor do I want it to.)
My instinct is that this is something I ought to be able to do without editing the CMake files, right? (Because this change in behavior is specific to my build environment and isn't a change to the project itself, right?) With an autoconf project I would probably add CFLAGS and LDFLAGS environment variables before running ./configure, but CMake seems to have a lot more going on.
What's the idiomatic way to do this in CMake?
You can provide additional search paths through CMAKE_PREFIX_PATH.
Paths within CMAKE_PREFIX_PATH are searched first.
You can specify CMAKE_PREFIX_PATH either hardcoded in the CMakeLists.txt file or, preferably, through:
cmake -D CMAKE_PREFIX_PATH=/path/where/brew/installed/curses .
You can add in your CMakeLists.txt include_directories and link_directories pointing to your ncurses version.
Also I would try to find if ncurses 5.9 has a pkg-config module. See with pkg-config --list-all.
I've successfully built a demo app using opencv on windows with the MSYS shell environment.
I did NOT use the prebuilt opencv installer, I downloaded and compiled the source locally (this is the recommended method).
After building opencv and running make install, all the files are happily in:
/e/deps/libopencv/build/install/
I can successfully build a sample application against this using cmake directives along the lines of:
find_package(OPENCV REQUIRED)
link_directory(${OpenCV_LIB_DIR})
include_directories(${OpenCV_INCLUDE_DIRS})
target_link_libraries(target ${OpenCV_LIBS})
To be completely clear here: building the binary is successful.
Now, when I run it from the shell I get the message:
The program can't start because libopencv_core231.dll is missing from your computer.
Try reinstalling the program to fix this problem.
So... I know where the libraries are:
$ ls /e/deps/libopencv/build/install/lib/
libopencv_calib3d231.dll.a libopencv_features2d231.dll.a libopencv_highgui231.dll.a libopencv_ml231.dll.a libopencv_video231.dll.a
libopencv_contrib231.dll.a libopencv_flann231.dll.a libopencv_imgproc231.dll.a libopencv_objdetect231.dll.a
libopencv_core231.dll.a libopencv_gpu231.dll.a libopencv_legacy231.dll.a libopencv_ts231.a
What now?
I guess I could try to make cmake build a static binary, but that seems pretty extreme.
How can I somehow make either 1) windows, or 2) the MSYS environment happy. Something like LD_LIBRARY_PATH on windows?
Or is this not the problem, and I've actually (despite appearances) somehow messed up the way the binary was compiled?
Edit:
NB. For whatever reason it seems that my libraries are .dll.a files, not .dlls (see the ls result) if that's remotely relevant.
windows searches the same directory as the exe, any directory in the %PATH% (Windows) or $PATH (msys) directories, as well as a few special ones in the windows folder
You could add /e/deps/libopencv/build/install/lib to your $PATH. I am not sure if this will work for msys, you may need to add E:\deps\libopencv\build\install\lib to %PATH% in windows instead.
The typical solution for this if you are giving the program to others is to include a copy of the DLL in the same directory as the EXE. you can get this same effect by making a symbolic link to it with the command
ln -s /e/deps/libopencv/build/install/lib/libopencv_core231.dll libopencv_core231.dll
while in the /e/deps/libopencv/build/install/ directory