KDE, The Standard C++ Library, Boost and Apache

The Studio 12 default libCstd.so is not 100% compliant with
the 
ANSI/ISO C++ Standard, and has trouble building Boost. Boost
can be 
built with libCstd.so, but it requires numerous patches,
fixes and 
hacks.

KDE4 requires Boost [http://www.boost.org/].

RogueWave has released its implementation of the Standard
C++ Library 
+ STL under an Open Source License. This has become a
project at 
Apache: http://incubator
.apache.org/stdcxx/.

<QUOTE>
The goal of the Apache C++ Standard Library project is to
provide a 
free implementation of the ISO/IEC 14882 international
standard for 
C++ that enables source code portability and consistent
behavior of 
programs across all major hardware implementations,
operating 
systems, and compilers, open source and commercial alike.
</QUOTE>

The Apache/RogueWave Standard C++ Library builds smoothly
with Sun 
Studio 12, in both 32- and 64- bit. Replacing the original
Sun Studio 
12 libCstd.so with the Apache/RogueWave Standard C++ Library
is a 
fairly straightforward operation, and is documented in
detail here:
 
http
://docs.sun.com/app/docs/doc/819-5267/6n7c46dsk?l=en&a=v
iew&q=Replacing+Standard+C%2B%2B+Library

Barring some unforeseen problems in building and testing
Boost 1.33.1 
with the Apache/RogueWave STL over the next few days, i am
proposing 
using the Apache/RogueWave Standard C++ Library for KDE
Solaris.

A permanent side-effect of this library change is that
linking against 
Sun's libCstd.so *and* the Apache/RogueWave Standard C++
Library is 
no longer permitted.

--Stefan

-- 
Stefan Teleman			'Nobody Expects the Spanish Inquisition'
KDE e.V.						-Monty Python
stefan.telemangmail.com
___________________________________________________
This message is from the kde-solaris mailing list.
Account management:  ht
tps://mail.kde.org/mailman/listinfo/kde-solaris.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.h
tml.

On Friday 24 August 2007, Stefan Teleman wrote:
> Barring some unforeseen problems in building and
testing Boost 1.33.1
> with the Apache/RogueWave STL over the next few days, i
am proposing
> using the Apache/RogueWave Standard C++ Library for KDE
Solaris.

This makes the build approach for KDE4 as follows:

- build cmake (against whichever STL you like)
- build libungif (C deps only)
- build redland (C deps only)
- build stdcxx
- build CLucene
- build PCRE
- build KDESupport (we hope)
- build kdelibs (maybe)


-- 
These are your friends - Adem
    GPG: FEA2 A3FE Adriaan de Groot

___________________________________________________
This message is from the kde-solaris mailing list.
Account management:  ht
tps://mail.kde.org/mailman/listinfo/kde-solaris.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.h
tml.

On Saturday 25 August 2007, Adriaan de Groot wrote:
>  build PCRE
> - build KDESupport (we hope)

(not entirely trivial) there is Qt 4.3 missing in there 


-- 
These are your friends - Adem
    GPG: FEA2 A3FE Adriaan de Groot

___________________________________________________
This message is from the kde-solaris mailing list.
Account management:  ht
tps://mail.kde.org/mailman/listinfo/kde-solaris.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.h
tml.

On Friday 24 August 2007 23:18, Stefan Teleman wrote:
> The Apache/RogueWave Standard C++ Library builds
smoothly with Sun
> Studio 12, in both 32- and 64- bit. Replacing the
original Sun Studio
> 12 libCstd.so with the Apache/RogueWave Standard C++
Library is a
> fairly straightforward operation, and is documented in
detail here:

I followed about half of your instructions, Stefan, and seem
to have ended up 
with a working /opt/stdcxx ; there were definitely some
rough edges i what I 
did. From there, I went on to build pcre. That too needed
some futzing around 
as libtool snuck in -lCstd everywhere. I'm now looking at
qt-copy, and I 
think we will need to introduce a new mkspec for
solaris-cc-stdcxx.

I think it would be useful to have an SVN -- not necessarily
KDE SVN -- 
somewhere to slowly create a build system for everything.
One that builds all 
the deps, all the tools, one after another in an automated
fashion. At least 
something that codifies that you need to remove -Wall from
lib/Makefile in 
libungif and add some includes to pcre and ...
___________________________________________________
This message is from the kde-solaris mailing list.
Account management:  ht
tps://mail.kde.org/mailman/listinfo/kde-solaris.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.h
tml.

On 8/25/07, Adriaan de Groot <grootkde.org> wrote:
> On Friday 24 August 2007 23:18, Stefan Teleman wrote:
> > The Apache/RogueWave Standard C++ Library builds
smoothly with Sun
> > Studio 12, in both 32- and 64- bit. Replacing the
original Sun Studio
> > 12 libCstd.so with the Apache/RogueWave Standard
C++ Library is a
> > fairly straightforward operation, and is
documented in detail here:
>
> I followed about half of your instructions, Stefan, and
seem to have ended up
> with a working /opt/stdcxx ; there were definitely some
rough edges i what I
> did. From there, I went on to build pcre. That too
needed some futzing around
> as libtool snuck in -lCstd everywhere. I'm now looking
at qt-copy, and I
> think we will need to introduce a new mkspec for
solaris-cc-stdcxx.
>
> I think it would be useful to have an SVN -- not
necessarily KDE SVN --
> somewhere to slowly create a build system for
everything. One that builds all
> the deps, all the tools, one after another in an
automated fashion. At least
> something that codifies that you need to remove -Wall
from lib/Makefile in
> libungif and add some includes to pcre and ...

That is the plan.

This weekend is BOOST + libstdxx followed by QT + libstdcxx.
After
this, everything
goes into SVN at CVSDude.

And i can even make Sun pkg's for libstdcxx since it only
depends on
stuff in /usr/lib (and respectively /usr/lib$).

--Stefan


-- 
Stefan Teleman
KDE e.V.
stefan.telemangmail.com
___________________________________________________
This message is from the kde-solaris mailing list.
Account management:  ht
tps://mail.kde.org/mailman/listinfo/kde-solaris.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.h
tml.

On Saturday 25 August 2007, Stefan Teleman wrote:
> On 8/25/07, Adriaan de Groot <grootkde.org> wrote:
> > On Friday 24 August 2007 23:18, Stefan Teleman
wrote:
> > > The Apache/RogueWave Standard C++ Library
builds smoothly with Sun
> > > Studio 12, in both 32- and 64- bit. Replacing
the original Sun Studio
> > > 12 libCstd.so with the Apache/RogueWave
Standard C++ Library is a
> > > fairly straightforward operation, and is
documented in detail here:
> >
> > I followed about half of your instructions,
Stefan, and seem to have
> > ended up with a working /opt/stdcxx ; there were
definitely some rough
>
> This weekend is BOOST + libstdxx followed by QT +
libstdcxx. After
> this, everything
> goes into SVN at CVSDude.

OK. I have created a solaris-cc-stdcxx mkspec for Qt using
stdcxx installed 
in /opt/stdcxx, attached. You can diff the usual
solaris-cc/qmake.conf to see 
what changed. The use of % in settings inside qmake is
broken wrt. the 
configure script that qt-copy uses.

> And i can even make Sun pkg's for libstdcxx since it
only depends on
> stuff in /usr/lib (and respectively
/usr/lib$).

Huzzah!

I've now noticed that (since I'm running S10U3 still)
there's no DBUS packages 
available, so we'll have to do DBUS as well (it's on nevada,
sure).


