Re: compile error gnome-vfs

[Danilo Segan <danilo gnome org>]

"J. Gardner Biggs" <gardnerbiggs houston rr com> writes:
>
> I can understand unresolved dependencies and changing configure

Actually, if configure lets something pass, and then make fails, it
is a bug in the configure script -- it doesn't check carefully
enough. So, be sure to report those at http://bugzilla.gnome.org/ for
corresponding product (i.e. gnome-vfs), and describe the problem
exactly as it is happening.

You'll probably need to include config.log or similar so someone
could see what did configure assume that it shouldn't have, so it
thought it did the job, yet it didn't :)

> arguments to point to non-standard installation prefixes.  But having to
> change CFLAGS on specific packages is a bit too much tweaking.
>

Perhaps it's also possible to pass Kerberos5 path via configure
option, so you could point package to "non-standard installation
prefixes".

This is really common problem on RedHat 9 (try searching Google for
"krb5.h RedHat 9"), and CFLAGS is a best "works-everywhere" solution 
(configure arguments might differ by their names, so you might have
--with-krb5, --enable-kerberos, etc. and it's a mess to track them
all).

It's completely safe to put this CFLAGS definition in your top-level
gar.conf.mk, because it just extends paths for includes and
libraries, but doesn't link anything that shouldn't be linked.

Also, CFLAGS is as valid mechanism of changing configure script
behaviour as is using parameters, what is suggested by running 

$ ./configure --help:
...
Some influential environment variables:
  CC          C compiler command
  CFLAGS      C compiler flags
...
Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.

$

Pay attention to "find libraries and programs with nonstandard
names/locations" -- that's exactly what you're looking for.

> I will wait for the next release and see how that goes.

I don't think anything will change in the future release with regards
to this, because it's an operating system problem, not GARNOME
problem. If you really expect everything to be flawless, I guess it
would mean waiting for Gnome 2.6 stable RPMs from RedHat, a thing I
doubt you'd like to do ;)

Of course, there might be a bug in configure script which needs to be
resolved upstream, so report it if you suspect that (it won't get
fixed if no one complains).


Cheers,
Danilo