Add to Gentoo repository

[vitaly-zdanevich]

@biodranik is desktop version ready for use? How to build it? What are the dependencies?

[biodranik]

There were some attempts. Please check existing issues and documentation.

[pastk]

Related to #1752

[vitaly-zdanevich]

Desktop version works well for me.

Now I have some experience adding software to the Gentoo main tree, in the future I hope to find some time to add Organic Maps as well, but I want to merge my first ebuild.

[hrnick]

I would love to see this in the Gentoo repository! I have played around a little in a local repo and have ran into a few problems.

Here's the (incomplete) ebuild based on the git source:

EAPI=6

inherit git-r3 cmake-utils
EGIT_REPO_URI="https://github.com/${PN}/${PN}.git"
KEYWORDS="~amd64"

DESCRIPTION="Offline Hike, Bike, Trails and Navigation"
HOMEPAGE="https://organicmaps.app"

LICENSE="Apache-2.0"
SLOT="0"

DEPEND="
	sys-devel/clang
	>=dev-util/cmake-3.18.1
	dev-util/ninja
	media-libs/freetype
	dev-libs/icu
	sys-libs/libstdc++-v3
	dev-qt/qtcore
	dev-qt/qtsvg
	dev-db/sqlite
	sys-libs/zlib[minizip]"
RDEPEND=""

src_prepare() {
	eapply "${FILESDIR}/patch"
	cmake-utils_src_prepare
}

src_configure() {
	CMAKE_BUILD_TYPE="RelWithDebInfo"
	echo | ./configure.sh

	cmake-utils_src_configure
}

For this to make it into the Gentoo repository I guess the git sources shouldn't be used. But the releases I have seen have been specifically for Android so is the Linux desktop code available in any other way than git?

Also I have not been able to find more specific information on what versions of the dependencies that are needed. https://github.com/organicmaps/organicmaps/blob/master/docs/INSTALL.md

If found that OMaps would not build without this patch (I don't remember where or how I found out now):

--- git/3party/minizip/CMakeLists.txt   2022-06-07 12:52:32.337814533 +0200
+++ organicmaps/3party/minizip/CMakeLists.txt   2022-05-31 13:38:50.604235282 +0200
@@ -15,6 +15,7 @@
 
 target_compile_definitions(${PROJECT_NAME}
   PUBLIC
+    OF=_Z_OF
     USE_FILE32API
   PRIVATE
     NOCRYPT

That makes OMaps build and install but I can only run it from /usr/share/organicmaps, most likely related to this issue: #2387

@vitaly-zdanevich: Does OMaps run on your desktop regardsless of what folder you execute it from? Did you add a CMAKE_INSTALL_PREFIX or something when building?

So that's as far as I have gotten at this point. I do not have a lot of experience in creating ebuilds but I hope that we can solve this together. :)

[vitaly-zdanevich]

Thanks!

EAPI 6 is too old, I think we need to specify it to 8.

For this to make it into the Gentoo repository I guess the git sources shouldn't be used

You can, with 9999 version, looks here for an example https://github.com/gentoo/gentoo/blob/09bceb3446344354276908ee2bb792b4bd33ce3e/media-sound/nulloy/nulloy-9999.ebuild

As I understand, in Gentoo this is a common practice to have 9999 ebuild (git master) and some version ebuild.

Now, for some reason, I cannot start OMaps, getting ./OMaps: error while loading shared libraries: libicuuc.so.70: cannot open shared object file: No such file or directory

Did you add a CMAKE_INSTALL_PREFIX or something when building?

No, but I do not remember.

[vitaly-zdanevich]

Please specify OpenStreetMap in the ebuild description, for SEO.

[hrnick]

EAPI 6 is too old, I think we need to specify it to 8.

I get a "EAPI=8 is not supported" when I try that running the ebuild digest.

You can, with 9999 version, looks here for an example https://github.com/gentoo/gentoo/blob/09bceb3446344354276908ee2bb792b4bd33ce3e/media-sound/nulloy/nulloy-9999.ebuild

Right, of course, but it would be masked, right? If there are official releases they could make it into arch and ~arch without being unmasked first.

Now, for some reason, I cannot start OMaps, getting ./OMaps: error while loading shared libraries: libicuuc.so.70: cannot open shared object file: No such file or directory

What version of icu do you have installed? What's stated in the install documentation is that libicu-dev is needed whatever that translates to in Gentoo...

Please specify OpenStreetMap in the ebuild description, for SEO.

Fair point! Fixed!

It seems that recent commits have fixed the problem I had that made OMaps only run from particular folders, possibly related to this fix a few hours ago: #2734

[hrnick]

Again, I don't remember how I found out that the patch is needed or where I found the solution; neither do I know if this is Gentoo specific or generic. What I want to get to is basically if this is a patch for Organic Maps upstream and if I should create a ticket or if it should be kept as a Portage specific patch.

[hrnick]

Again, I don't remember how I found out that the patch is needed or where I found the solution; neither do I know if this is Gentoo specific or generic. What I want to get to is basically if this is a patch for Organic Maps upstream and if I should create a ticket or if it should be kept as a Portage specific patch.

It seems to be Gentoo specific according to jmcnamara/libxlsxwriter#116. I don't know what the Organic Maps developers would say about this going upstream, I guess it could be fixed with a if(${CMAKE_HOST_SYSTEM} MATCHES gentoo) as seen here.

[vitaly-zdanevich]

I get a "EAPI=8 is not supported" when I try that running the ebuild digest.

Try grep -r 'EAPI=8' /var/db/repos/gentoo/

[vitaly-zdanevich]

Even in documentation ebuild example EAPI is 8:

[vitaly-zdanevich]

Hm, ebuild organicmaps-9999.ebuild manifest returns EAPI=8 is not supported, but 7 works.

[vitaly-zdanevich]

Tried to emerge your ebuild (big thank you again!):

>>> Preparing source in /var/tmp/portage/x11-apps/organicmaps-9999/work/organicmaps-9999 ...
 * Applying patch ...
/var/tmp/portage/x11-apps/organicmaps-9999/temp/environment: line 1326: /var/tmp/portage/x11-apps/organicmaps-9999/files/patch: No such file or directory
/var/tmp/portage/x11-apps/organicmaps-9999/temp/environment: line 1329: /var/tmp/portage/x11-apps/organicmaps-9999/files/patch: No such file or directory                                                                                                                                              [ !! ]
 * ERROR: x11-apps/organicmaps-9999::gentoo failed (prepare phase):
 *   patch -p1  failed with /var/tmp/portage/x11-apps/organicmaps-9999/files/patch
 * 
 * Call stack:
 *               ebuild.sh, line  127:  Called src_prepare
 *             environment, line 2727:  Called eapply '/var/tmp/portage/x11-apps/organicmaps-9999/files/patch'
 *             environment, line 1394:  Called _eapply_patch '/var/tmp/portage/x11-apps/organicmaps-9999/files/patch'
 *             environment, line 1332:  Called __helpers_die 'patch -p1  failed with /var/tmp/portage/x11-apps/organicmaps-9999/files/patch'
 *   isolated-functions.sh, line  112:  Called die
 * The specific snippet of code:
 *   		die "$@"
 * 
 * If you need support, post the output of `emerge --info '=x11-apps/organicmaps-9999::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=x11-apps/organicmaps-9999::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/x11-apps/organicmaps-9999/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/x11-apps/organicmaps-9999/temp/environment'.
 * Working directory: '/var/tmp/portage/x11-apps/organicmaps-9999/work/organicmaps-9999'
 * S: '/var/tmp/portage/x11-apps/organicmaps-9999/work/organicmaps-9999'

>>> Failed to emerge x11-apps/organicmaps-9999, Log file:

>>>  '/var/tmp/portage/x11-apps/organicmaps-9999/temp/build.log'

 * Messages for package x11-apps/organicmaps-9999:

 * ERROR: x11-apps/organicmaps-9999::gentoo failed (prepare phase):
 *   patch -p1  failed with /var/tmp/portage/x11-apps/organicmaps-9999/files/patch
 * 
 * Call stack:
 *               ebuild.sh, line  127:  Called src_prepare
 *             environment, line 2727:  Called eapply '/var/tmp/portage/x11-apps/organicmaps-9999/files/patch'
 *             environment, line 1394:  Called _eapply_patch '/var/tmp/portage/x11-apps/organicmaps-9999/files/patch'
 *             environment, line 1332:  Called __helpers_die 'patch -p1  failed with /var/tmp/portage/x11-apps/organicmaps-9999/files/patch'
 *   isolated-functions.sh, line  112:  Called die
 * The specific snippet of code:
 *   		die "$@"
 * 
 * If you need support, post the output of `emerge --info '=x11-apps/organicmaps-9999::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=x11-apps/organicmaps-9999::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/x11-apps/organicmaps-9999/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/x11-apps/organicmaps-9999/temp/environment'.
 * Working directory: '/var/tmp/portage/x11-apps/organicmaps-9999/work/organicmaps-9999'
 * S: '/var/tmp/portage/x11-apps/organicmaps-9999/work/organicmaps-9999'

 * GNU info directory index is up-to-date.

[vitaly-zdanevich]

Created files/patch with your patch, now I got:

-- Configuration
--   Prefix ..................... /usr
--   Build type ................. RelWithDebInfo
--   Shared libraries ........... OFF
--   Character type ............. char (UTF-8)
-- 
--   Build documentation ........ OFF
--   Build examples ............. OFF
--   Build fuzzers .............. OFF
--   Build tests ................ OFF
--   Build tools (xmlwf) ........ OFF
--   Build pkg-config file ...... OFF
--   Install files .............. OFF
-- 
--   Features
--     // Advanced options, changes not advised
--     Attributes info .......... OFF
--     Context bytes ............ 1024
--     DTD support .............. ON
--     Large size ............... OFF
--     Minimum size ............. OFF
--     Namespace support ........ ON
-- 
--   Entropy sources
--     getrandom ................ 1
--     syscall SYS_getrandom .... 1
--     libbsd ................... OFF
--     /dev/random .............. ON
-- 
-- ===========================================================================
-- Looking for C++ include fnmatch.h
-- Looking for C++ include fnmatch.h - found
-- Looking for C++ include stddef.h
-- Looking for C++ include stddef.h - found
-- Check size of uint32_t
-- Check size of uint32_t - done
-- Looking for strtoll
-- Looking for strtoll - found
-- Found the following ICU libraries:
--   uc (required)
--   i18n (required)
--   data (required)
-- Found ICU: /usr/include (found version "71.1") 
-- Found Freetype: /usr/lib64/libfreetype.so (found version "2.12.0") 
-- Found Python3: /usr/bin/python3.10 (found version "3.10.4") found components: Interpreter 
Found python to use in qt/, shaders/ and 3party/: /usr/bin/python3.10
-- Found OpenGL: /usr/lib64/libOpenGL.so   
-- Found Python: /usr/bin/python3.10 (found version "3.10.4") found components: Interpreter 
-- <<< Gentoo configuration >>>
Build type      RelWithDebInfo
Install path    /usr
Compiler flags:
C               -O2 -march=native -pipe
C++             -O2 -march=native -pipe
Linker flags:
Executable      -fuse-ld=gold
Module          -Wl,-O1 -Wl,--as-needed
Shared          -Wl,-O1 -Wl,--as-needed

-- Configuring done
CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
  "editor" of type SHARED_LIBRARY
    depends on "indexer" (weak)
    depends on "search" (weak)
  "indexer" of type SHARED_LIBRARY
    depends on "search" (weak)
    depends on "editor" (weak)
  "search" of type SHARED_LIBRARY
    depends on "editor" (weak)
    depends on "indexer" (weak)
At least one of these targets is not a STATIC_LIBRARY.  Cyclic dependencies are allowed only among static libraries.
CMake Generate step failed.  Build files cannot be regenerated correctly.
 * ERROR: x11-apps/organicmaps-9999::gentoo failed (configure phase):
 *   cmake failed
 * 
 * Call stack:
 *     ebuild.sh, line  127:  Called src_configure
 *   environment, line 2736:  Called cmake-utils_src_configure
 *   environment, line 1189:  Called die
 * The specific snippet of code:
 *       "${CMAKE_BINARY}" "${cmakeargs[@]}" "${CMAKE_USE_DIR}" || die "cmake failed";

[hrnick]

Same thing here so I guess something has changed since commit ab8fb16 a day ago when I installed it successfully.

[biodranik]

The problem is that for some reason you're building internal OM libraries as shared, not as static ones. We never designed nor tested OM with its internal libs (e.g. editor, indexer, search) as shared.

[PureTryOut]

I'm not building for Gentoo (but for Alpine Linux) and saw the same thing originally. Our build scripts for CMake set -DBUILD_SHARED_LIBS=True by default (as we want to build all libraries shared rather than static of course), but for an end user application like this that doesn't really make sense. Set it to false or omit it from the CMake command to fix the build.

[hrnick]

Thank you for the comment @PureTryOut! I thought that was enabled by default for EAPI>=7 in the Gentoo ebuilds but it's definitely something to look into!

[vitaly-zdanevich]

@hrnick will you update the ebuild?

[vitaly-zdanevich]

Recently I pushed my first package into Guru, so I got some experience how to do it.

[hrnick]

No update done other than EAPI=7. I added the following based on what I found in other ebuilds in the gentoo repository but with the same result unfortunately. :/

local mycmakeargs=(
	-DBUILD_SHARED_LIBS=ON
)

[vitaly-zdanevich]

Try TRUE.

[hrnick]

I tried both ON and TRUE.

[hrnick]

So it seems as if it is the EAPI>=7 that breaks the building. I wonder if that is because BUILD_SHARED_LIBS is set to TRUE/ON by default from EAPI 7.

[hrnick]

So what is it that is being built statically? With EAPI=6 and no BUILD_SHARED_LIBS specificed organicmaps installs using the ebuild and patch above for me and running ldd on /usr/bin/OMaps yields a result which, as far as I understand it, at least means that the executable is built as a dynamic one at least.

[hrnick]

So I guess this is what is being built statically with indexer, search and editor having circular dependencies that is only allowed for statically built libraries:

$ grep "static library" log.txt 
[  5%] Linking CXX static library ../../libagg.a
[  5%] Linking CXX static library ../../libminizip.a
[  6%] Linking CXX static library ../../libbsdiff.a
[  7%] Linking CXX static library ../../liboauthcpp.a
[  7%] Linking CXX static library ../../libsuccinct.a
[  8%] Linking CXX static library ../../libjansson.a
[  9%] Linking CXX static library ../../libvulkan_wrapper.a
[  9%] Linking CXX static library ../../libsdf_image.a
[ 10%] Linking CXX static library ../../libopenlocationcode.a
[ 11%] Linking CXX static library ../../libgflags_nothreads.a
[ 12%] Linking C static library ../../libtess2.a
[ 14%] Linking C static library ../../../libexpat.a
[ 14%] Linking CXX static library ../libqt_tstfrm.a
[ 15%] Linking CXX static library ../../libpugixml.a
[ 17%] Linking CXX static library ../libge0.a
[ 18%] Linking CXX static library ../../libstb_image.a
[ 18%] Linking CXX static library ../../libprotobuf.a
[ 18%] Linking CXX static library ../../../librouting_api.a
[ 18%] Linking CXX static library ../libtracking.a
[ 18%] Linking CXX static library ../../../../lib/libgtest.a
[ 19%] Linking CXX static library ../../../../lib/libgtest_main.a
[ 20%] Linking CXX static library ../librouting_common.a
[ 21%] Linking CXX static library ../../../../lib/libgmock.a
[ 21%] Linking CXX static library ../../../../lib/libgmock_main.a
[ 22%] Linking CXX static library ../libtransit.a
[ 23%] Linking CXX static library ../../libopening_hours.a
[ 24%] Linking CXX static library ../libbase.a
[ 26%] Linking CXX static library ../libcoding.a
[ 26%] Linking CXX static library ../libgeometry.a
[ 30%] Linking CXX static library ../../libmwm_diff.a
[ 32%] Linking CXX static library ../libplatform.a
[ 35%] Linking CXX static library ../libstorage.a
[ 36%] Linking CXX static library ../libsearch.a
[ 38%] Linking CXX static library ../libindexer.a
[ 39%] Linking CXX static library ../libeditor.a
[ 43%] Linking CXX static library ../../libplatform_tests_support.a
[ 43%] Linking CXX static library ../../libeditor_tests_support.a
[ 43%] Linking CXX static library ../libdescriptions.a
[ 43%] Linking CXX static library ../libtraffic.a
[ 46%] Linking CXX static library ../libkml.a
[ 49%] Linking CXX static library ../libdrape.a
[ 51%] Linking CXX static library ../libshaders.a
[ 53%] Linking CXX static library ../librouting.a
[ 56%] Linking CXX static library ../../libroutes_builder.a
[ 59%] Linking CXX static library ../../librouting_quality.a
[ 59%] Linking CXX static library ../libopenlr.a
[ 61%] Linking CXX static library ../libdrape_frontend.a
[ 62%] Linking CXX static library ../libgenerator.a
[ 65%] Linking CXX static library ../../libgenerator_tests_support.a
[ 66%] Linking CXX static library ../../libworld_roads_builder.a
[ 68%] Linking CXX static library ../libpoly_borders.a
[ 69%] Linking CXX static library ../../libsearch_tests_support.a
[ 70%] Linking CXX static library ../libtrack_analyzing.a
[ 72%] Linking CXX static library ../libmap.a
[ 73%] Linking CXX static library ../../libworld_feed.a
[ 81%] Linking CXX static library ../../libsearch_quality.a
[ 93%] Linking CXX static library ../../libqt_common.a

[PureTryOut]

Ideally that gets fixed, but for now -DBUILD_SHARED_LIBS=False will make it compile.

[hrnick]

Adding -DBUILD_SHARED_LIBS=False makes organicmaps install even with EAPI=7. Should IUSE="static-libs" and REQUIRED_USE="static-libs" to indicate that this has to be built statically maybe? Let me know what you think and I'll post an updated ebuild.

[vitaly-zdanevich]

Hmmm, but if a map is downloaded - we do not need a network?

[gerion0]

But the map needs to be downloaded at some time. Also, OM notifies you about too old maps and present you the newest one. It does make some network connections.

You can also look at (some) of the dependencies with ldd:

$ ldd /usr/bin/OMaps
linux-vdso.so.1 (0x00007fffbebaa000)
	libgflags.so.2.2 => /usr/lib64/libgflags.so.2.2 (0x00007fdb22c12000)
	libpugixml.so.1 => /usr/lib64/libpugixml.so.1 (0x00007fdb22bd3000)
	libQt6Network.so.6 => /usr/lib64/libQt6Network.so.6 (0x00007fdb21a2b000)
	libQt6Positioning.so.6 => /usr/lib64/libQt6Positioning.so.6 (0x00007fdb21991000)
	libjansson.so.4 => /usr/lib64/libjansson.so.4 (0x00007fdb21981000)
	libicuuc.so.74 => /usr/lib64/libicuuc.so.74 (0x00007fdb21600000)
	libz.so.1 => /usr/lib64/libz.so.1 (0x00007fdb21965000)
	libicui18n.so.74 => /usr/lib64/libicui18n.so.74 (0x00007fdb21200000)
	libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fdb21899000)
	libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 (0x00007fdb210d0000)
	libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fdb2186d000)
	libQt6OpenGLWidgets.so.6 => /usr/lib64/libQt6OpenGLWidgets.so.6 (0x00007fdb2185f000)
	libQt6Widgets.so.6 => /usr/lib64/libQt6Widgets.so.6 (0x00007fdb20800000)
	libQt6OpenGL.so.6 => /usr/lib64/libQt6OpenGL.so.6 (0x00007fdb2155b000)
	libQt6Gui.so.6 => /usr/lib64/libQt6Gui.so.6 (0x00007fdb20000000)
	libGLX.so.0 => /usr/lib64/libGLX.so.0 (0x00007fdb21829000)
	libOpenGL.so.0 => /usr/lib64/libOpenGL.so.0 (0x00007fdb210a5000)
	libQt6Core.so.6 => /usr/lib64/libQt6Core.so.6 (0x00007fdb1fa00000)
	libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++.so.6 (0x00007fdb1f600000)
	libm.so.6 => /usr/lib64/libm.so.6 (0x00007fdb20fca000)
	libmvec.so.1 => /usr/lib64/libmvec.so.1 (0x00007fdb1f908000)
	libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/13/libgcc_s.so.1 (0x00007fdb20fa5000)
	libc.so.6 => /usr/lib64/libc.so.6 (0x00007fdb1f441000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fdb22c85000)
	libzstd.so.1 => /usr/lib64/libzstd.so.1 (0x00007fdb1f381000)
	libproxy.so.1 => /usr/lib64/libproxy.so.1 (0x00007fdb21820000)
	libcrypto.so.3 => /usr/lib64/libcrypto.so.3 (0x00007fdb1ee00000)
	libicudata.so.74 => /usr/lib64/libicudata.so.74 (0x00007fdb1d000000)
	libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00007fdb2180d000)
	libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fdb207c9000)
	libbrotlidec.so.1 => /usr/lib64/libbrotlidec.so.1 (0x00007fdb2154d000)
	libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fdb1f23e000)
	libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 (0x00007fdb20f7f000)
	libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00007fdb207b3000)
	libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fdb1f8bc000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fdb1cebd000)
	libQt6DBus.so.6 => /usr/lib64/libQt6DBus.so.6 (0x00007fdb1cdfe000)
	libxkbcommon.so.0 => /usr/lib64/libxkbcommon.so.0 (0x00007fdb1f874000)
	libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 (0x00007fdb1cd45000)
	libdouble-conversion.so.3 => /usr/lib64/libdouble-conversion.so.3 (0x00007fdb2079d000)
	libb2.so.1 => /usr/lib64/libb2.so.1 (0x00007fdb21542000)
	libpcre2-16.so.0 => /usr/lib64/libpcre2-16.so.0 (0x00007fdb1ed71000)
	libpxbackend-1.0.so => /usr/lib64/libproxy/libpxbackend-1.0.so (0x00007fdb20793000)
	libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007fdb1cce4000)
	libbrotlicommon.so.1 => /usr/lib64/libbrotlicommon.so.1 (0x00007fdb1ffdd000)
	libpcre2-8.so.0 => /usr/lib64/libpcre2-8.so.0 (0x00007fdb1cc48000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fdb1cc1e000)
	libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007fdb1cbd1000)
	libgomp.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/13/libgomp.so.1 (0x00007fdb1cb82000)
	libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007fdb1c999000)
	libffi.so.8 => /usr/lib64/libffi.so.8 (0x00007fdb1ffd1000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fdb21539000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fdb1ffc9000)
	libsystemd.so.0 => /usr/lib64/libsystemd.so.0 (0x00007fdb1c899000)
	libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007fdb2078c000)
	libmount.so.1 => /usr/lib64/libmount.so.1 (0x00007fdb1c82d000)
	libcap.so.2 => /usr/lib64/libcap.so.2 (0x00007fdb1ed65000)
	libgcrypt.so.20 => /usr/lib64/libgcrypt.so.20 (0x00007fdb1c6e7000)
	liblz4.so.1 => /usr/lib64/liblz4.so.1 (0x00007fdb1c6c2000)
	liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007fdb1c693000)
	libblkid.so.1 => /usr/lib64/libblkid.so.1 (0x00007fdb1c636000)
	libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007fdb1c60e000)

