It should be an option to build against the system fmt, or if we have to use a specific version, it should not be installed to /usr/lib and /usr/lib64

[ilikenwf]

I have run into an issue where Neumodvb is building it's own fmt, which I already have installed by the system. I'm currently working around it by installing to /opt/neumodvb, however it would be nice if CMake first checked for a system fmt and used that instead?

Totally understand if there's some specific fmt version required, though, too.

neumodvb-git: /usr/include/fmt/args.h exists in filesystem (owned by fmt)
neumodvb-git: /usr/include/fmt/chrono.h exists in filesystem (owned by fmt)
neumodvb-git: /usr/include/fmt/color.h exists in filesystem (owned by fmt)
neumodvb-git: /usr/include/fmt/compile.h exists in filesystem (owned by fmt)
neumodvb-git: /usr/include/fmt/core.h exists in filesystem (owned by fmt)
neumodvb-git: /usr/include/fmt/format-inl.h exists in filesystem (owned by fmt)
neumodvb-git: /usr/include/fmt/format.h exists in filesystem (owned by fmt)
neumodvb-git: /usr/include/fmt/os.h exists in filesystem (owned by fmt)
neumodvb-git: /usr/include/fmt/ostream.h exists in filesystem (owned by fmt)
neumodvb-git: /usr/include/fmt/printf.h exists in filesystem (owned by fmt)
neumodvb-git: /usr/include/fmt/ranges.h exists in filesystem (owned by fmt)
neumodvb-git: /usr/include/fmt/std.h exists in filesystem (owned by fmt)
neumodvb-git: /usr/include/fmt/xchar.h exists in filesystem (owned by fmt)
neumodvb-git: /usr/lib/cmake/fmt/fmt-config-version.cmake exists in filesystem (owned by fmt)
neumodvb-git: /usr/lib/cmake/fmt/fmt-config.cmake exists in filesystem (owned by fmt)
neumodvb-git: /usr/lib/cmake/fmt/fmt-targets.cmake exists in filesystem (owned by fmt)
neumodvb-git: /usr/lib/pkgconfig/fmt.pc exists in filesystem (owned by fmt)
neumodvb-git: /usr/lib64 exists in filesystem (owned by filesystem)

[ilikenwf]

This may be something weird with arch's build system...not sure yet.

xbmc has a nice FindFmt.cmake :
https://github.com/xbmc/xbmc/blob/master/cmake/modules/FindFmt.cmake

[ilikenwf]

...I seem to be ok with it now with some adjustments, however is it necessary to have Neumodvb bring it's own fmt when it's already installed in the system libs?

[ilikenwf]

Nevermind...my workarounds failed. Guess I need to figure out how to get system fmt working.

[ilikenwf]

This appears to get it built without conflicting with the local system at least - just going built in instead of dynamic:

# Prevent fmt from being installed system-wide
set(FMT_INSTALL OFF CACHE BOOL "Disable installation of fmt" FORCE)

[deeptho]

This appears to get it built without conflicting with the local system at least - just going built in instead of dynamic:

# Prevent fmt from being installed system-wide
set(FMT_INSTALL OFF CACHE BOOL "Disable installation of fmt" FORCE)

Where should this be placed?

There is a reason for using non standard packages: specifically when the installed versions are not new enough (eg. ubuntu is often very outdated).

Also, there is no need to install neumodvb. Just run from where it was compiled. This is how most people
run it, and so it is better tested (but I want installation to work as well)

[ilikenwf]

Here's a patch: https://aur.archlinux.org/cgit/aur.git/plain/static-build-fmt.patch?h=neumodvb-git

I can pull request if you want though.

In the case of Arch, I have the opposite issue at times where packages are too new...haha. Having it packaged is just nice.

[deeptho]

Patch is fine (for such a simple thing). Will be in next version.

[ilikenwf]

Current master is crashing for me whenever I try to scan or tune, it can see the spectrum though...I'm going to build the 1.7 tag and see if it does any better.

[ilikenwf]

/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../include/c++/14.2.1/optional:475: _Tp &std::_Optional_base_impl<devdb::fe_t, std::_Optional_basedevdb::fe_t>::_M_get() [_Tp = devdb::fe_t, _Dp = std::_Optional_basedevdb::fe_t]: Assertion 'this->_M_is_engaged()' failed.

[ilikenwf]

Is my gcc stdlib too new? @deeptho

[ilikenwf]

Just because I got it working right in headend now, doesn't mean I don't want to get neumo working for all the stranger stuff that can be discovered on these satellites.

[deeptho]

You should compile using clang, not gcc. And if something does not work, you need to provide useful information to figure out the problem. neumo.log, debug.log, any asserttions printed on the console + a description on how the problem can be made to occur.

I doubt that any library is too new. At most that should cause compilation problems.

[andimik]

You should compile using clang, not gcc

Could you please write in the Readme how to do that? I guess others have the same problem.

Lots of us are users, not programmers.

[deeptho]

No need: it is in the CMakeLists.txt file and the instructions already explain the prerequisites. If you make a similar list for ArchLinux, I am willing to add it to install.md