Re: 0.1.4 breeaks compilation on Alpha system

sterwill@io.nu
Wed, 28 Oct 1998 22:38:33 +0000 (GMT)


Thanks for trying AbiWord out... I _think_ I can solve all your problems,
and pretty easily. :) The first is an organizational problem, the one
with the architecture-dependent GCC switches (-m486, etc.). Short of
removing them completely (which wouldn't bother me), I don't see a non-
convoluted way of keeping the build process sane across all platforms
supported by a given OS (like Linux). It's simple to set your own
environment variable CFLAGS with any optimizations you may like.
I think I'll do that, since the flags in there now don't really do anything
anyway.

The second problem has to do with the location of glibconfig.h.
Starting with some version of GTK+, that file has moved on over
to /usr/local/lib/glib/include, which was not in our include search
path. Actually, a few hours after we rolled up the tarball, I noticed
this was a problem on machines that I hadn't done a symlink for (messy
fix). I've added a check at the bottom of abi_defs.mk, so that if you're
building the Unix GUI, it tacks on -I/usr/local/lib/glib/include to the
INCLUDE path. I'm now sure this was the wrong way to do it, but it
worked.

The makefile now checks if you're building for a Unix GUI and adds
the output of "gtk-config --cflags" onto the CFLAGS variable before
it goes off to build objects. If you grab the latest CVS source, these
changes should be incorporated. That single missed include caused all
those syntax errors.

As of today, Eric has committed some JavaScript work, so you'll have
to check out the js/ module from the CVS archive and build/install
it before building the updated abi/ module tree.

> Please understand that I do not claim that these problems are with your code, in
> fact it seems clear that they are with the gdk headers. I will look into this
> further when I get the time.

Nope, entirely our fault. I was using a quick fix of "ln -s
/usr/local/lib/glib/include/glibconfig.h /usr/local/include/glibconfig.h"
and I didn't notice this problem until I tried to build on another
machine. :)

> I am willing to put in as much time as I can in trying to resolve these
> problems. I really think it is important that your project remain
> platform-independent and run on all ports of Linux. If you folks can point me
> in the right direction(s) I'd like to help.

Hopefully, the system should build with the latest versions of our
tree from CVS. If you've got any other questions, just mail them here, and
I'll try to figure them out.

> My system is a SX164 Alpha running RedHat 5.0. Compiler is EGCS 1.1b. GTK+
> 1.0.6.

> Although your docs say I need gtk+1.0.5 version 1.0.6 was listed as a
> maintanance release, containing only bugfixes, was I wrong in using it?

Nope, 1.0.6 was what I was using until last week here. I've since
moved up to the latest GNOME CVS tree versions of GTK+, the 1.1.X series
so I can incorporate some of the latest widgets (notably the font
selector). Since I stuck that code in the tree today, you'll need to upgrade
to the GTK+ 1.1.X series to make this work.

Is this something you really don't want to do? I'm using 1.1.X here at home,
and since the old shared libs are still around, things like Gimp work just
fine. I'm hoping having people change to 1.1.X isn't too big a deal; but
to take advantage of the newer widgets and future GNOME integration, it's
something we've gotta do some time. The web page will be updated very
soon to reflect these changes.

If there's demand, I'll #ifdef out the font selection code so people can
use GTK+ 1.0.6, or you can do it yourself (it's in wp/ap/unix/ap_EditMethods.cpp,
in _chooseFont() if I remember correctly).

-- 
Shaw Terwilliger (sterwill@abisource.com)


This archive was generated by hypermail 1.03b2.