1

So, I'm trying to build an application that requires gtkglextmm on CentOS. So far, I grabbed the source (from here) for gtkglext and gtkglextmm, and (finally) figured out how to compile them and install them using ./configure then make then sudo make install. That was pretty cool to get that to work.

Now, I'm trying to build Degate with cmake and it's complaining that it can't find gtkglextmm. What do I need to do to get the gtkglextmm library I built, available for cmake?

Rephrase: Built and installed library a with make,make install. Now want to build application b that depends on a with cmake. How?

Thanks!

natebot13
  • 167
  • 3
  • 11
  • Not 100% sure on this, but it may be that it's installing the library to /usr/local and then Degate can't find it because it's looking in /usr - if this is the case you could try reinstalling gtkglextmm using `configure --prefix=/usr && make && make install`. – SteJ Jul 29 '15 at 23:36
  • @SteJ No. Do **not** do that. You do **not** install, from source, into `/usr` on a package managed system. That is **asking** for trouble, problems and pain. – Etan Reisner Jul 29 '15 at 23:41
  • 1
    Assuming cmake is looking for the pkg-config files related to `gtkglextmm` then it probably just doesn't have the appropriate `/usr/local` path for them. You can try setting `PKG_CONFIG_PATH` to contain the appropriate path before running cmake, etc. and see if that helps. – Etan Reisner Jul 29 '15 at 23:42
  • Good thought, and I tried it, but didn't work. That seemed to make sense to me... Any other ideas?.... Oops... – natebot13 Jul 29 '15 at 23:43
  • @EtanReisner well, I tried it just before I saw your comment... And I guess my new task is undoing what I did... By manually removing the installed files? And I'll see about setting that variable. – natebot13 Jul 29 '15 at 23:47
  • You ran `./configure --prefix=/usr && make && make install`? Hope and pray that `make uninstall` works correctly. It probably will. But anything it leaves behind is going to be a random stranded file in the main hierarchy of your system. It may (or may not) actually cause a problem though. (It probably won't especially if `make uninstall` does anything of use.) – Etan Reisner Jul 29 '15 at 23:53
  • @EtanReisner Ok, seemed to work. Phew. Thanks. But I still can't build degate. What does "PKG_CONFIG_PATH" need to point to? The `pkgconfig` directory in `/usr/local/lib`? I tried that... – natebot13 Jul 30 '15 at 00:04
  • Unless nothing depends on the library you've just installed and you're sure a distro version of the library is not already installed, in which case you'll be OK because there's nothing for it to conflict with - none the less very good point @EtanReisner; I focussed to much on getting the result and not enough on the repercussions, I will be more careful in the future. – SteJ Jul 30 '15 at 00:06
  • It's cool @SteJ, It was easy to fix, even though I am building from source because this package is not available to CentOS, so there wouldn't be any conflicts. Anyway, I got past dependency checking (sweet) but now boost is complaining about `no member name make_preferred`... There's always something isn't there? – natebot13 Jul 30 '15 at 00:22
  • `PKG_CONFIG_PATH` got configure to work? What is the exact error now and at what point in the process? – Etan Reisner Jul 30 '15 at 01:56
  • @Etan Yeah, setting `PKG_CONFIG_PATH` to /`usr/lib64/local/pkgconfig` worked for configure and make. Then libboost-filesystem was complaining about functions it couldn't find, which was fixed by getting a more updated boost (version 1.58) from a different update repo. Now, the actual Degate code is giving an error, something about expected expression before ']'... I think its a g++ compatibility issue now. I think I'm just going to give up on CentOS and use an Ubuntu machine which works flawlessly with Degate. But many of the computers at work run CentOS... If there's a fix, great. – natebot13 Jul 30 '15 at 02:09
  • `/usr/lib64/local/pkgconfig` or `/usr/local/lib64/pkgconfig`? I'm going to hope the latter as the former doesn't really make sense and is still under the `/`/`/usr` hierarchy. Anyway, if you want help with the new problem I'd delete this question and file a new one (include the info from here and the source install and `PKG_CONFIG_PATH` setting, etc.) and show the new errors and ask for help with them. But it could certainly be a g++ version/compat issue I suppose. – Etan Reisner Jul 30 '15 at 02:16

1 Answers1

0

This is a newcomer's notes made for my team as we adopt cmake. It summarizes briefly what I thought would be somewhere in a novice's example. Although with references and suitable for novices, I am very new to the material and this example may suffer accordingly.

General info for this question is at: https://cmake.org/Wiki/CMake:How_To_Find_Libraries - in particular, find_package can be used on any of the named packages listed by the help command:
cmake --help-module-list Note: the 'Find' is omitted (e.g., FindLibXml2 -> find_package(LibXml2) )

However, for this type of library, it is more likely that it will not be in that list, in which case you want to use find_library and find_path instead. A simple example is:

find_library(SQLITE3_LIB sqlite3) # simple because I did not need to give paths
find_path(SQLITE3_PATH sqlite3.h)
target_link_libraries( your_target_name ${SQLITE3_LIB} )
include_directories( ${SQLITE3_PATH} )

You do not need to test if these have the '-NOTFOUND' return value because cmake will exit with an error if they do:

...
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
SQLITE3_LIB
     linked by target "test" in directory /home/matlab/QFDC_ROOT/api

-- Configuring incomplete, errors occurred!

Note that the all-capitalized 'SQLITE3_LIB' and 'SQLITE3_PATH' are the variable names that I chose. You choose the variable names. If you have other libraries and include directories, you can list them before and after this one and separated by spaces (I ordered them by their link order consistently for both, although I think include paths are insensitive).

Your case may not be so simple, in which case you want to use the CMake features described at find_library for providing CMake more information about where it should find that library. There are other Q&A on specifically that topic - my favorite is to produce your own FindXXX.cmake (although it is a very terse answer pointing you to an example).

In many cases, it is helpful to run make VERBOSE=1 to help you troubleshoot the process, such as cd build && cmake .. && make VERBOSE=1.

For even better diagnostics, I used DLRdave's answer to print out the INCLUDE_DIRS and I used a simple message to return the results of my variables:

message( STATUS "SQLITE3_LIB: ${SQLITE3_LIB} SQLITE3_PATH: ${SQLITE3_PATH}")
get_property(dirs DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY INCLUDE_DIRECTORIES)
foreach(dir ${dirs})
  message(STATUS "dir='${dir}'")
endforeach()

EDIT NOTE: this answer was effectively re-written 2016-04-08 after discovering that the previous day's implementation erred and confused find_library() and find_path().

Community
  • 1
  • 1
sage
  • 4,863
  • 2
  • 44
  • 47