Adam H.Pendleton wrote:
>
> On Aug 13, 2004, at 4:33 PM, Raphaël Enrici wrote:
>
>> to me it's something like this, although the ld found them. In fact,
>> I think FC1 may be more advanced than EL 3.0 or the opposite
>> concerning kerberos.
>>
>> can you confirm the following:
>> nm -D /usr/kerberos/lib/libkrb5.so.3 | grep krb5_cc_get_principal
>> should give _nothing_ on your host.
>>
>> If yes, can you try packages for RH9.
>> I played a bit with FC1 & RH9 packages and it seems that binaries
>> provided for RH9 don't refer to krb5_cc_get_principal and krb5_cc_close.
>> (see nm -a /usr/bin/pgadmin3 | grep krb5 to list the symbols pgadmin3
>> is looking for).
>>
>> That's not a definitive solution, just a try to provide you something
>> easy to install until someone try to build it for RH EL.
>>
>> If this does not work, I bet we are on the way to try a build on your
>> host. Are you ok to go with it if we guide you a bit ?
>>
> IIRC, the problem with RH kerberos link errors had to do with the fact
> that the SSL libraries linked dynamically with the kerberos libraries,
> and not including the kerberos libraries when you linked with SSL
> caused problems. Try adding -lkrb5 to the LIBS variable in
> pgadmin3/src/Makefile.
Hi Adam,
I'm not sure this is the case we face as both FC1 and RH9 binaries
refers to some krb5* symbols. I believe that FC1 and RH EL are using two
different kerberos versions which are not compatible between each other
(FC1 uses krb5 1.3.x and RH EL 3.0 seems to use 1.2.7 like what's found
on a RH9 box) but I'm surely missing something. However if we go to the
last step (rebuild on RH EL, we will try to add the flag you give).
Regards,
Raphaël