Re: help request: libksysguard build failure on Stream 8

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Thu, Jun 24, 2021 at 8:31 PM Yaakov Selkowitz <yselkowi@xxxxxxxxxx> wrote:
On Thu, 2021-06-24 at 15:40 -0700, Troy Dawson wrote:
> On Wed, Jun 23, 2021 at 9:25 AM Yaakov Selkowitz <yselkowi@xxxxxxxxxx>
> wrote:
>
> > On Wed, 2021-06-23 at 08:56 -0700, Troy Dawson wrote:
> > > I'm updating/ rebuilding KDE Plasma Desktop on CentOS Stream 8, for the
> > > updated qt5 that is there.  I am using what is in F34 for the update.
> > > I've got all the qt5 5.15.2 and kf5 5.83.0 packages built and in the
> > > buildroot.
> > > For libksysguard I believe I have all other dependencies built and in the
> > > buildroot.
> > > But it just keeps failing, despite everything I've tried.[1][2]
> > > I get the same error on all arches.  The same error on version 5.22.1,
> > > 5.22.2 and even 5.21.4.
> > > I've tried passing build parameters that I thought went along with the
> > > error, but nothing changed.
> > >
> > > I think this is the critical error, but it's possible I'm wrong
> > >
> > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function
> > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone
> > > .localalias.209]':
> > > /usr/include/c++/8/bits/fs_path.h:185: undefined reference to
> > > `std::filesystem::__cxx11::path::_M_split_cmpts()'
> > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function
> > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone
> > > .localalias.209]':
> > > /usr/include/c++/8/bits/fs_dir.h:371: undefined reference to
> > >
> > `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::files
> > ys
> > > tem::__cxx11::path
> > > const&, std::filesystem::directory_options, std::error_code*)'
> > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function
> > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*)':
> > > /builddir/build/BUILD/libksysguard-
> > > 5.22.2.1/processcore/cgroup_data_model.cpp:447:
> > > undefined reference to
> > > `std::filesystem::__cxx11::directory_iterator::operator*() const'
> > > /builddir/build/BUILD/libksysguard-
> > > 5.22.2.1/processcore/cgroup_data_model.cpp:447:
> > > undefined reference to
> > > `std::filesystem::__cxx11::directory_iterator::operator++()'
> > > CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function
> > > `KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone
> > > .localalias.209]':
> > > /usr/include/c++/8/bits/fs_dir.h:260: undefined reference to
> > > `std::filesystem::status(std::filesystem::__cxx11::path const&)'
> > > collect2: error: ld returned 1 exit status
> >
> > std::filesystem was originally added as an experimental extension to C++,
> > and
> > at first required explicitly linking with -lstdc++fs.  GCC 9 removed the
> > requirement for the additional link library [1], but RHEL 8's default
> > compiler
> > is GCC 8.  Therefore, for EPEL 8, you would have to create a patch which
> > adds
> > stdc++fs to the target_link_libraries of the processcore target.
> >
> > [1] https://gcc.gnu.org/gcc-9/changes.html
> >
> > HTH,
> >
>
> My cmake skills are not up to snuff.  A little more help is needed.
> I seems -lstdc++fs needs to be added at the end of the compile command
>   /usr/bin/c++ <options and other stuff> -lstdc++fs
> instead of at the beginning or middle of the options
>   /usr/bin/c++ -lstdc++fs <options and other stuff>
>
> I can do that manually, and it compiles correctly.
>
> But getting cmake to do it, I'm clearly missing something.
> Is there a cmake command line option to put -lstdc++fs at the end?
> There are several cmake and cmake.in files.  Would I put it in one, and if
> so, what is the syntax?

Add stdc++fs to the end of this list:

https://github.com/KDE/libksysguard/blob/master/processcore/CMakeLists.txt#L29-L39

That did it.  Thank you very much.
Not only am I unblocked, but my cmake skills are a little bit better.

Troy


_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux