Обсуждение: Kerberos V5 required for PostgreSQL installation on Windows

If Kerberos V5 is not installed on a Windows platform, the following
error dialog is returned upon attempted installation:

Posgres.exe - Unable to Locate Component

This application has failed to start because krb5_32.dll was not found.
Re-installing the application may fix this problem.
[OK]

We should delayload this dll since it is only needed
for specific configuration. No need to install when it is not used.

Andreas

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Dann Corbit
> Sent: Friday, February 27, 2009 2:31 AM
> To: pgsql-general@postgresql.org
> Cc: pgsql-hackers@postgresql.org
> Subject: [HACKERS] Kerberos V5 required for PostgreSQL
> installation on Windows [bayes][heur]
> Importance: Low
>
> If Kerberos V5 is not installed on a Windows platform, the following
> error dialog is returned upon attempted installation:
>
> Posgres.exe - Unable to Locate Component
>
> This application has failed to start because krb5_32.dll was
> not found.
> Re-installing the application may fix this problem.
> [OK]
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

On Fri, Feb 27, 2009 at 8:47 AM, Zeugswetter Andreas OSB sIT
<Andreas.Zeugswetter@s-itsolutions.at> wrote:
>
> We should delayload this dll since it is only needed
> for specific configuration. No need to install when it is not used.

That would require building knowledge of DLL names into the code,
which isn't practical as some projects have a habit of changing them
regularly (e.g. gettext).

I'm not sure why Dann would see this problem - all our installers
include the required DLLs, and they should also be in the
binaries-no-installer packages. If he's built the binary himself, then
he obviously has the import libraries for Kerberos, so where are the
DLLs?


-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Dave Page wrote:
> On Fri, Feb 27, 2009 at 8:47 AM, Zeugswetter Andreas OSB sIT
> <Andreas.Zeugswetter@s-itsolutions.at> wrote:
>> We should delayload this dll since it is only needed
>> for specific configuration. No need to install when it is not used.
> 
> That would require building knowledge of DLL names into the code,
> which isn't practical as some projects have a habit of changing them
> regularly (e.g. gettext).

Are you sure?

http://msdn.microsoft.com/en-us/library/hf3f62bz.aspx

seems to indicate that you can do it on just the commandline if you want to?

(I haven't tried it so I don't know if it's actually doable)


> I'm not sure why Dann would see this problem - all our installers
> include the required DLLs, and they should also be in the
> binaries-no-installer packages. If he's built the binary himself, then
> he obviously has the import libraries for Kerberos, so where are the
> DLLs?

That is also a valid question, though.

//Magnus

On Fri, Feb 27, 2009 at 9:39 AM, Magnus Hagander <magnus@hagander.net> wrote:
> Dave Page wrote:
>> On Fri, Feb 27, 2009 at 8:47 AM, Zeugswetter Andreas OSB sIT
>> <Andreas.Zeugswetter@s-itsolutions.at> wrote:
>>> We should delayload this dll since it is only needed
>>> for specific configuration. No need to install when it is not used.
>>
>> That would require building knowledge of DLL names into the code,
>> which isn't practical as some projects have a habit of changing them
>> regularly (e.g. gettext).
>
> Are you sure?
>
> http://msdn.microsoft.com/en-us/library/hf3f62bz.aspx
>
> seems to indicate that you can do it on just the commandline if you want to?

Hmm, didn't know you could do that. We'd still need code support to
figure out the DLL name from the import library so we can generate the
command line correctly though.


-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

> > We should delayload this dll since it is only needed
> > for specific configuration. No need to install when it is not used.
>
> That would require building knowledge of DLL names into the code,
> which isn't practical as some projects have a habit of changing them
> regularly (e.g. gettext).

Yup, that is bad. Seems the krb5_32.dll name is quite stable though.
Not sure if you can specify a list of anticipated names ?

> I'm not sure why Dann would see this problem - all our installers
> include the required DLLs, and they should also be in the

Oh, didn't know that. I guess that shifts it to pilot error then.

Andreas