On Sunday, 23 July 2017 22:58:30 PDT Kevin Kofler wrote: > Thiago Macieira wrote: > > No, this is the solution, unless you want to build in a chroot'ed build > > root. In the environment where you're going to build a given software, you > > must not have the development packages of that software already installed. > > That is utter nonsense. Any package that picks up headers or library > symlinks from the old installed version instead of from the one you are > currently building is buggy.
You're thinking only of a 1-software problem. This is complex when you have more than one. Take this as an example: you want to build software for your professional project but not pollute your system, so you build Qt and GStreamer 1.0 but tell it to install in /opt/myproject. That means /opt/myproject/lib/pkgconfig/gstreamer-1.0.pc file has: prefix=/opt/myproject exec_prefix=/opt/myproject libdir=/opt/myproject/lib So when Qt asks pkg-config for the path to the GStreamer library, it will print: -L/opt/myproject/lib -lgstreamer-1.0 That -L switch will make the linker find Qt libraries too. Before you say, "well, list Qt libraries first", let me add another complication: the plugin has this in the linker line: -lQt5MultimediaGstTools.t -lQt5MultimediaWidgets.t -lQt5Multimedia.t -lQt5Widgets.t -lQt5Gui.t -lQt5Network.t -lQt5Core.t but if you ldd it after compiling, you find it loaded one more library (Qt5OpenGL) because of an indirect dependency. So even if qmake listed the Qt's own -L and its libraries first (and it does), we may still have a problem due to the indirect dependency and how it's found by the linker. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development