QtNetwork is explicitely linked against.
(Not all of them needs to be listed in the ebuild explicitely, since they are automatically present due to other dependencies.)

[vitaly-zdanevich]

after another package required dev-qt/qtbase -network.

why some package want to disable it? What is the name of that package?

[vitaly-zdanevich]

Now, even without adding qtbase dependency, I got compile error:

 * Applying more-3party.patch ...
patching file 3party/CMakeLists.txt
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file 3party/CMakeLists.txt.rej
patching file base/CMakeLists.txt
Hunk #1 succeeded at 111 with fuzz 2.                                               

Any ideas?

This is the link to the patch https://github.com/gentoo/guru/blob/73885a8d9d55f623ed74366c932d800ea09c9a37/gui-apps/organicmaps/files/more-3party.patch

[biodranik]

I suggest to properly fix the upstream version here instead of applying strange patches )

[vitaly-zdanevich]

I know nothing about cmake - can somebody please investigate the upstream?

[biodranik]

Any ideas?

Your patch has failed, because the same file has changed here, and the older patch didn't take it into account. So you can take the latest version of the file from here and make another patch, similar to the failing one.

To reduce the amount of patches (or remove them completely) you can offer necessary changes in pull requests here. If they are really needed, and they don't break all other platforms, then we can accept and merge these changes here. And custom patches for Gentoo won't be needed.

There is not much to know about cmake. Two commands are used to build:

cmake -DCMAKE_BUILD_TYPE=Release -B path_to_temporary_build_folder -S path_to_organicmaps_repo_source_root
cmake --build path_to_temporary_build_folder --target desktop

You can also install ninja build and use -G Ninja in the first line to speed up the build.

Then go step by step and fix all build issues.

[vitaly-zdanevich]

I tried to install without more-3party.patch and got

-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using compiler GNU 13.2.1
-- Using Unity Build with batch 50, export UNITY_DISABLE=1 or use -DUNITY_DISABLE=ON to disable it.
-- export COLORS_DISABLE=1 or use -DCOLORS_DISABLE=ON to disable colored compiler output.
-- Build type: RelWithDebInfo
-- Using ld.ldd linker
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE  
-- Performing Test HAVE_STDATOMIC
-- Performing Test HAVE_STDATOMIC - Success
-- Found WrapAtomic: TRUE  
-- Found OpenGL: /usr/lib64/libOpenGL.so   
-- Found WrapOpenGL: TRUE  
-- Found XKB: /usr/lib64/libxkbcommon.so (found suitable version "1.6.0", minimum required is "0.5.0") 
-- Found WrapVulkanHeaders: /usr/include  
-- Found the following ICU libraries:
--   uc (required): /usr/lib64/libicuuc.so
--   i18n (required): /usr/lib64/libicui18n.so
--   data (required): /usr/lib64/libicudata.so
-- Found ICU: /usr/include (found version "74.2") 
-- Found Freetype: /usr/lib64/libfreetype.so (found version "2.13.2") 
CMake Error at CMakeLists.txt:324 (find_package):
  Could not find a package configuration file provided by "jansson" with any
  of the following names:

    janssonConfig.cmake
    jansson-config.cmake

  Add the installation prefix of "jansson" to CMAKE_PREFIX_PATH or set
  "jansson_DIR" to a directory containing one of the above files.  If
  "jansson" provides a separate development package or SDK, be sure it has
  been installed.

Can we fix it in this repo, not in a patch?

[biodranik]

This config clearly requires that jansson is installed in your system as a dependency. Why a patch is needed?

if (WITH_SYSTEM_PROVIDED_3PARTY)
  set(GFLAGS_USE_TARGET_NAMESPACE ON)
  find_package(gflags REQUIRED)

  find_package(expat CONFIG REQUIRED)
  find_package(jansson CONFIG REQUIRED)
  find_package(pugixml REQUIRED)
  find_package(utf8cpp REQUIRED)
endif()

[vitaly-zdanevich]

Oh, ok, thanks, I will try...

[gerion0]

Let me clarify the situation, since I'm the author of the patches.
There are currently two patches, and the whole ebuild does not work anymore due to 76dd632.

Patch 1

Here is an updated version of the patch. @vitaly-zdanevich I'll make an PR with that for guru as soon as the OrganicMaps PRs are resolved.

diff --git a/3party/CMakeLists.txt b/3party/CMakeLists.txt
index d4996e302d..953787945b 100644
--- a/3party/CMakeLists.txt
+++ b/3party/CMakeLists.txt
@@ -41,9 +41,6 @@ if (NOT WITH_SYSTEM_PROVIDED_3PARTY)
   # Add pugixml library.
   add_subdirectory(pugixml)
 
