Compiling error about libfm-qt HOT 23 CLOSED

with no further informations (distro, versions etc) i will close this bug as invalid and wontfix.

from libfm-qt.

i can add here, this is because g_vfs_register_uri_scheme is available only since glib version 2.50 and this is not checked by cmake (compile error can happen in e.g. ubuntu 16.04).

i can provide a patch to check glib version but in source code there are some #ifdefs for earlier glib versions so i'm not sure if it's time to drop support for glib < 2.50 or to implement this feature some other way.

from libfm-qt.

erm - nope, that would not be needed. To be true about - it is no LXQt problem, it is a problem with some distributions in the wild. And i'm dead sure that it is not the recommended way on a Ubuntu system to use cmake; make; make install - but i might be wrong.

from libfm-qt.

I think this should be solved some way.

It's not about cmake; make; but about libraries versions installed.
The mentioned ubuntu 16.04 has default glib version 2.48 packaged and when not checked by cmake, build will fail finding this function in header file because it's not present yet in the library.

see the link and look down for g_vfs_register_uri_scheme
https://github.com/GNOME/glib/blob/master/gio/gvfs.h

I had this problem too and had temporarily delete this function call from the source to compile, not to mention search doesn't work without it (using grep now). But i would accept that as fact if glib >= 2.50 is required, which is not.

from libfm-qt.

Fair point - i wonder if the lxqt-build-tools would be the right place for such checks. We set minimum versions in several places in the project - so some components can be built with Qt 5.4.2, some others with min 5.5, one or two would have a minimum of 5.6.1 - glib is such a thing too.

Maybe it the build tools will be the right place for it - @luis-pereira @palinek - what do you think?

from libfm-qt.

Beside of that i don't really care about ancient LTS versions right now. Even 11.1 will not build for 16.04 - and a Long Term Supported OS is not the place for bleeding and cutting edge software. Same is for debian stretch - als long as new LXQt versions will build for it we can take care and backport it, if not - so what?

from libfm-qt.

beside of that many, if not all ubuntu problems can be solved without much work - just upgrade to a current version. The current version of LXQt is the first one where we will care of a certain longer time. And even that does not mean that we will take care that future LXQt versions will work on todays releases, but it will be more likely because the development and LXQt will be more mature with less new features in future versions. Next point is: There will be some new features with every new Qt we are desperatly waiting for. And we will use such features, so a central point with minimum Versions will make sense.

from libfm-qt.

@agaida I agree with that to be current, and not to support what's not necessary. But possible FTBFS should be solved in some way (add or drop support, I don't vote for any).

If it's decided to drop, I can even myself provide delete patch - because some support for older glib versions in some places in libfm-qt historically already is.

from libfm-qt.

@vc-01 It's sometimes not only hard but also counterproductive to add support for older libraries/systems and, when it's about a DE with all its parts, it may be impossible.

from libfm-qt.

