Subject: Re: Wrong config.h in several glib-wv files?
From: James Montgomerie (jamie@montgomerie.net)
Date: Wed Jun 28 2000 - 12:11:07 CDT
On Wed, 28 Jun 2000 14:18:06 you wrote:
>
> Thanks for the fix; does the job!
>
> Once I am at it, a few more bug reports:
>
> 1) libole2/ms-ole.c contains an include for glib.h.
> Doesn't find it, as it is in ../glib-wv.
>
> 2) wv.h contains #include "ms-ole.h". Cannot find it as it is
> in libole2.
>
> 3) wvHtml.c and wvConvert.c contain a reference to a struct type
> "option". This appears to be defined in getopt.h, the inclusion
> of which makes it compile.
>
> 4) There is a dangling call to uncompress in decompresswmf.c.
> By commenting it out I get it to compile, but I'm not sure
> that's wise. WMF support appears to work now occasionally (I am
> getting PNG graphics created), but more often my conversion
> runs segfault. May not be related: acc. to gdb+core, the crash
> happens in wvAppendStr.
>
> I have an oldish Linux system: RH5.0 kernel 2.0.31, gcc-2.7.2.3-8
> and libc.so.6 points to libc-2.0.5.so (whatever that means).
I think the reason for problems 1 and 2 not being noticed in the past is that
wv has not been compied seperately from AbiWord on systems without libiconv
installed seperately. The Makefile in the iconv directory in the attached
patch has
been altered to take account of the new tree structure.
The getopt problem is caused by a stale config.h.in file. Not having a copy
of
autoheader here, I've replaced it with the one from the current release
version
of wvWare, and all appears to be well. If you apply the attached patch to a
fresh check-out of wv, and re-run ./configure, [I hope] it should compile
properly ["it works for me"(tm)].
The WMF support is beyond my current knowledge of how wv works - I may look
into it if I find the time (I'm sure any patches you'd like to make would be
welcome :-).
> I understand that a CVS cannot be production quality all the time.
> It has been almost that for a long time, however, but it isn't
> right now. Large changes to the code base? Some of these problems
> would be caught by regularly doing a complete checkout and
> recompile. Incremental upgrades may leave little things dangling
> unnoticedly, as make doesn't recompile everything either.
Remember that (as far as I've been made aware) the AbiWord wv is /only/
intended to be used in the importer - it's /not/ intended to be a stand-alone
copy of
wv. Having said that, I have been trying to keep wv in a working state, so
problem reports are still good - hopefully that the changes being made at the
moment
will eventually find their way back into the 'official' version of wvWare.
> I hope that this may help to get the situation quickly better.
> Especially the rapidly improving graphics support looks tempting.
You don't need to compile wv seperately to compile abiword - if you 'make' [or
'gmake'] in your abi directory the parts of wv required by AbiWord will be
compiled by the abi make system, which is independent of wv's make system.
The latest release version of wvWare is available from www.wvware.com.
Jamie.
P.S. I'd warn /against/ checking the attached patch into the CVS tree until it
has been tested on all the platforms (whilst it fixes them on the wv side, I
think it might bring back our getopt problems on the abi side). Please test
it on your system!
This archive was generated by hypermail 2b25 : Wed Jun 28 2000 - 11:07:51 CDT