-  # Add protobuf library.
-  add_subdirectory(protobuf)
-
   if (NOT PLATFORM_LINUX)
     add_subdirectory(freetype)
     add_subdirectory(icu)
@@ -55,6 +52,9 @@ if (NOT WITH_SYSTEM_PROVIDED_3PARTY)
   target_include_directories(utf8cpp INTERFACE "${OMIM_ROOT}/3party/utfcpp/source")
 endif()
 
+# Add protobuf library.
+add_subdirectory(protobuf)
+
 add_subdirectory(agg)
 add_subdirectory(bsdiff-courgette)
 add_subdirectory(liboauthcpp)

It put protobuf to a vendored library again, since the installed version in Gentoo is too new. This should be fixed by #6310, so the patch is superfluous at the moment the PR is merged.

Patch 2

I suggest to properly fix the upstream version here instead of applying strange patches )

See PR #7983

The Jansson failure

76dd632 introduced a new mechanism for finding jansson which seems to fail. PR #7982 should fix that.

The failure after that

Applying both PRs fixes CMake configuration. However, the next failure is:

[76/1529] Building CXX object base/CMakeFiles/base.dir/string_utils.cpp.o
FAILED: base/CMakeFiles/base.dir/string_utils.cpp.o 
/usr/bin/ccache /usr/bin/ccache /usr/bin/c++ -DRELEASE -I/home/gerion/src/organicmaps -isystem /home/gerion/src/organicmaps/3party/boost -isystem /usr/include/utf8cpp -O3 -DNDEBUG -std=c++17 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fdiagnostics-color=always -ffast-math -Ofast -Wall -Wextra -Wpedantic -Wno-unused-parameter -MD -MT base/CMakeFiles/base.dir/string_utils.cpp.o -MF base/CMakeFiles/base.dir/string_utils.cpp.o.d -o base/CMakeFiles/base.dir/string_utils.cpp.o -c /home/gerion/src/organicmaps/base/string_utils.cpp
/home/gerion/src/organicmaps/base/string_utils.cpp:12:10: fatal error: fast_double_parser.h: No such file or directory
   12 | #include <fast_double_parser.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

This needs further investigation. I'm not sure why the base project does not include fast_double_parser since it is done explicitly in the CMake file:

base/CMakeLists.txt
115:  target_include_directories(${PROJECT_NAME} PRIVATE "${OMIM_ROOT}/3party/fast_double_parser/include")

[biodranik]

@gerion0 thanks! It would be great to understand the root causes of why the master code does not work for jansson.

Regarding fast double parser, it is under the if for some reason. You're likely building with WITH_SYSTEM_PROVIDED_3PARTY=ON, right?

if (NOT WITH_SYSTEM_PROVIDED_3PARTY)
  target_include_directories(${PROJECT_NAME} PRIVATE "${OMIM_ROOT}/3party/fast_double_parser/include")
endif()

[gerion0]

Regarding fast double parser, it is under the if for some reason. You're likely building with WITH_SYSTEM_PROVIDED_3PARTY=ON, right?

Should have looked into the CMakeLists as well and not just on the output of ripgrep...
Yes, I build it with WITH_SYSTEM_PROVIDED_3PARTY=ON. So I assume that fast_double_parser should be a system provided 3party now? In this case, Cmake is not aware at all that fast_double_parser is a needed dependency since it is a header only library and the compiler looks in /usr/include/ anyway?

[Ferenc-]

In this case, Cmake is not aware at all that fast_double_parser is a needed dependency since it is a header only library and the compiler looks in /usr/include/ anyway?

