> On Nov. 20, 2015, 1:44 p.m., Martin Gräßlin wrote: > > The need for the change surprises me. I have been using a /opt setup for > > years and udev was always found. Can you show the error you hit? > > René J.V. Bertin wrote: > Have you been using a Linux distro like Ubuntu that has multi-arch, with > the actual libraries installed in `/[usr/]lib/x86_64-linux-gnu`? I guess it's > also not for nothing that most FindFoo scripts appear to use the 2-stage > approach where pkgconfig is queried first for hints about where to look in > addition to the default locations. BTW, I'm using cmake 3.3.1 . That's not > the host's default cmake which *may* have been patched to look in the > multi-arch locations, but in my experience it works better to use a cmake > from the target prefix (Ubuntu's Project Neon5 did the same, IIRC). > > I don't have access to the Linux system right now, but the error was that > the library wasn't being found, IIRC it did find the headerfile. The error > wasn't more explicit than that, my initial reaction was to check if I had the > libudev-dev package installed. > > René J.V. Bertin wrote: > Actually, my memory was wrong, the error is more perverse. Or rather, > was, because I cannot seem to reproduce it now :-/ > > Somehow, the configure step completed without error, set `UDEV_LIBS` (to > `udev`, I think), but for whatever reason the library wasn't added to the > link command where it should be added. So I got a link error. > > Of course I tried to rule out operator error before starting to hack the > FindUDev.cmake script, but I must have missed something, or something else > changed on my system since those few days ago. I seem to recall that I found > a libudev.so symlink in a generic (as opposed to a multi-arch) location, but > that one I can no longer find either. > > So I can either discard this RR, or else it could serve as a reason > investigate whether some FindFoo scripts need `pkg_check_modules` to obtain > hints for `find_path` and `find_library`.
I'd suggest discarding it until we can properly reproduce. Removing the build directory helps to reproduce this kind of issues, by the way. - Aleix ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126123/#review88645 ----------------------------------------------------------- On Nov. 20, 2015, 1:41 p.m., René J.V. Bertin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126123/ > ----------------------------------------------------------- > > (Updated Nov. 20, 2015, 1:41 p.m.) > > > Review request for KDE Frameworks and Kubuntu. > > > Repository: solid > > > Description > ------- > > Configuring KF5 Solid under KUbuntu 14.04 for installation in a parallel > prefix (/opt/local) it failed to find libudev which is installed "normally". > > Modifying FindUDev.cmake to follow the same approach as other Find`*.cmake > files (use pkgconfig first, and the results as hints for `find_path` and > `find_library`) corrected that failure. > > > Diffs > ----- > > cmake/FindUDev.cmake 9d0f21d > > Diff: https://git.reviewboard.kde.org/r/126123/diff/ > > > Testing > ------- > > On Kubuntu 14.04.3 with Qt 5.5.1 and all of Solid 5.16.0's KF5 dependencies > installed in /opt/local > > > Thanks, > > René J.V. Bertin > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
