CVS, Oct 30, Build errors on x86_64

[Derek Atkins]

Quoting Karl Hegbloom <hegbloom at pdx.edu>:

> On Mon, 2005-10-31 at 09:00 -0500, Josh Sled wrote:
>> On Sun, 2005-10-30 at 23:36 -0800, Karl Hegbloom wrote:
>> > I won't have time to try and fix these; I'm way behind on my Mathematics
>> > homework and should really be working on that instead...
>> >
>> > Hope this helps.  Do yous have an AMD64 to test compile on?
>>
>> Only vicariously through souls like yourself... :)
>>
>> ...but the issue here isn't x86_64 specific: the GSF_CLASS_FULL macro
>> errors in the lib/goffice/ code are due to a macro signature difference
>> in <=libgsf-1.12.1 and >=libgsf-1.12.2.
>>
>> Neil Williams had put in a check re: libgoffice / libgsf to work around
>> this on his Debian Unstable box.  What system-installed versions of
>> libgsf and libgoffice do you have?
>
> libgsf-1-dev       1.12.3-3ubuntu3
> libgsf-gnome-1-dev 1.12.3-3ubuntu3
>
> libgoffice-1-dev was not installed at all.  I just installed version
> 0.0.4-1, also from Ubuntu.
>
> I don't know how it was able to finish 'configure' and compile as much
> as it did if it requires libgoffice.  Perhaps a 'configure.in' check for
> that is not present?  It probably would fail to link without it.

There's an internal version of libgoffice that Gnucash tries to build. 
Unfortunately it only builds with "older" libgsf.  So you have a "too 
new"
libgsf but no libgoffice, which is the one part of the matrix that is known to
fail.  You are correct, there should be a configure switch that fails during
configure if it finds a too-new libgsf but no libgoffice.

However, it is perfectly legal to build w/o libgoffice installed...

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available