Magnus Hagander wrote:
> > > > > > As for how to do it - on Windows you *can* get the
> > path of the
> > > > > > DLL that is executing your code, using GetModuleFileName().
> > > > > > Hardly cross-platform, but can be done.
> > > > >
> > > > > That sounds pretty reasonable to me.
> > > >
> > > > True, and we already have our own find_my_exec() which
> > works for Unix too.
> > >
> > > What does that have to do with this case? We're trying to find the
> > > library here.
> >
> > Oh, I see that GetModuleFileName() finds the location of your
> > library, not of the binary. Nice. So, for Win32, we use
> > that function call to find the locale directory?
> >
> > We do have a comment in port/exec.c:
> >
> > if (GetModuleFileName(NULL, retpath, MAXPGPATH) == 0)
> >
> > and I thought that did only binaries, not the library that
> > uses them. I assume if the library is a DLL, it returns the
> > DLL location, and if it is in the binary, it returns the
> > binary location.
>
> Nope, not quite.
> With the parameter NULL, it will return for the current *process*.
> You will need to use GetModuleHandle() (I think that should work) to get
> the handle of the DLL. See
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc
> /base/getmodulehandle.asp
>
> For static libaries, you need a different solution. Base that off the
> EXE?
Oh, static libs basically kills our idea. Maybe we just need to use the
environment variable solution for Win32 too.
The EXE solution would work for our client apps, and I am going to add a
putenv("NLSPATH") in those, but for 3rd-party apps that use libpq, they
could be anywhere in relation to the pgsql install. In fact, there
might be no libpq install at all because they only use pgsql clients.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
