$ emerge kicad These are the packages that would be merged, in reverse order: Calculating dependencies .... done! Dependency resolution took 8.59 s. [ebuild U *] sci-electronics/kicad-9999 [7.0.2] >>> Verifying ebuild manifests >>> Running pre-merge checks for sci-electronics/kicad-9999 * Checking for at least 900 MiB disk space at "/var/tmp/portage/sci-electronics/kicad-9999/temp" ... [ ok ] >>> Emerging (1 of 1) sci-electronics/kicad-9999::gentoo >>> Installing (1 of 1) sci-electronics/kicad-9999::gentoo >>> Completed (1 of 1) sci-electronics/kicad-9999::gentoo >>> Failed to install sci-electronics/kicad-9999, Log file: >>> '/var/tmp/portage/sci-electronics/kicad-9999/temp/build.log' <snip> * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at https://bugs.gentoo.org/ unless you report exactly * which two packages install the same file(s). See * https://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how * to solve the problem. And once again, please do NOT file a bug report * unless you have completely understood the above message. * * Detected file collision(s): * * /usr/lib64/pkgconfig/fmt.pc * /usr/lib64/cmake/fmt/fmt-config-version.cmake * /usr/lib64/cmake/fmt/fmt-targets.cmake * /usr/lib64/cmake/fmt/fmt-config.cmake * /usr/lib64/cmake/fmt/fmt-targets-relwithdebinfo.cmake * /usr/include/fmt/ranges.h * /usr/include/fmt/printf.h * /usr/include/fmt/ostream.h * /usr/include/fmt/core.h * /usr/include/fmt/args.h * /usr/include/fmt/compile.h * /usr/include/fmt/format-inl.h * /usr/include/fmt/color.h * /usr/include/fmt/format.h * /usr/include/fmt/os.h * /usr/include/fmt/chrono.h * /usr/include/fmt/xchar.h * /usr/include/fmt/std.h * /usr/lib64/libfmt.so * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * dev-libs/libfmt-9.1.0-r1:0::gentoo * /usr/include/fmt/args.h * /usr/include/fmt/chrono.h * /usr/include/fmt/color.h * /usr/include/fmt/compile.h * /usr/include/fmt/core.h * /usr/include/fmt/format-inl.h * /usr/include/fmt/format.h * /usr/include/fmt/os.h * /usr/include/fmt/ostream.h * /usr/include/fmt/printf.h * /usr/include/fmt/ranges.h * /usr/include/fmt/std.h * /usr/include/fmt/xchar.h * /usr/lib64/cmake/fmt/fmt-config-version.cmake * /usr/lib64/cmake/fmt/fmt-config.cmake * /usr/lib64/cmake/fmt/fmt-targets-relwithdebinfo.cmake * /usr/lib64/cmake/fmt/fmt-targets.cmake * /usr/lib64/libfmt.so * /usr/lib64/pkgconfig/fmt.pc * * Package 'sci-electronics/kicad-9999' NOT merged due to file * collisions. If necessary, refer to your elog messages for the whole * content of the above message.
Created attachment 865774 [details] emerge --info
Upstream master recently switched to fmt 10. So I unmasked dev-libs/libfmt-10.0.0 on my system. Same result. * Detected file collision(s): * * /usr/lib64/libfmt.so.10.0.0 * /usr/lib64/pkgconfig/fmt.pc * /usr/lib64/cmake/fmt/fmt-config-version.cmake * /usr/lib64/cmake/fmt/fmt-targets.cmake * /usr/lib64/cmake/fmt/fmt-config.cmake * /usr/lib64/cmake/fmt/fmt-targets-relwithdebinfo.cmake * /usr/include/fmt/ranges.h * /usr/include/fmt/format.h * /usr/include/fmt/core.h * /usr/include/fmt/args.h * /usr/include/fmt/chrono.h * /usr/include/fmt/printf.h * /usr/include/fmt/std.h * /usr/include/fmt/os.h * /usr/include/fmt/xchar.h * /usr/include/fmt/ostream.h * /usr/include/fmt/compile.h * /usr/include/fmt/color.h * /usr/include/fmt/format-inl.h * /usr/lib64/libfmt.so.10 * /usr/lib64/libfmt.so * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * dev-libs/libfmt-10.0.0:0::gentoo * /usr/include/fmt/args.h * /usr/include/fmt/chrono.h * /usr/include/fmt/color.h * /usr/include/fmt/compile.h * /usr/include/fmt/core.h * /usr/include/fmt/format-inl.h * /usr/include/fmt/format.h * /usr/include/fmt/os.h * /usr/include/fmt/ostream.h * /usr/include/fmt/printf.h * /usr/include/fmt/ranges.h * /usr/include/fmt/std.h * /usr/include/fmt/xchar.h * /usr/lib64/cmake/fmt/fmt-config-version.cmake * /usr/lib64/cmake/fmt/fmt-config.cmake * /usr/lib64/cmake/fmt/fmt-targets-relwithdebinfo.cmake * /usr/lib64/cmake/fmt/fmt-targets.cmake * /usr/lib64/libfmt.so.10 * /usr/lib64/libfmt.so.10.0.0 * /usr/lib64/pkgconfig/fmt.pc * * Package 'sci-electronics/kicad-9999' NOT merged due to file * collisions. If necessary, refer to your elog messages for the whole * content of the above message. * * The following package has failed to build, install, or execute postinst: * * (sci-electronics/kicad-9999:0/0::gentoo https://gitlab.com/kicad/code/kicad/-/blob/master/CMakeLists.txt#L1036 add_subdirectory( thirdparty ) https://gitlab.com/kicad/code/kicad/-/blob/master/thirdparty/CMakeLists.txt#L33 add_subdirectory( fmt ) We need a way to disable the building of thirdparty libs and use system libs as it is for glew. My last successful install of sci-electronics/kicad-9999 was 6. Jul 07:16 /usr/bin/kicad equery f kicad does not show fmt.
Created attachment 865806 [details, diff] kicad_system_fmt.patch A quick patch based on my analysis above. Seems to work. Please test it. Should kicad ebuild have a dep on dev-libs/libfmt then? With slot?
It seems that Kicad decided witch version of libfmt, they moved to 10 and that creates a compilation problem. The attached patch allows kicad to compile with libfmt-9.
Created attachment 866006 [details, diff] Patch to support libfmt-9
(In reply to Alexandre Ferreira from comment #4) > It seems that Kicad decided witch version of libfmt, they moved to 10 and > that creates a compilation problem. The attached patch allows kicad to > compile with libfmt-9. Would it work if we remove the version number there?
https://gitlab.com/kicad/code/kicad/-/issues/15306 "Built-in fmt and system fmt conflict" https://gitlab.com/kicad/code/kicad/-/commit/b95b07e54dffa13096f747c049b600bbfe3c5913 "Turn off the FMT_INSTALL opt" So should we still disable the build of bundled fmt and use the system libfmt for the kicad build even if upstream seems to not want that? Me - yes.
Is it even still built after the upstream change?
(In reply to jospezial from comment #8) > Is it even still built after the upstream change? Yes! They disabled the install of libfmt only. Not the build.
Created attachment 866821 [details, diff] kicad_system_fmt.patch Updated to latest upstream change. The libfmt-9 change should be done in another patch.
KiCad upstream fixed this, which means it won't try to override system dev-libs/libfmt. > So should we still disable the build of bundled fmt and use the system libfmt for the kicad build even if upstream seems to not want that? I don't think we want to open this can of worms. The "thirdparty" directory contents are statically linked into KiCAD. If we were to allow for dev-libs/libfmt to be used from the system instead, then why not also allow for all the other third party libraries found in portage? Since upstream clearly does not support this use case and in each release they are building against specific versions of said libraries, this would open the door for a lot of potential compatibility problems both during build and runtime. However it seems I need to update the license list for KiCad due to new libraries included in thirdparty, so at least there is some good outcome from this bug ;)
(In reply to Zoltan Puskas from comment #11) > KiCad upstream fixed this, which means it won't try to override system > dev-libs/libfmt. > > > So should we still disable the build of bundled fmt and use the system libfmt for the kicad build even if upstream seems to not want that? > > I don't think we want to open this can of worms. The "thirdparty" directory > contents are statically linked into KiCAD. If we were to allow for > dev-libs/libfmt to be used from the system instead, then why not also allow > for all the other third party libraries found in portage? > That's precisely what our policy is in Gentoo (https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies). Now, we can make exceptions, and actually, libfmt is a good argument for one because it breaks *all the time*. But please don't apply this argument to libraries in general simply because upstream do bundle them. > Since upstream clearly does not support this use case and in each release > they are building against specific versions of said libraries, this would > open the door for a lot of potential compatibility problems both during > build and runtime. That's what a testsuite is for.
