Обсуждение: Novice Guide to Windows Compile How to
Novice Guide to Windows Compile How to
От
"V i s h a l Kashyap @ [Sai Hertz And Control Systems]"
Дата:
Hi, I was successfull today with installation of MinGW MinSys and then compilation of PostgreSQL on an WindowsXP SP1. I have documented all my steps for my convinience and would like to know if someone else needs it or more appropriatly would the document be accepted as PostgreSQL Windows How to ? If this has been already done then sorry I waisted you and mine time. Suggestions / Comments / Ideas Most welcome -- Best Regards, Vishal Kashyap Director / Lead Developer, Sai Hertz And Control Systems Pvt Ltd, http://saihertz.rediffblogs.com Jabber IM: vishalkashyap@jabber.org ICQ : 264360076 Yahoo IM: mailforvishal@yahoo.com ----------------------------------------------- You yourself, as much as anybody in the entire universe, deserve your love and affection. - Buddha --------------- pgsql=# select marital_status from vishals_life; marital_status ------------------ Single not looking 1 Row(s) affected ___ //\\\ ( 0_0 ) ----------------o0o-----o0o---------------------
> Hi, > > I was successfull today with installation of MinGW MinSys and then > compilation of PostgreSQL on an > WindowsXP SP1. > > I have documented all my steps for my convinience and would like to > know if someone else needs it or more appropriatly > would the document be accepted as PostgreSQL Windows How to ? > > If this has been already done then sorry I waisted you and mine time. > > Suggestions / Comments / Ideas Most welcome I would imagine there is going to be a win32 specific section to the documentation which contains installation instructions and compilation instructions. I would suggest posting on docs mailing list to see if anybody is working on that part. Merlin
Re: Novice Guide to Windows Compile How to
От
"V i s h a l Kashyap @ [Sai Hertz And Control Systems]"
Дата:
Hi all , Find the PDF version at http://vishalkashyap.speedpost.net/1_beta.zip Suggestions / Comments / Ideas Most welcome -- Best Regards, Vishal Kashyap Director / Lead Developer, Sai Hertz And Control Systems Pvt Ltd, http://saihertz.rediffblogs.com Jabber IM: vishalkashyap@jabber.org ICQ : 264360076 Yahoo IM: mailforvishal@yahoo.com ----------------------------------------------- You yourself, as much as anybody in the entire universe, deserve your love and affection. - Buddha --------------- pgsql=# select marital_status from vishals_life; marital_status ------------------ Single not looking 1 Row(s) affected
Hi! Good to see something along this line. Couple of comments: 1) I would not suggest copying the LIB directory to the windows directory. That is just evil :-) Instead, add the pg lib directory to the system PATH. 2) Note that pgsql ONLY works on NT based plattforms. Therefor, the comment on the beginning of the "as a service" section really applies to the whole document. As fr the location of it, I think we'll eventually want this in some form in the main documenation tree. That means SGML sources (look at existing docs). I'll let someone else comment on *where* it's good to put it. //Magnus > -----Original Message----- > From: V i s h a l Kashyap @ [Sai Hertz And Control Systems] > [mailto:sank89@sancharnet.in] > Sent: Wednesday, May 12, 2004 12:40 PM > Cc: pgsql-hackers-win32@postgresql.org > Subject: Re: [pgsql-hackers-win32] Novice Guide to Windows > Compile How to > > Hi all , > > > Find the PDF version at > > http://vishalkashyap.speedpost.net/1_beta.zip > > Suggestions / Comments / Ideas Most welcome > > -- > Best Regards, > Vishal Kashyap > Director / Lead Developer, > Sai Hertz And Control Systems Pvt Ltd, > http://saihertz.rediffblogs.com > Jabber IM: vishalkashyap@jabber.org > ICQ : 264360076 > Yahoo IM: mailforvishal@yahoo.com > ----------------------------------------------- > You yourself, as much as anybody in the entire universe, > deserve your love and affection. > - Buddha > --------------- > pgsql=# select marital_status from vishals_life; > > marital_status > ------------------ > Single not looking > > 1 Row(s) affected > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > >
Magnus Hagander wrote: >Hi! > >Good to see something along this line. Couple of comments: > >1) I would not suggest copying the LIB directory to the windows >directory. That is just evil :-) Instead, add the pg lib directory to >the system PATH. > > I agree that putting stuff in the Windows directory is evil. Having to use 2 path elements is a bit ugly too, though. My solution has been to move libpq.dll to the bin directory, which makes it work just fine for me without any PATH adjustment. It should actually load binaries slightly faster, too, since the binary location is the very first place Windows looks for DLLs, as I understand it. I'm not sure what else is loaded automatically at runtime (i.e. not with dlopen/LoadLibrary). Nothing obvious that I can see. cheers andrew
Andrew Dunstan wrote: > Magnus Hagander wrote: > >> Hi! >> >> Good to see something along this line. Couple of comments: >> >> 1) I would not suggest copying the LIB directory to the windows >> directory. That is just evil :-) Instead, add the pg lib directory to >> the system PATH. >> >> > > I agree that putting stuff in the Windows directory is evil. > > Having to use 2 path elements is a bit ugly too, though. My solution > has been to move libpq.dll to the bin directory, which makes it work > just fine for me without any PATH adjustment. It should actually load > binaries slightly faster, too, since the binary location is the very > first place Windows looks for DLLs, as I understand it. > > I'm not sure what else is loaded automatically at runtime (i.e. not > with dlopen/LoadLibrary). Nothing obvious that I can see. When working with the win32 builds and shipping them to friends, I wound up locating all of the DLLs (even from contrib) into the location of the postmaster executable. *I can hear the groans about this now* But, this allowed even the contrib modules (the ones that I could get to build) to work without any problems. I had learned about moving DLLs to their host directories when different versions of DLLs would be overwritten by install programs with win95. I don't know what the packaging issues are, but this seems to be a workable way to get around the need to alter the path and allow different versions of postmaster or psql to coexist on the same machine.
Re: Novice Guide to Windows Compile How to
От
"V i s h a l Kashyap @ [Sai Hertz And Control Systems]"
Дата:
Hi , > Thank you for the PDF file though it does work for me. I am glad that my work was of some help > There should be no need to copy all files under lib into system > directory. This may cause some problem when upgrading pgsql. One can > simply set the PATH to it as for the bin directory. > This has been corrected in latest doc at http://vishalkashyap.speedpost.net/ Looking forward for more inputs from others -- Best Regards, Vishal Kashyap Director / Lead Developer, Sai Hertz And Control Systems Pvt Ltd, http://saihertz.rediffblogs.com Jabber IM: vishalkashyap@jabber.org ICQ : 264360076 Yahoo IM: mailforvishal@yahoo.com ----------------------------------------------- You yourself, as much as anybody in the entire universe, deserve your love and affection. - Buddha --------------- pgsql=# select marital_status from vishals_life; marital_status ------------------ Single not looking 1 Row(s) affected
> >1) I would not suggest copying the LIB directory to the windows > >directory. That is just evil :-) Instead, add the pg lib > directory to > >the system PATH. > > > > > > I agree that putting stuff in the Windows directory is evil. > > Having to use 2 path elements is a bit ugly too, though. My > solution has been to move libpq.dll to the bin directory, > which makes it work just fine for me without any PATH > adjustment. It should actually load binaries slightly faster, > too, since the binary location is the very first place > Windows looks for DLLs, as I understand it. That depends on your Windows version. In XP with Service Pack 1 and later, and in Server 2003, it searches: 1) System locations 2) Current directory 3) User defined PATHs Before, it was: 1) Current directory 2) System locations 3) User defined PATHs These newer versions also added SetDllDirectory() - maybe this one will help us in some ways? //Magnus
Magnus Hagander said: >> >1) I would not suggest copying the LIB directory to the windows >> >directory. That is just evil :-) Instead, add the pg lib >> directory to >> >the system PATH. >> > >> > >> >> I agree that putting stuff in the Windows directory is evil. >> >> Having to use 2 path elements is a bit ugly too, though. My >> solution has been to move libpq.dll to the bin directory, >> which makes it work just fine for me without any PATH >> adjustment. It should actually load binaries slightly faster, >> too, since the binary location is the very first place >> Windows looks for DLLs, as I understand it. > > That depends on your Windows version. > In XP with Service Pack 1 and later, and in Server 2003, it searches: > 1) System locations > 2) Current directory > 3) User defined PATHs > > Before, it was: > 1) Current directory > 2) System locations > 3) User defined PATHs > > > These newer versions also added SetDllDirectory() - maybe this one will > help us in some ways? > Hmm. My understanding is that there's a 0th element to these lists: 0) Directory from which the .exe was loaded. Experimentation on W2K has shown this to be true - i.e. I have the DLL in the same dir as the exe, but it is not in my path, nor my current dir, nor my System locs, and it works (e.g. in <install-root> I say "bin\initdb -D data" and it finds the DLL just fine. http://support.microsoft.com/default.aspx?scid=kb;en-us;815065 says: Windows then searches for the DLLs in the following sequence: . The directory where the executable program for the current process is located. . The current directory. . The Windows system directory. (The GetSystemDirectory function gets the path of the Windows system directory.) . The Windows directory. (The GetWindowsDirectory function gets the path of the Windows directory.) . The directories that are listed in the PATH environment variable. cheers andrew
> >> Having to use 2 path elements is a bit ugly too, though. > My solution > >> has been to move libpq.dll to the bin directory, which > makes it work > >> just fine for me without any PATH adjustment. It should > actually load > >> binaries slightly faster, too, since the binary location > is the very > >> first place Windows looks for DLLs, as I understand it. > > > > That depends on your Windows version. > > In XP with Service Pack 1 and later, and in Server 2003, it > searches: > > 1) System locations > > 2) Current directory > > 3) User defined PATHs > > > > Before, it was: > > 1) Current directory > > 2) System locations > > 3) User defined PATHs > > > > > > These newer versions also added SetDllDirectory() - maybe this one > > will help us in some ways? > > > > Hmm. > > My understanding is that there's a 0th element to these lists: > > 0) Directory from which the .exe was loaded. > > Experimentation on W2K has shown this to be true - i.e. I > have the DLL in the same dir as the exe, but it is not in my > path, nor my current dir, nor my System locs, and it works > (e.g. in <install-root> I say "bin\initdb -D data" and it > finds the DLL just fine. > > http://support.microsoft.com/default.aspx?scid=kb;en-us;815065 says: > > > Windows then searches for the DLLs in the following sequence: > . The directory where the executable program for the current > process is located. > . The current directory. > . The Windows system directory. (The GetSystemDirectory > function gets the path of the Windows system directory.) . > The Windows directory. (The GetWindowsDirectory function gets > the path of the Windows directory.) . The directories that > are listed in the PATH environment variable. From what I can tell, this article is not valid for XP SP1+ and Server 2003 (if you look at the article, you'll see that it specifically excludes Windows Server 2003). Current Directory is moved way down on the list. But it could be that "application directory" is treated different than "current directory". Look at the text in this article: See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/ html/secure06122003.asp under the header "DLL Search Order Has Changed". It says it loads from the system directories *first*. Now, if there is no DLL in the system directories, then it will pick it up from the app dir. But if there is a different version in the system dirs, it will use that one (and break). But then it really shouldn't affect this. It's still loaded before what's in the PATH. What it says is we should stay away from stuffing things in the windows/system directories. That will create problems in the future. //Magnus
Magnus Hagander wrote: >> >>http://support.microsoft.com/default.aspx?scid=kb;en-us;815065 says: >> >> >>Windows then searches for the DLLs in the following sequence: >>. The directory where the executable program for the current >>process is located. >>. The current directory. >>. The Windows system directory. (The GetSystemDirectory >>function gets the path of the Windows system directory.) . >>The Windows directory. (The GetWindowsDirectory function gets >>the path of the Windows directory.) . The directories that >>are listed in the PATH environment variable. >> >> > >From what I can tell, this article is not valid for XP SP1+ and Server >2003 (if you look at the article, you'll see that it specifically >excludes Windows Server 2003). Current Directory is moved way down on >the list. But it could be that "application directory" is treated >different than "current directory". Look at the text in this article: >See >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/ >html/secure06122003.asp > >under the header "DLL Search Order Has Changed". >It says it loads from the system directories *first*. Now, if there is >no DLL in the system directories, then it will pick it up from the app >dir. But if there is a different version in the system dirs, it will use >that one (and break). > > >But then it really shouldn't affect this. It's still loaded before >what's in the PATH. What it says is we should stay away from stuffing >things in the windows/system directories. That will create problems in >the future. > > > As usual their documentation just sucks. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/load_time_dynamic_linking.asp appears to suggest, although it is not explicit, that the changed behaviour affects only the location of current directory, not application directory, in the search order. Can anyone clarify what the *actual* behaviour is? (Their supposed justification for the change seems to me to be a bit dubious too, at least if it applies to the app directory: "The reason this change was made was to mitigate some kinds of trojaning attacks. An attacker may be able to sneak a bad DLL into your application directory or a directory that has files associated with your application. The DLL search order change removes this attack vector." If they can sneak in a DLL why can't they also sneak in a .exe? OTOH lowering current directory in the search order makes more sense.) cheers andrew