-- 
These are your friends - Adem
    GPG: FEA2 A3FE Adriaan de Groot

___________________________________________________
This message is from the kde-solaris mailing list.
Account management:  ht
tps://mail.kde.org/mailman/listinfo/kde-solaris.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.h
tml.

On Saturday 25 August 2007 20:04, Stefan Teleman wrote:
> On 8/25/07, Adriaan de Groot <grootkde.org> wrote:
> > I think it would be useful to have an SVN -- not
necessarily KDE SVN --
> > somewhere to slowly create a build system for
everything. One that builds
> > all the deps, all the tools, one after another in
an automated fashion.
> > At least something that codifies that you need to
remove -Wall from
> > lib/Makefile in libungif and add some includes to
pcre and ...
>
> That is the plan.

Excellent. That will also codify all our decisions about
what goes where 
(speaking of which, perhap cmake should go outside of
kdesupport, since it is 
a viable third-party application which is not intimately
tied to KDE).

> This weekend is BOOST + libstdxx followed by QT +
libstdcxx. After
> this, everything
> goes into SVN at CVSDude.

At some point we are really going to have to pick one
location -- osol project 
page, solaris.kde.org or techbase -- to put information
about what is where 
and how to work it. I'd need some instructions on dealing
with CVSDude, for 
instance. My *personal* preference would be solaris.kde.org,
but techbase is 
probably much easier to work with.
___________________________________________________
This message is from the kde-solaris mailing list.
Account management:  ht
tps://mail.kde.org/mailman/listinfo/kde-solaris.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.h
tml.

