Building balsa on Tru64 UNIX (without pspell)

[jkunz unixag-kl fh-kl de]

Hi.

I am working on a port of Balsa 1.2.3 to Compaq Tru64 UNIX 5.1 using the
Compaq cc / cxx compilers 6.4. My experiences up to now:

Building fancy GNUware like all that GNOME stuff on a 64 bit / non ia32,
non Linux, non gcc, non glibc, non ... system is masochism. ;-)

Whe website mentions that pspell and libesmtp are absolutely required.
After spendig houres to get libesmtp compiled, I read in the FAQ that it
is actually possible to build balsa without libesmtp. In this case a
local MTA like sendmail is required. And that is exactely what I want
to have: The local MUA uses the local MTA. So there should be a litle
note about building without libesmtp on the requirements section...

Big problem (for me): pspell. pspell uses some functionality of the
iostream lib that is simply not present in the Compaq / DEC
implementation. glibc and the *BSD libc have that, so no problem there. 
cxx: Error: config_impl.cc, line 653: class "ios" has no member "fmtflags"
  ios::fmtflags f = out.flags();
-------^
As I have no clue about that C++ stuff, I really need external help to
get a workaround for that.

One possible solution would be to make pspell optional for balsa. I
would prefere that, as i don't like spell checker. (I think you already
noticed that. ;-)  )

Please help me to solve that pspell problem and to get rid of mutt.
(mutt is fine, but 1006601344 seconds since the UNIX Epoch is a time
where I prefere to use a MUA with a powerful GUI interface instead of a
text mode interface that was modern 25 years ago.)

I started to compile balsa with a faked pspell interface / commented out
the spell check related funktions. This gives errors about unresolved
references while linking the final executable. That was expected and the
executable will not run of course. But I was able to compile balsa and
work on all the other problems I encountered: libmutt exports some
symbols like "CONTEXT" that are already declared by the libc. So I had
to rename them to "MAIL_CONTEXT"... Some compiler issues (gcc may accept
to do a typedef on a struct that is declared later. cxx insist on an
already declared struct when it is used in a typedef.) Some other things
and a bunch of warnings I did not investigate yet. 

Be prepared to receive a buch of patches.
-- 



tschuess,
          Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz