KDE 4.0 on opensolaris, howto build

Hi all,

sorry, perhaps this is a stupid question but is anybody
testing KDE 4
on opensolaris ? Or does someone has any docs how to build
it on
solaris and create packages ? I'm interesting is creating
kde 4
packages for opensolaris. If anybody did same job could you
please
share your experience, 

thanks beforehand,
Murad
___________________________________________________
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.

Hi Murad,

On Thursday 30 August 2007, Murad Tagirov wrote:
> sorry, perhaps this is a stupid question but is anybody
testing KDE 4
> on opensolaris ? 

As you can see from the traffic on this list, yes, lots of
people are trying 
it and testing builds. SInce it doesn't build (easily) yet,
we're mostly 
focusing on compilation and dependencies.

> Or does someone has any docs how to build it on 
> solaris and create packages ? I'm interesting is
creating kde 4
> packages for opensolaris. If anybody did same job could
you please
> share your experience, 

I maintain a build system for KDE4 in CVSDude. It's just a
bunch of makefiles 
that download, compile and install the dependencies for KDE
and KDE itself. 
Well, as far as I've gotten, anyway. You can get it with

	svn co http:/
/svn2.cvsdude.com/kdesolaris/trunk/Build

This gives you a directory full of Makefiles. Things will be
installed as 
follows:

/opt/kdesupport -- everything else
/opt/qt-4.3 -- Qt 4.3.1
/opt/kde-4.0 -- kdelibs and onwards

You can find a little graphic showing the status of the
whole exercise in 
Build/Tools/dependencies.png, where green is OK, orange
still needs work (see 
annotation) and red is broken; black is untried.

This setup assumes that *nothing* is installed; on an
OpenSolaris box (as 
opposed to a Solaris one) it will probably download and
build stuff you 
already have. That will bloat up /opt/kdesupport a little.

As a quick start, you might do the following:

# Create directories where work will happen: source
tarballs,
# packaged tarballs and build artifacts.
mkdir ~/src ~/packages ~/build
# Create directories where results are installed.
# You may want to do this as root and do a chown on them.
mkdir /opt/kdesupport /opt/qt-4.3 /opt/kde-4.0
# Test run
gmake -f Makefile.kdelibs 
	--no-print-directory 
	WITH_OPTIONAL_DEPS=YES 
	WITHOUT_WITNESSES=IGNORE 
	all-recursive

This will crunch through and print lots of things; the
interesting bits are 
like this one:

# [kdelibs] Building dependencies qt kdesupport libungif
pcre ...
...
# [libstdcxx] No mandatory dependencies
# [libstdcxx] Witness kdesupport/include/algorithm exists

So to get kdelibs, you need qt and kdesupport and ..., it
later checks if 
other bits have already been built. If it looks vaguely
sensible to you, you 
can drop the WITHOUT_WITNESSES and then things will actually
be built (you 
may also want to drop the WITH_OPTIONAL_DEPS, to get a more
minimal system):

gmake -f Makefile.kdelibs 
	--no-print-directory 
	WITH_OPTIONAL_DEPS=YES 
	all-recursive

This will crunch on and on and on. Packages end up in
~/packages/ by default. 
These are just tarballs of the results. Builds -- and more
importantly, build 
logs -- are in ~/build/ . This system has a regrettable
tendency to carry on 
even when some compilation has failed -- I'm not sure how to
break out of a 
shell-based for loop while preserving $? .

Another approach is to use the Makefile (not one of the
component makefiles 
list Makefile.kdelibs) which will build things in a
predefined order not 
based on dependencies.

gmake

For a little more fine-grained control (I can imagine that
libstdcxx is 
problematic), build the C-based dependencies first, then
libstdcxx:

gmake ctargets libstdcxx

Note that the KDE modules are assumed to be SVN checkouts
mounted somewhere in 
your filesystem (there's no point really in trying to
compile the tarballs of 
any of the KDE4 alpha or beta releases so far). The variable
KDESVN_DIR sets 
where this is. Actually, you could untar a released tarball
somewhere and 
point KDESVN_DIR to its parent.

The CPU is assumed to be a V8 SPARC or an IA32. This affects
the build flags. 
I have a V9 SPARC but no 64-bit X libraries, so there is a
special setting 
V9-32 to accomodate that. Set CPU= on the gmake command
line.

I'm interested in people actually using this setup to build
KDE4, since I push 
Stefan's knowledge of build flags and his patches to various
bits and pieces 
into here, but I don't know if it works for anyone else. The
setup will break 
if you use too many fancy tricks in your machine setup -- I
think using GNU 
sed instead of Sun sed already bungs up the trickery used to
get libstdcxx 
working.


-- 
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.

Two things:

1) libstdcxx has a specific DIST_DIR set, which is going to
be bogus for you. 
Get the sources from Stefan or apache.org and put them
somewhere. I'll be 
fixing this tomorrow so it fetches from Apache in a normal
way.

2) kdesupport needs the patches I posted to this list
earlier, since those 
have not been committed to KDE SVN.

For me, everything below kdelibs compiles just fine now.
Libs fails on all 
kinds of things, but always trivial to fix. I'll go through
them tomorrow and 
push as much as I can upstream.

___________________________________________________
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.

Hi Adriaan,

I'll try this as well 

With the KDE release itself pushing back by two months, it
gives the
KDE Solaris Project (if i can call it that ) a couple of
more months!

All the best!
Manish Chakravarty

On 9/14/07, Adriaan de Groot <grootkde.org> wrote:
> Two things:
>
> 1) libstdcxx has a specific DIST_DIR set, which is
going to be bogus for you.
> Get the sources from Stefan or apache.org and put them
somewhere. I'll be
> fixing this tomorrow so it fetches from Apache in a
normal way.
>
> 2) kdesupport needs the patches I posted to this list
earlier, since those
> have not been committed to KDE SVN.
>
> For me, everything below kdelibs compiles just fine
now. Libs fails on all
> kinds of things, but always trivial to fix. I'll go
through them tomorrow and
> push as much as I can upstream.
>
> ___________________________________________________
> 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.
>
>


-- 
Warm Regards,
Manish Chakravarty
----
Associate Software Developer
Spike Source
+919980250606
---
___________________________________________________
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.

Hi... I've been beating my head on this for a while. 
Granted, I've been 
up a while, but I don't get what the error is.  I am
building KDE 3.5.7 on 
an AMD64 machine.  I'm building it all as 32-bit code.  I am
using GCC 
4.1.2 (hand built on this machine).  I get this error when I
try to build 
kdelibs:

gmake[4]: Entering directory `/tmp/kdelibs-3.5.7/kdecore'
/bin/bash ../libtool --silent --tag=CXX --mode=link g++ 
-Wno-long-long 
-Wundef -Wall -W -Wpointer-arith -O2 -Wno-non-virtual-dtor
-fno-exceptions 
-fno-check-new -fno-common  -DQT_CLEAN_NAMESPACE
-DQT_NO_ASCII_CAST 
-DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION     -o
kde-config -R 
/usr/local/lib -R /usr/local/lib -R /usr/local/lib 
kde-config.o 
./libkdecore.la
ld: warning: file /usr/local/lib/libstdc++.so: attempted
multiple 
inclusion of file
Undefined                       first referenced
   symbol                             in file
art_free(void*)                     ./.libs/libkdecore.so
art_alloc(unsigned int)             ./.libs/libkdecore.so
art_realloc(void*, unsigned int)    ./.libs/libkdecore.so
ld: fatal: Symbol referencing errors. No output written to 
.libs/kde-config
collect2: ld returned 1 exit status
gmake[4]: *** [kde-config] Error 1
gmake[4]: Leaving directory `/tmp/kdelibs-3.5.7/kdecore'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory `/tmp/kdelibs-3.5.7/kdecore'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/tmp/kdelibs-3.5.7/kdecore'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/tmp/kdelibs-3.5.7'
gmake: *** [all] Error 2

I am guessing these undefined symbols are in
libart_lgpl_2.so, but I am 
lacking the proper syntax to tell the build where to find
them.  The 
library doesn't have any permissions issues.  It's 32-bit. 
My 
LD_LIBRARY_PATH is set properly.  Does anyone have some
words of wisdom, 
or a post I can look back on ??  I didn't find much via
Google that helped 
out, although I did find some interesting things...

Is is safe to ignore the, "ld: warning: file
/usr/local/lib/libstdc++.so: 
attempted multiple inclusion of file" warning ??

Thanks in advance !!

-------------------
Morgan Henning
morganhitechtx.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 9/19/07, morgan henning <morganhitechtx.com> wrote:

> ld: warning: file /usr/local/lib/libstdc++.so:
attempted multiple
> inclusion of file
> Undefined                       first referenced
>    symbol                             in file
> art_free(void*)                    
./.libs/libkdecore.so
> art_alloc(unsigned int)            
./.libs/libkdecore.so
> art_realloc(void*, unsigned int)   
./.libs/libkdecore.so
> ld: fatal: Symbol referencing errors. No output written
to
> .libs/kde-config
> collect2: ld returned 1 exit status
> gmake[4]: *** [kde-config] Error 1
> gmake[4]: Leaving directory
`/tmp/kdelibs-3.5.7/kdecore'
> gmake[3]: *** [all-recursive] Error 1
> gmake[3]: Leaving directory
`/tmp/kdelibs-3.5.7/kdecore'
> gmake[2]: *** [all] Error 2
> gmake[2]: Leaving directory
`/tmp/kdelibs-3.5.7/kdecore'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/tmp/kdelibs-3.5.7'
> gmake: *** [all] Error 2
>
> I am guessing these undefined symbols are in
libart_lgpl_2.so, but I am
> lacking the proper syntax to tell the build where to
find them.  The
> library doesn't have any permissions issues.  It's
32-bit.  My
> LD_LIBRARY_PATH is set properly.  Does anyone have some
words of wisdom,
> or a post I can look back on ??  I didn't find much via
Google that helped
> out, although I did find some interesting things...
>
> Is is safe to ignore the, "ld: warning: file
/usr/local/lib/libstdc++.so:
> attempted multiple inclusion of file" warning ??

This one is just a warning, and it's harmless.

Add -lart_lgpl_2 to the link line. The linker should find it
by
default since it's in /usr/lib and you are building 32-bit.

--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.

Yeah, I tried that before I posted to the list   This is
what I get when 
I try running the compilation command for just that object,
and part of 
the reason I am confused.  Please advise if I am missing
something:

morgan:/tmp/kdelibs-3.5.7/kdecore $ /bin/bash ../libtool
--silent 
--tag=CXX --mode=link g++  -Wno-long-long -Wundef -Wall -W
-Wpointer-arith 
-O2 -Wno-non-virtual-dtor -fno-exceptions -fno-check-new
-fno-common 
-DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL
-DQT_NO_COMPAT 
-DQT_NO_TRANSLATION     -o kde-config -R /usr/local/lib -R
/usr/local/lib 
-R /usr/local/lib  kde-config.o ./libkdecore.la
-lart_lgpl_2
ld: warning: file /usr/local/lib/libstdc++.so: attempted
multiple 
inclusion of file
Undefined                       first referenced
  symbol                             in file
art_free(void*)                     ./.libs/libkdecore.so
art_alloc(unsigned int)             ./.libs/libkdecore.so
art_realloc(void*, unsigned int)    ./.libs/libkdecore.so
ld: fatal: Symbol referencing errors. No output written to 
.libs/kde-config
collect2: ld returned 1 exit status
morgan:/tmp/kdelibs-3.5.7/kdecore $

-------------------
Morgan Henning
morganhitechtx.com

On Wed, 19 Sep 2007, Stefan Teleman wrote:

> On 9/19/07, morgan henning <morganhitechtx.com> wrote:
>
>> ld: warning: file /usr/local/lib/libstdc++.so:
attempted multiple
>> inclusion of file
>> Undefined                       first referenced
>>    symbol                             in file
>> art_free(void*)                    
./.libs/libkdecore.so
>> art_alloc(unsigned int)            
./.libs/libkdecore.so
>> art_realloc(void*, unsigned int)   
./.libs/libkdecore.so
>> ld: fatal: Symbol referencing errors. No output
written to
>> .libs/kde-config
>> collect2: ld returned 1 exit status
>> gmake[4]: *** [kde-config] Error 1
>> gmake[4]: Leaving directory
`/tmp/kdelibs-3.5.7/kdecore'
>> gmake[3]: *** [all-recursive] Error 1
>> gmake[3]: Leaving directory
`/tmp/kdelibs-3.5.7/kdecore'
>> gmake[2]: *** [all] Error 2
>> gmake[2]: Leaving directory
`/tmp/kdelibs-3.5.7/kdecore'
>> gmake[1]: *** [all-recursive] Error 1
>> gmake[1]: Leaving directory `/tmp/kdelibs-3.5.7'
>> gmake: *** [all] Error 2
>>
>> I am guessing these undefined symbols are in
libart_lgpl_2.so, but I am
>> lacking the proper syntax to tell the build where
to find them.  The
>> library doesn't have any permissions issues.  It's
32-bit.  My
>> LD_LIBRARY_PATH is set properly.  Does anyone have
some words of wisdom,
>> or a post I can look back on ??  I didn't find much
via Google that helped
>> out, although I did find some interesting
things...
>>
>> Is is safe to ignore the, "ld: warning: file
/usr/local/lib/libstdc++.so:
>> attempted multiple inclusion of file" warning
??
>
> This one is just a warning, and it's harmless.
>
> Add -lart_lgpl_2 to the link line. The linker should
find it by
> default since it's in /usr/lib and you are building
32-bit.
>
> --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.
>
___________________________________________________
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 Wednesday 19 September 2007 16:41, morgan henning wrote:
> Yeah, I tried that before I posted to the list   This is
what I
> get when I try running the compilation command for just
that
> object, and part of the reason I am confused.  Please
advise if I
> am missing something:

OK.

Libtool is giving you trouble, that's what it is.

Here's a libtool *.la file for libart:

##### SNIP #####

# libart_lgpl_2.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.5 (1.1220
2003/04/05 
19:32:58)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname='libart_lgpl_2.so.2'

# Names of this library.
library_names='libart_lgpl_2.so.2.3.16 libart_lgpl_2.so.2  
libart_lgpl_2.so'

# The name of the static archive.
old_library=''

# Libraries that this one depends upon.
dependency_libs=' -lc -lm -L/usr/X11/lib'

# Version information for libart_lgpl_2.
current=2
age=3
revision=16

# Is this an already installed library?
installed=yes

# Should we warn about portability when linking against
-modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/usr/lib'

##### SNAP #####

Install this file as /usr/lib/libart_lgpl_2.la on your box,
and then, 
instead of passing -lart_lgpl_2 on the linker line, pass the
absolute 
path to this libart_lgpl_2.la file:

/usr/lib/libart_lgpl_2.la

Make sure that none of the lines in this file wrap around
when you 
copy and paste (the libtool parser will choke).

--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 Wednesday 19 September 2007 09:04, morgan henning wrote:
> art_free(void*)                    
./.libs/libkdecore.so
> art_alloc(unsigned int)            
./.libs/libkdecore.so
> art_realloc(void*, unsigned int)   
./.libs/libkdecore.so

> I am guessing these undefined symbols are in
libart_lgpl_2.so, but I am
> lacking the proper syntax to tell the build where to
find them.  The
> library doesn't have any permissions issues.  It's
32-bit.  My

Use --with-extra-libs=/usr/local/lib or similar; it's
strange that libkdecore 
would use libart but then not link to it properly.
___________________________________________________
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.

Well, I don't know if reverting to a stock Solaris 10 (6/06)
with the 
latest patches fixed my issue, or trying KDE 3.5.8 fixed it,
but this 
comes to you from a konsole session on Solaris 10/x86.

For reference: below the libart stuff below seems to have
been some kind 
of issue with the linker (a hand built gcc that used a hand
built gnu ld 
worked for the same box, but I got some other errors, so I
tried S10 
again).  The library was there.  I was pointing to it in
every way I knew 
how...  My LD_LIBRARY_PATH pointed to it, and all manner of
compile time 
flags didn't solve the issue (nor did the hand made (?) .la
file, but I 
learned about libtool from that one  ).

With my current config, the Sun included gcc 3.4.3 built KDE
fine.  I 
don't think that this was the case before, but I've tried
this so many 
times in the past couple months, that I don't remember all
the gyrations 
that I went through.

Now, after building a base KDE (kdelibs, kdebase,
kdeartwork, and some 
more building now), I am going to see if I can make it work
with all the 
possible support libraries KDE might want (OpenEXR, etc.). 
If anyone's 
interested, I can send along the flags I use to build it
all.  I have no 
idea if this would work on Sparc as a process, but until I
have everything 
flushed out on x86, I am not going to put my poor Ultra 5 to
work on KDE 
juuuust yet ;)

Has anyone else had good luck with KDE 3.5.8 ??

-------------------
Morgan Henning
morganhitechtx.com

On Wed, 19 Sep 2007, Adriaan de Groot wrote:

> On Wednesday 19 September 2007 09:04, morgan henning
wrote:
>> art_free(void*)                    
./.libs/libkdecore.so
>> art_alloc(unsigned int)            
./.libs/libkdecore.so
>> art_realloc(void*, unsigned int)   
./.libs/libkdecore.so
>
>> I am guessing these undefined symbols are in
libart_lgpl_2.so, but I am
>> lacking the proper syntax to tell the build where
to find them.  The
>> library doesn't have any permissions issues.  It's
32-bit.  My
>
> Use --with-extra-libs=/usr/local/lib or similar; it's
strange that libkdecore
> would use libart but then not link to it properly.
>
___________________________________________________
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.