Because released versions of fast_double_parser, have rather rudimentary cmake tooling, and there was no upstream provided, universal way of finding fast_double_parser (besides searching through the filesystem), so it was simply assumed that the system provided it.
In the last month there have been new changes on this front to the master branch (not released yet) of fast_double_parser, partially by the same author as in 76dd632

[biodranik]

For header-only libs we should use cmake's INTERFACE without any preconditions, instead of PRIVATE, right?

I'm sure there was a better, even faster double parser that is worth integrating. I think it was even faster than mentioned in #1659

[vitaly-zdanevich]

I hope that we can fix it soon. I know nothing about cmake so waiting for you guys...

[biodranik]

@vitaly-zdanevich it's a great opportunity to learn instead of waiting ;-)

[vitaly-zdanevich]

For header-only libs we should use cmake's INTERFACE without any preconditions, instead of PRIVATE, right?

I'm sure there was a better, even faster double parser that is worth integrating. I think it was even faster than mentioned in #1659

I do not understand this, what should I do?

[gerion0]

I do not understand this, what should I do?

On the organicmaps side, nothing is necessary, adding the library search process directly in CMake would just provide a better (and earlier in the build) error message. The next step for the Gentoo packaging process would be to write an ebuild for fast_double_parser.

[vitaly-zdanevich]

So, what to do with that now?

[gerion0]

@vitaly-zdanevich I'll make an PR with that for guru as soon as the OrganicMaps PRs are resolved.

gentoo/guru#185

[vitaly-zdanevich]

Please help, I cannot compile this :(

[biodranik]

@vitaly-zdanevich it is impossible to help without any error logs.

[vitaly-zdanevich]

Here gentoo/guru#185 (comment)

[biodranik]

Did you install libpthread dependency?

[gerion0]

Did you install libpthread dependency?

This does not exist as seperate package on Gentoo. /usr/lib64/pthreads.{a|so} is provided by sys-libs/glibc. @vitaly-zdanevich You can verify this with:

% equery files sys-libs/glibc | grep libpthread
/usr/x86_64-linux-gnu/lib64/libpthread.so.0
/usr/x86_64-linux-gnu/usr/lib64/libpthread.a
/lib/libpthread.so.0
/lib64/libpthread.so.0
/usr/lib/libpthread.a
/usr/lib64/libpthread.a

[biodranik]

The failed cmake check is clearly about the missing Threads library:

CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Threads (missing: Threads_FOUND)

Either its dev version is missing, or there is a bug in cmake module that searches for this library on gentoo.

[gerion0]

The failed cmake check is clearly about the missing Threads library

Therefore I asked to compile a binary that uses pthread, which @vitaly-zdanevich said is working.

Either its dev version is missing

Gentoo does not split out the headers in dev packages, since one always needs them to compile other packages.

or there is a bug in cmake module that searches for this library on gentoo.

It works on my Gentoo :). Maybe some configuration in the system of @vitaly-zdanevich is incorrect.

@vitaly-zdanevich You can:

1. Check, which source file CMake creates to check for threading support, compile it by yourself, check which command CMake uses to compile that binary and try to find out, what is missing. CMake should report these things in the log file.
2. Run strace on the compiler call to find out what files it tries to open (one of them should be a pthread header).

[vitaly-zdanevich]

equery files sys-libs/glibc | grep libpthread

/lib64/libpthread.so.0
/usr/lib64/libpthread.a

[vitaly-zdanevich]

1. Check, which source file CMake creates to check for threading support, compile it by yourself, check which command CMake uses to compile that binary and try to find out, what is missing. CMake should report these things in the log file.

Thanks, but this is difficult for me, what about a Google Meet call with my screen sharing?