On Dec 11, 2007 10:27 AM, Stefan Teleman <stefan.teleman at sun.com> wrote: > Shawn Walker wrote: > > On Dec 9, 2007 4:31 PM, Alan DuBoff <alan.duboff at sun.com> wrote: > >> On Fri, 7 Dec 2007, Shawn Walker wrote: > >> > >>> I understand your argument, but because of the C++ lib mess and all of > >>> the special build options we are doing here, I don't think it's > >>> viable. > >> Why? > >> > >> All binaries should have the runpath compiled into them, and linked with > >> the proper libraries. > > > > The runpath is my issue; if the default installation location is one > > that could easily conflict or does not make it obvious that > > applications built with these are intended only for "our build of > > KDE"; then there is a problem. > > What exactly is the issue ? What is the problem ? > > -B group -z nodefaultlib. > > man ld. > > Two days ago it was "not pissing off the sysadmins". Today it's $RPATH.
The pissing off the sysadmins is still an issue I would like to see resolved. This is another, separate issue that I brought up a few days ago. So this isn't a "new one" or an excuse. I don't see how the installation path != runpath. This is my issue, which Adrian seemed to understand perfectly: /usr/lib/libqt4.so (linked against stdcxx) A binary application built on someon else's system that is *not* linked against stdcxx picks that library up and then fails. That is the issue. So, to put this in very clear terms: What is the planned installation path of the C++ dependencies we have? How will it be ensured that the C++ dependencies KDE has that are incompatible with other C++ applications not linked against stdcxx won't cause issues? Since all I keep hearing is "it's going to /usr and you'll like it or else!" I haven't been give any indication that it will be going as: /usr/lib/libqt4-stdcxx.so or: /usr/lib/qt4-stdcxx/libqt4.so -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben
