[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: koffice and FreeBSD 3.2
From:       Marc van Kempen <marc () bowtie ! nl>
Date:       1999-06-15 9:50:17
[Download RAW message or body]

> On Mon, 14 Jun 1999, Marc van Kempen wrote:
> 
> > Hopefully, that will solve my other problems too. By the way, since 
> > you're implying that I should run FreeBSD-CURRENT, do you run FreeBSD? 
> > and how does koffice run for you?
> 
> Actually, no, I really wouldn't recommend -CURRENT for you.  But it seems
> like -CURRENT is getting all the NFS and mmap related bugfixes, and in
> general a whole lot more attention.
> 
I know, but the stability of the OS is not in question here, although
-CURRENT seems to be even more stable than -RELEASE from time to time ;-)

What may be related is the integration of the egcs compiler in to the 
OS. Did you ever succeed at compiling koffice with 3.x or -CURRENT 
before egcs was introduced as the system compiler?

> Yes, I run FreeBSD (a reasonably up to date -CURRENT box), and KOffice
> runs as well as it would on Linux, which is to say there are quite a few
> mysterious crashes, but I doubt that they're attributable to FreeBSD.
> 
Ok, that gives me some hope of getting it to run, although I feel
like targeting a duck flying at 100mph ;-).

> P.S. By the egcs port I meant the straight egcs port (ports/devel/egcs),
> which is currently at 1.1.2 (as is -CURRENT).  patch-af seems to do most
> of the required FreeBSDtweaking.  So far egcs 1.1.2 has proven itself very
> stable for me.
> 
Ok, I already mentioned this in my first post, I'm using egcs 1.1.2 from
the port collection on FreeBSD 3.1-stable from April.

Right now, I'm stuck in koffice with the following error:
(koffice and kdelibs cvsupp'ed yesterday afternoon)

eg++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../lib/koml -I../../lib/koml \
-I../../lib/store -I../../lib/store -I./../ -I/usr/local/kde-2.0/include/idl \
-I/usr/local/kde-2.0/include -I/usr/local/qt-2.0-19990614/include \
-I/usr/X11R6/include -I/usr/local/mico/include -O2 -Wall -Wp,-MD,.deps/koDocument.pp \
-c  -fPIC -DPIC koDocument.cc -o koDocument.lo In file included from koffice.h:20,
                 from koDocument.h:26,
                 from koDocument.cc:23:
/usr/local/kde-2.0/include/idl/kom.h:85: warning: ANSI C++ forbids typedef which does \
                not specify a type
/usr/local/kde-2.0/include/idl/kom.h:85: parse error before `;'
/usr/local/kde-2.0/include/idl/kom.h:86: warning: ANSI C++ forbids typedef which does \
                not specify a type
/usr/local/kde-2.0/include/idl/kom.h:86: parse error before `;'
/usr/local/kde-2.0/include/idl/kom.h:91: confused by earlier errors, bailing out
gmake[3]: *** [koDocument.lo] Error 1
gmake[3]: Leaving directory `/usr2/local/src/kde/cvsup/koffice/lib/kofficecore'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/usr2/local/src/kde/cvsup/koffice/lib'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr2/local/src/kde/cvsup/koffice'
gmake: *** [all-recursive-am] Error 2


Where the offending lines in kom.h look like:

83:    };
84:
85:    typedef ExceptVar<UnknownSignal> UnknownSignal_var;
86:    typedef UnknownSignal_var UnknownSignal_out;
87:
88:    static CORBA::TypeCodeConst _tc_UnknownSignal;

As far as I can see kom.h is generated by the mico idl compiler (mico 
2.2.7)

I had trouble getting mico 2.2.7 to compile, but 
I eventually managed to get it to compile using a patch from 
the mico mailing list, which said to move 

void
CORBA::Exception::_raise (void)
{   
    ::mico_throw (*this);
}  

from include/mico/throw.h to orb/dii.cc

(In throw.h it was defined as inline)

I'm surprised you didn't have any problems with this or the configure script 
barfing about dynamic libraries and dynamic loading, when I run the
configure script for mico it fails for dynamic linking because there
is no symlink from libshtest.so.1.0 to libshtest.so, when I create it
it works ok, however the dynamic loading is really puzzling:

./configure --disable-mini-stl --disable-optimize --prefix=/usr/local/mico

..
..
checking for dynamic loading... ./libshtest.so.1.0: Undefined symbol \
"__ls__7ostreamPFR7ostream_R7ostream"

I hacked around it by overriding the define in configure that sets
dynamic loading to "yes", after that it compiles ok. I have no idea
why it fails to resolve the dynamic object, as far as I know it should
work. 

By the way, do I have to have dynamic loading?

Regards,
Marc.

----------------------------------------------------
Marc van Kempen                 BowTie Technology     
Email: marc@bowtie.nl            WWW & Databases
tel. +31 40 2 43 20 65         
fax. +31 40 2 44 21 86         http://www.bowtie.nl
----------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]