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

List:       koffice
Subject:    Re: koffice and FreeBSD 3.2
From:       Alex Zepeda <garbanzo () hooked ! net>
Date:       1999-06-16 2:54:40
[Download RAW message or body]

On Tue, 15 Jun 1999, Marc van Kempen wrote:

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

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

Well, it generally helps if you track a stable OS.  This is why I find
Linux maddening, it's *so* disorganized.

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

This tends to indicate that sys/types.h needs to be moved up on the food
chain, but not always.

> Where the offending lines in kom.h look like:
[..]
> As far as I can see kom.h is generated by the mico idl compiler (mico 
> 2.2.7)

Could be an IDL error, could be a bunch of things.  I haven't (as of
upgrading to mico 2.2.7) tried to compile KOffice, as I'm moving to gcc
2.95.

> 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

I took the "wimpy" route and used --enable-final, and removed the last
line from orb-all.c or whatever.

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

Words cannot express my frustration with mico and shared libs.  I've got a
few different solutions tho.  The easiest thing to do was to tell it to
use .so for the shlib extension.  This is not the style(9) compliant way
to do things, but it works in a pinch.

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

Is it linking in the proper libs?  This also tends to make me think that
it didn't create the shlib properly, as I've never seen an undefined
symbol error.

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

For KOffice my guess is yes (for plugins and such).  But I'm really not
sure.

P.S. KOffice should work fine on 2.2.x, just without shlib support.

- alex


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