@tsujan I know that very good. Maybe it looked like that I wanted or expected to add support - so no i didn't.
Only that I'm not in place to decide. I wrote on this issue because I knew about it and this should be solved, maybe only by adding check for glib version - but then old source could be deleted too, because it's dead anyway (in a #ifdef GLIB < 2.50 branch).

from libfm-qt.

@vc-01, it's OK. I just told about my experience; didn't want to say anything against anyone.

from libfm-qt.

@tsujan yes, I have that experience too from paid projects, then you can't do much about it. And lower the support bigger the pain.

from libfm-qt.

@vc-01 ok, the "solution" i think of doesn't prevent things from FTBFS - it would prevent even the start of a build. If you have a look into the LXQt history there is a long history to drop old things fast and complete (Qt 4 support) and adopt new things fast. This was only possible because of the rapid development of Qt 5 and also KF5. And so evolve LXQt fast. And imho the 0.11 release (with the point releases) is the first release that is stable enough to support it over a longer time, even if there will be new versions. A complete new experience :)

EDIT: Stable in the sense of features and used technologies, not as in bugs or so.

from libfm-qt.

@agaida yes, that's cool, maybe only I badly formed my last posts but this is what i meant. And +1 for vital development and staying current with the libs.

from libfm-qt.

Maybe it the build tools will be the right place for it - @luis-pereira @palinek - what do you think?

You mean ... to put a minimum required version for each library, that is used by more than one component, into lxqt-build-tools ?

from libfm-qt.

@agaida, sorry for not being specific. I'm using a distro called Porteus, which is derived from Slackware 14.2. In fact, I'm the one who is making LXQt x64 module for Porteus.

@vc-01, thanks for the tip. Now I got it 👍

from libfm-qt.

@palinek - only the main ones like Qt and libc - because it doesn't really matter most of the time which component need which minimum - the highest needed minimum will prevent LXQt from being built sucessfully. Esp when it comes to building from git via our (in)famous script.

Edit: The minimum versions in the components can stay - but only for pure informational purpose.

from libfm-qt.

only the main ones like Qt and libc

@agaida I'm OK with that.

from libfm-qt.

Is this the way meant? (only check for glib included as example)

diff --git a/lxqt-build-tools/cmake/LXQtConfigVars.cmake.in b/lxqt-build-tools/cmake/LXQtConfigVars.cmake.in
index 3dfe0e6..25787e0 100644
--- a/lxqt-build-tools/cmake/LXQtConfigVars.cmake.in
+++ b/lxqt-build-tools/cmake/LXQtConfigVars.cmake.in
@@ -25,6 +25,8 @@ set(LXQT_GRAPHICS_DIR       "@LXQT_GRAPHICS_DIR@")
 set(LXQT_ETC_XDG_DIR        "@LXQT_ETC_XDG_DIR@")
 set(LXQT_DATA_DIR           "@LXQT_DATA_DIR@")
 
+set(REQUIRED_GLIB_VERSION   "2.50")
+
 add_definitions("-DLXQT_RELATIVE_SHARE_DIR=\"${LXQT_RELATIVE_SHARE_DIR}\"")
 add_definitions("-DLXQT_SHARE_DIR=\"${LXQT_SHARE_DIR}\"")
 add_definitions("-DLXQT_RELATIVE_SHARE_TRANSLATIONS_DIR=\"${LXQT_RELATIVE_TRANSLATIONS_DIR}\"")

diff --git a/libfm-qt/CMakeLists.txt b/libfm-qt/CMakeLists.txt
index fa38f05..4939c0b 100644
--- a/libfm-qt/CMakeLists.txt
+++ b/libfm-qt/CMakeLists.txt
@@ -39,6 +39,7 @@ find_package(Fm "${REQUIRED_LIBFM_VERSION}" REQUIRED)
 find_package(MenuCache "${REQUIRED_LIBMENUCACHE_VERSION}" REQUIRED)
 find_package(Exif REQUIRED)
 find_package(XCB REQUIRED)
+find_package(GLIB REQUIRED)
 
 message(STATUS "Building ${PROJECT_NAME} with Qt ${Qt5Core_VERSION_STRING}")
 
@@ -46,10 +47,15 @@ option(UPDATE_TRANSLATIONS "Update source translation translations/*.ts files" O
 include(GNUInstallDirs)
 include(GenerateExportHeader)
 include(CMakePackageConfigHelpers)
+include(LXQtConfigVars)
 include(LXQtTranslateTs)
 include(LXQtTranslateDesktop)
 include(LXQtCompilerSettings NO_POLICY_SCOPE)
 
+if (GLIB_VERSION VERSION_LESS "${REQUIRED_GLIB_VERSION}")
+      message(FATAL_ERROR "Error: glib (version >= ${REQUIRED_GLIB_VERSION}) required.\n")
+endif ()
+
 set(CMAKE_AUTOMOC TRUE)
 set(CMAKE_INCLUDE_CURRENT_DIR ON)

Perhaps LXQtConfigVars is not the best file name for this, create new file (like LXQtDeps) ?

(Can make PR then)

from libfm-qt.

Why not require the version directly in find_pacakage ? (of course move the include(LXQtConfigVars) before)

from libfm-qt.

move the include(LXQtConfigVars) before

yes, move it up, now i see

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -35,10 +35,16 @@ find_package(Qt5LinguistTools "${REQUIRED_QT_VERSION}" REQUIRED)
 find_package(Qt5X11Extras "${REQUIRED_QT_VERSION}" REQUIRED)
 
 find_package(lxqt-build-tools "${REQUIRED_LXQT_BUILD_TOOLS_VERSION}" REQUIRED)
+include(LXQtConfigVars)
 find_package(Fm "${REQUIRED_LIBFM_VERSION}" REQUIRED)
 find_package(MenuCache "${REQUIRED_LIBMENUCACHE_VERSION}" REQUIRED)
 find_package(Exif REQUIRED)
 find_package(XCB REQUIRED)
+find_package(GLIB REQUIRED)
+
+if (GLIB_VERSION VERSION_LESS "${REQUIRED_GLIB_VERSION}")
+      message(FATAL_ERROR "Error: glib (version >= ${REQUIRED_GLIB_VERSION}) required.\n")
+endif ()
 
 message(STATUS "Building ${PROJECT_NAME} with Qt ${Qt5Core_VERSION_STRING}")

Why not require the version directly in find_pacakage

Only because of the message displayed, it looks more like it crashed, then regular build error. But that was a proposal, can change to find_package.

CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
  Could NOT find GLIB: Found unsuitable version "2.48.2", but required is at
  least "2.50" (found
  /usr/include/glib-2.0;/usr/lib/x86_64-linux-gnu/glib-2.0/include)
Call Stack (most recent call first):
  /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:386 (_FPHSA_FAILURE_MESSAGE)
  /usr/local/share/cmake/lxqt-build-tools/find-modules/FindGLIB.cmake:113 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:43 (find_package)

So for now, keep it in LXQtConfigVars, no LXQtDeps or LXQtExtLibVers?

from libfm-qt.

i would introduce the dependency in lxqt-build-tools, like this, will take care about in the afternoon

set(REQUIRED_GLIB_VERSION   "2.50")
....
find_package($Glib "${REQUIRED_GLIB_VERSION}" REQUIRED)
find_package($Qt "${REQUIRED_QT_VERSION}" REQUIRED)

Edit: This would have the downside that components needing a lower minimum version will not be built anymore - but i think thats ok, esp for monolitic builds like build from git - and it is imho right, because if we say LXQt we mean the whole LXQt, not only parts of it.

from libfm-qt.

This would have the downside that components needing a lower minimum version will not be built anymore - but i think thats ok, esp for monolitic builds like build from git - and it is imho right, because if we say LXQt we mean the whole LXQt, not only parts of it.

I totally agree with you.

from libfm-qt.