Hi Devrim, thanks for the quick response!

On Mon, 24 Oct 2005 06:21 pm, Devrim GUNDUZ wrote:
> Yeah, I had no time to build RPMs for for RHEL3. Will do it later today.

When I get it built I'll put it somewhere for you to grab if you like.

> SRPM suits all Red Hat'ish platforms.

Yes, that's why I was puzzled by the seperate SRPM directories here:
http://developer.postgresql.org/~devrim/slony/1.1.2/srpms/
But perhaps one's for 8.0.3 and the other is for 8.0.4?

> This is/was a bug of RHEL 3 and it was fixed in newer versions. 

I see the same thing going back to RH7.3 (so likely also on RHEL2.1).

> Here is 
> quick solution to solve your problem:
>
> [symlinking]

OK, two issues I see with that approach:
1) even after symlinking krb5.h, the compile fails to find profile.h (also 
in /usr/kerberos/include) - yes, easy fix is to symlink that too, so not a 
big issue
2) it adds additional steps for people wanting to build from source pre 
RHEL4.0 (which I guess probably isn't that many)

I don't see any penalty for changing the spec file to include:
CPPFLAGS="${CPPFLAGS} -I%{_includedir}/et -I/usr/kerberos/include"
export CPPFLAGS
CFLAGS="${CFLAGS} -I%{_includedir}/et -I/usr/kerberos/include"
export CFLAGS

Would that be okay?

> That's weird. I've committed the fixes to RH spec file before 1.1.2 was
> released. :( The CVS version does not include those bugs.

Uh, I just went by the changelog in the file, I'll check more carefully to see 
what actually happens in the build process.

> Use make rpm to build RPMs...

'make rpm' for the source tarball still has the same issue with finding 
kerberos headers. I suppose putting -I/usr/kerberos/include in the Makefile 
would achieve the same end for us poor RHEL3.0 (and earlier) users :-) 

I'm not keen to go symlinking header files, I'd rather the build process 
worked for the platform I use, if it can be done non-intrusively. I'm not 
trying to be difficult, I just like to keep things simple. 

Regards, Philip.

-----------------
Utiba Pty Ltd 
This message has been scanned for viruses and
dangerous content by Utiba mail server and is 
believed to be clean.