On 8/26/07, Adriaan de Groot <grootkde.org> wrote:

> Excellent. That will also codify all our decisions
about what goes where
> (speaking of which, perhap cmake should go outside of
kdesupport, since it is
> a viable third-party application which is not
intimately tied to KDE).
>
> > This weekend is BOOST + libstdxx followed by QT +
libstdcxx. After
> > this, everything
> > goes into SVN at CVSDude.
>
> At some point we are really going to have to pick one
location -- osol project
> page, solaris.kde.org or techbase -- to put information
about what is where
> and how to work it. I'd need some instructions on
dealing with CVSDude, for
> instance. My *personal* preference would be
solaris.kde.org, but techbase is
> probably much easier to work with.

solaris.kde.org + techbase is the reference official
location for KDE
Solaris (at least in my view).

CVSDude is useful because we can check in/out temporary
things or
things which are
still in
flux/not-yet-ready-for-official-commit/could-you-please-test
-this-and-see-if-it-works
in there. it's not meant to be the official location, it's
just  a
sandbox/backup location.

--Stefan

-- 
Stefan Teleman
KDE e.V.
stefan.telemangmail.com
___________________________________________________
This message is from the kde-solaris mailing list.
Account management:  ht
tps://mail.kde.org/mailman/listinfo/kde-solaris.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.h
tml.

On Friday 24 August 2007, Stefan Teleman wrote:
> Barring some unforeseen problems in building and
testing Boost 1.33.1
> with the Apache/RogueWave STL over the next few days, i
am proposing
> using the Apache/RogueWave Standard C++ Library for KDE
Solaris.

It looks fine for Qt. I did find one unforeseen effect of
your install 
instructions for stdcxx: the timestamps on the various files
in include/ may 
seriously confuse Qt's makefiles. After (manually!)
installing the headers, 
go through and:

- touch *.c *.cc
- touch */*
- touch `ls -1 | grep -v '.c'`

(i.e. make sure the headers like <list> are definitely
newer than the .c files 
or Qt's makefiles will try to compile the .c into the
header.)

We will have an interesting chain of Makefiles, for sure.
What's it going to 
look like?

Makefile - do everything by callng make -f <package)
repeatedly
Makefile.libungif - unpack, patch, compile libungif
Makefile.raptor - ditto
Makefile.qt-copy - ditto
...


-- 
These are your friends - Adem
    GPG: FEA2 A3FE Adriaan de Groot

___________________________________________________
This message is from the kde-solaris mailing list.
Account management:  ht
tps://mail.kde.org/mailman/listinfo/kde-solaris.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.h
tml.

On Sunday 26 August 2007, Stefan Teleman wrote:
> On 8/26/07, Adriaan de Groot <grootkde.org> wrote:
> > > This weekend is BOOST + libstdxx followed by
QT + libstdcxx. After

I'm still soldiering on with qt-copy. There seems to be a
lost and 
dangerous -lXfixes in there. I ended up patching my
Makefiles with

-L/usr/openwin/sfw/lib -lXfixes

I'll see if I can wrangle the qmake.conf to do what we
need.

> > > this, everything
> > > goes into SVN at CVSDude.
> >
> > At some point we are really going to have to pick
one location -- osol
> > project page, solaris.kde.org or techbase -- to
put information about
> > what is where and how to work it. I'd need some
instructions on dealing
...
> solaris.kde.org + techbase is the reference official
location for KDE
> Solaris (at least in my view).

Matches my perception as well. So as a tangent to the
development work, we 
also have a website content update to do. The latest news on
solaris.k.o is 
pretty old.

> CVSDude is useful because we can check in/out temporary
things or
> . it's not meant to be the official location, it's just

> a sandbox/backup location.

OK. Do I have access to that yet? I'd like to start pushing
build recipes and 
a graphviz picture of where we are to others.


-- 
These are your friends - Adem
    GPG: FEA2 A3FE Adriaan de Groot

___________________________________________________
This message is from the kde-solaris mailing list.
Account management:  ht
tps://mail.kde.org/mailman/listinfo/kde-solaris.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.h
tml.