Обсуждение: Re: Couldn't make check
> -----Original Message----- > From: Hisaji ONO [mailto:hi_ono2001@ybb.ne.jp] > Sent: 07 May 2004 16:48 > To: pgsql-hackers-win32@postgresql.org > Subject: [pgsql-hackers-win32] Couldn't make check > > Hi. > > I've succeeded to make postgresql in latest msys/mingw. > > However I've got following message. > > initdb.exe - couldn't find the component - > > couldn't find libpq.dll....... Try modifying your path - I use: export PATH=$PATH:/usr/local/pgsql/lib:/usr/local/pgsql/bin in the msys /etc/profile - something similar in the system path should help from cmd.exe. Regards, Dave
> However I've got following message. > > initdb.exe - couldn't find the component - > > couldn't find libpq.dll....... 1. did you run make install? 2. add pgsql\bin and pgsql\lib to your path (usually installed into the msys folder). Merlin
Dave Page wrote: > > > > >>-----Original Message----- >>From: Hisaji ONO [mailto:hi_ono2001@ybb.ne.jp] >>Sent: 07 May 2004 16:48 >>To: pgsql-hackers-win32@postgresql.org >>Subject: [pgsql-hackers-win32] Couldn't make check >> >>Hi. >> >> I've succeeded to make postgresql in latest msys/mingw. >> >>However I've got following message. >> >>initdb.exe - couldn't find the component - >> >>couldn't find libpq.dll....... >> >> > >Try modifying your path - I use: > >export PATH=$PATH:/usr/local/pgsql/lib:/usr/local/pgsql/bin > >in the msys /etc/profile - something similar in the system path should >help from cmd.exe. > > > Yes, but it's a hack - we need pg_regress to set up the path to the temp install correctly, not to rely on having installed first. cheers andrew
It's rumoured that Andrew Dunstan once said: > Dave Page wrote: > > > Yes, but it's a hack - we need pg_regress to set up the path to the > temp install correctly, not to rely on having installed first. Modifying the pg_regress script isn't going to help for daily use of psql. and other apps that want to use libpq.dll. We need a more robust solution such as a mod to the system path, or, I know you can register .exe locations in the registry - dunno if you can do that for a dll as well. Regards, Dave
Dave Page said: > It's rumoured that Andrew Dunstan once said: >> Dave Page wrote: >> >> >> Yes, but it's a hack - we need pg_regress to set up the path to the >> temp install correctly, not to rely on having installed first. > > Modifying the pg_regress script isn't going to help for daily use of > psql. and other apps that want to use libpq.dll. We need a more robust > solution such as a mod to the system path, or, I know you can register > .exe locations in the registry - dunno if you can do that for a dll as > well. But the question was not about daily use of pgsql. It was specifically about running 'make check', for which we should *not* rely on existing environment settings. What if we have version A installed and we want to test version B? If we rely on existing PATH settings we'll pick up the wrong DLLs. On Unix pg_regress supplies a special LD_LIBRARY_PATH, to find the temp_install libraries, on Cygwin it supplies a special PATH for the same purpose. The correct fix for MINGW is a one line change to pg_regress.sh to do the same thing in this respect as it does on cygwin. For daily use I agree that we should also do something. One possibility is to put the DLLs into the bin directory instead of into a separate lib directory. IIRC, Windows executables always search their own location first for wanted DLLs before searching the PATH. Alternatively, we could have the installer modify the system path. cheers andrew
Andrew Dunstan wrote: > But the question was not about daily use of pgsql. It was specifically > about running 'make check', for which we should *not* rely on existing > environment settings. What if we have version A installed and we want > to test version B? If we rely on existing PATH settings we'll pick up the > wrong DLLs. One further data-point. I run 'make check' under MingW just fine, without any changes to PATH (via pg_regress, the command line, or otherwise). Only changes to head are those to resolve PKGLIBDIR and friends, which iirc Bruce is working on. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
Claudio Natoli said: > > Andrew Dunstan wrote: >> But the question was not about daily use of pgsql. It was specifically >> about running 'make check', for which we should *not* rely on existing >> environment settings. What if we have version A installed and we want >> to test version B? If we rely on existing PATH settings we'll pick up >> the wrong DLLs. > > One further data-point. I run 'make check' under MingW just fine, > without any changes to PATH (via pg_regress, the command line, or > otherwise). Only changes to head are those to resolve PKGLIBDIR and > friends, which iirc Bruce is working on. > Did you by any chance run configure with bindir and libdir set to the same directory? If not, how does it know where to find the temp_install DLLs? cheers andrew
It's rumoured that Andrew Dunstan once said: > > For daily use I agree that we should also do something. One possibility > is to put the DLLs into the bin directory instead of into a separate > lib directory. IIRC, Windows executables always search their own > location first for wanted DLLs before searching the PATH. iirc they search the current directory, system32 directory and then the path. Moving the .dll's is probably easiest and has least effect on the rest of the system - plus, it's easy to do in an installer. > Alternatively, we could have the installer modify the system path. As with the regression test problem you pointed out, that will make 2 installations on the same machine unfeasible, or at least much more awkward. Regards, Dave
Dave Page wrote: > It's rumoured that Andrew Dunstan once said: > > > > For daily use I agree that we should also do something. One possibility > > is to put the DLLs into the bin directory instead of into a separate > > lib directory. IIRC, Windows executables always search their own > > location first for wanted DLLs before searching the PATH. > > iirc they search the current directory, system32 directory and then the > path. Moving the .dll's is probably easiest and has least effect on the > rest of the system - plus, it's easy to do in an installer. > > Alternatively, we could have the installer modify the system path. > > As with the regression test problem you pointed out, that will make 2 > installations on the same machine unfeasible, or at least much more > awkward. I am about to post a plan to allow relocatable installs. -- 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