[kde-solaris] [kde-discuss] KBE 1.0 - Build enviroment for KDE

[Shawn Walker]

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