Thread: Small suggestion on build script
I would like to suggest changing the symlinks to copy commands: cp ./src/backend/port/tas/dummy.s ./src/backend/port/tas.s cp ./src/backend/port/dynloader/win32.c ./src/backend/port/dynloader.c cp ./src/backend/port/sysv_sema.c ./src/backend/port/pg_sema.c cp ./src/backend/port/sysv_shmem.c ./src/backend/port/pg_shmem.c cp ./src/backend/port/dynloader/win32.h ./src/include/dynloader.h cp ./src/include/port/win32.h ./src/include/pg_config_os.h cp ./src/makefiles/Makefile.win32 ./src/Makefile.port The reason is that under Mingw, I get random failures with the symlinks (typically all will work but one or two, but there is no telling which will succeed and which will fail). The space consumed by a copy instead of a symblink is very small. Here is a summary of the changes I need to make to do a build of the latest drop: 1. Go to the Postgresql site and download the latest development snapshot called postgresql-snapshot.tar.bz2 and decompress and untar it. 2. Install the complete MINGW tool chain from here: http://www.mingw.org/download.shtml I went from the bottom up. 3. Using mingw, change directory to the /postgresql-snapshot directory and run $ ./configure --without-readline 3. b) even at that, the pg_config.h file will be messed up. You have to manually edit it so that every reference to readline is #undef removed. 3. c) edit pg_config.h and make these changes: /* Define to 1 if you have the <termios.h> header file. */ #undef HAVE_TERMIOS_H #define WIN32 1 3. d) a sample of a working pg_config.h file is attached. 4. You will probably have to repair either float.c or ieeefp.h. The file float.c needs the following modification after the comments, because something goes haywire in ieeefp.h: #include "postgres.h" #include <ctype.h> #include <errno.h> #include <float.h> #include <math.h> #include <limits.h> /* for finite() on Solaris */ #ifdef HAVE_IEEEFP_H #ifndef __MINGW32__ /* <<<== ICKY_WIN32_KLUDGE --> DRC {BROKEN ieeefp.h file} */ #include <ieeefp.h> #endif /* end ICKY_WIN32_KLUDGE */ #endif 5. The build will stop where the symlinks fail (random). For the files that are missing, perform the copy commands shown above. 6. Run make, correcting any errors with symlinks until all are resolved 7. Make install
On Tue, 6 Apr 2004, Dann Corbit wrote: > I would like to suggest changing the symlinks to copy commands: > > cp ./src/backend/port/tas/dummy.s ./src/backend/port/tas.s > cp ./src/backend/port/dynloader/win32.c ./src/backend/port/dynloader.c > cp ./src/backend/port/sysv_sema.c ./src/backend/port/pg_sema.c > cp ./src/backend/port/sysv_shmem.c ./src/backend/port/pg_shmem.c > cp ./src/backend/port/dynloader/win32.h ./src/include/dynloader.h > cp ./src/include/port/win32.h ./src/include/pg_config_os.h > cp ./src/makefiles/Makefile.win32 ./src/Makefile.port > > The reason is that under Mingw, I get random failures with the symlinks > (typically all will work but one or two, but there is no telling which > will succeed and which will fail). Would a hard link work, vs a symlink? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Hi Dann, whilst I have, on rare occasions, observed the symlink failure under MingW, I've never come across the other issues you've mentioned (I build from cvs, instead of snapshots, but I can't imagine that causes these problems). Is it possible your MingW install is a broken? Which version are you using? Is it possible the wrong libs/include files are being referenced? Are you sure parts of cygwin are not in your path? ... Cheers, Claudio -----Original Message----- From: Dann Corbit To: pgsql-hackers@postgresql.org Sent: 4/7/04 7:14 AM Subject: [HACKERS] Small suggestion on build script I would like to suggest changing the symlinks to copy commands: cp ./src/backend/port/tas/dummy.s ./src/backend/port/tas.s cp ./src/backend/port/dynloader/win32.c ./src/backend/port/dynloader.c cp ./src/backend/port/sysv_sema.c ./src/backend/port/pg_sema.c cp ./src/backend/port/sysv_shmem.c ./src/backend/port/pg_shmem.c cp ./src/backend/port/dynloader/win32.h ./src/include/dynloader.h cp ./src/include/port/win32.h ./src/include/pg_config_os.h cp ./src/makefiles/Makefile.win32 ./src/Makefile.port The reason is that under Mingw, I get random failures with the symlinks (typically all will work but one or two, but there is no telling which will succeed and which will fail). The space consumed by a copy instead of a symblink is very small. Here is a summary of the changes I need to make to do a build of the latest drop: 1. Go to the Postgresql site and download the latest development snapshot called postgresql-snapshot.tar.bz2 and decompress and untar it. 2. Install the complete MINGW tool chain from here: http://www.mingw.org/download.shtml I went from the bottom up. 3. Using mingw, change directory to the /postgresql-snapshot directory and run $ ./configure --without-readline 3. b) even at that, the pg_config.h file will be messed up. You have to manually edit it so that every reference to readline is #undef removed. 3. c) edit pg_config.h and make these changes: /* Define to 1 if you have the <termios.h> header file. */ #undef HAVE_TERMIOS_H #define WIN32 1 3. d) a sample of a working pg_config.h file is attached. 4. You will probably have to repair either float.c or ieeefp.h. The file float.c needs the following modification after the comments, because something goes haywire in ieeefp.h: #include "postgres.h" #include <ctype.h> #include <errno.h> #include <float.h> #include <math.h> #include <limits.h> /* for finite() on Solaris */ #ifdef HAVE_IEEEFP_H #ifndef __MINGW32__ /* <<<== ICKY_WIN32_KLUDGE --> DRC {BROKEN ieeefp.h file} */ #include <ieeefp.h> #endif /* end ICKY_WIN32_KLUDGE */ #endif 5. The build will stop where the symlinks fail (random). For the files that are missing, perform the copy commands shown above. 6. Run make, correcting any errors with symlinks until all are resolved 7. Make install ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster --- 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>
> -----Original Message----- > From: Claudio Natoli [mailto:claudio.natoli@memetrics.com] > Sent: Tuesday, April 06, 2004 5:42 PM > To: Dann Corbit; 'pgsql-hackers@postgresql.org ' > Subject: RE: [HACKERS] Small suggestion on build script > > > > Hi Dann, > > whilst I have, on rare occasions, observed the symlink > failure under MingW, I've never come across the other issues > you've mentioned (I build from cvs, instead of snapshots, but > I can't imagine that causes these problems). > > Is it possible your MingW install is a broken? I imagine it is possbile > Which version > are you using? Msys version is 1.0. dcorbit@DANNFAST /u/postgresql-snapshot $ gcc --version gcc.exe (GCC) 3.3.3 (mingw special) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > Is it possible the wrong libs/include files > are being referenced? Don't know. > Are you sure parts of cygwin are not in > your path? ... Doubtful. I do have cygwin on my system, but the libraries and headers are only visible when I run from the cygwin bash shell. > Cheers, > Claudio > > > > -----Original Message----- > From: Dann Corbit > To: pgsql-hackers@postgresql.org > Sent: 4/7/04 7:14 AM > Subject: [HACKERS] Small suggestion on build script > > I would like to suggest changing the symlinks to copy commands: > > cp ./src/backend/port/tas/dummy.s ./src/backend/port/tas.s > cp ./src/backend/port/dynloader/win32.c > ./src/backend/port/dynloader.c cp > ./src/backend/port/sysv_sema.c ./src/backend/port/pg_sema.c > cp ./src/backend/port/sysv_shmem.c > ./src/backend/port/pg_shmem.c cp > ./src/backend/port/dynloader/win32.h > ./src/include/dynloader.h cp ./src/include/port/win32.h > ./src/include/pg_config_os.h cp > ./src/makefiles/Makefile.win32 ./src/Makefile.port > > The reason is that under Mingw, I get random failures with > the symlinks (typically all will work but one or two, but > there is no telling which will succeed and which will fail). > > The space consumed by a copy instead of a symblink is very small. > > Here is a summary of the changes I need to make to do a build > of the latest drop: > > 1. Go to the Postgresql site and download the latest > development snapshot called postgresql-snapshot.tar.bz2 and > decompress and untar it. > > 2. Install the complete MINGW tool chain from here: http://www.mingw.org/download.shtml I went from the bottom up. 3. Using mingw, change directory to the /postgresql-snapshot directory and run $ ./configure --without-readline 3. b) even at that, the pg_config.h file will be messed up. You have to manually edit it so that every reference to readline is #undef removed. 3. c) edit pg_config.h and make these changes: /* Define to 1 if you have the <termios.h> header file. */ #undef HAVE_TERMIOS_H #define WIN32 1 3. d) a sample of a working pg_config.h file is attached. 4. You will probably have to repair either float.c or ieeefp.h. The file float.c needs the following modification after the comments, because something goes haywire in ieeefp.h: #include "postgres.h" #include <ctype.h> #include <errno.h> #include <float.h> #include <math.h> #include <limits.h> /* for finite() on Solaris */ #ifdef HAVE_IEEEFP_H #ifndef __MINGW32__ /* <<<== ICKY_WIN32_KLUDGE --> DRC {BROKEN ieeefp.h file} */ #include <ieeefp.h> #endif /* end ICKY_WIN32_KLUDGE */ #endif 5. The build will stop where the symlinks fail (random). For the files that are missing, perform the copy commands shown above. 6. Run make, correcting any errors with symlinks until all are resolved 7. Make install ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster --- 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.co m/em ailpolicy.html</a>
> -----Original Message----- > From: Dann Corbit > Sent: Tuesday, April 06, 2004 5:47 PM > To: Claudio Natoli; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Small suggestion on build script > > > > -----Original Message----- > > From: Claudio Natoli [mailto:claudio.natoli@memetrics.com] > > Sent: Tuesday, April 06, 2004 5:42 PM > > To: Dann Corbit; 'pgsql-hackers@postgresql.org ' > > Subject: RE: [HACKERS] Small suggestion on build script > > > > > > > > Hi Dann, > > > > whilst I have, on rare occasions, observed the symlink > > failure under MingW, I've never come across the other issues > > you've mentioned (I build from cvs, instead of snapshots, but > > I can't imagine that causes these problems). > > > > Is it possible your MingW install is a broken? > > I imagine it is possbile > > > Which version > > are you using? > > Msys version is 1.0. > > dcorbit@DANNFAST /u/postgresql-snapshot > $ gcc --version > gcc.exe (GCC) 3.3.3 (mingw special) > Copyright (C) 2003 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO warranty; not even for MERCHANTABILITY or > FITNESS FOR A PARTICULAR PURPOSE. > > > > Is it possible the wrong libs/include files > > are being referenced? > > Don't know. > > > Are you sure parts of cygwin are not in > > your path? ... > > Doubtful. I do have cygwin on my system, but the libraries > and headers are only visible when I run from the cygwin bash shell. Something important: Since Mingw uses system header files and libraries, I should mention that the compiler is Microsoft C++ .NET 2003
Hi Dann, > > Which version > > are you using? > > Msys version is 1.0. Ok, probably the same I'm using (MSYS-1.0.10 and MSYS-1.0.9) > dcorbit@DANNFAST /u/postgresql-snapshot > $ gcc --version > gcc.exe (GCC) 3.3.3 (mingw special) I'm using MinGW-3.1.0-1, which has: gcc.exe (GCC) 3.2.3 (mingw special 20030504-1) 3.3.3 is still a candidate release for MinGW, right? Might want to try the release version, and FWIW I'll try 3.3.3 myself as soon as I get the chance. 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>
"Dann Corbit" <DCorbit@connx.com> writes:
> I would like to suggest changing the symlinks to copy commands:
That would cause make to fail to handle update dependencies on the
linked files.
> The reason is that under Mingw, I get random failures with the symlinks
This is the worst sort of Microsoft imperialism that I hoped we'd not be
succumbing to by having a Windows port :-(. "If it doesn't work on
Windows then the rest of you have to give up functionality." How about
filing a bug report against the Mingw breakage, instead of expecting us
to try to work around it?
regards, tom lane
Dann Corbit wrote: > I would like to suggest changing the symlinks to copy commands: > The reason is that under Mingw, I get random failures with the > symlinks (typically all will work but one or two, but there is no > telling which will succeed and which will fail). configure will automatically make copies if it determines that symlinks don't work, but that doesn't help with random failures. Fix your operating system.
> whilst I have, on rare occasions, observed the symlink > failure under MingW, I've never come across the other issues > you've mentioned (I build from cvs, instead of snapshots, but > I can't imagine that causes these problems). I'm running off snapshots (my bison install is badly broken), and I have no such problems either (except the occassional symlink problem - but that deos not happen often at all). (Though the snapshot I'm working off right now is march 25th, but I don't think anything has happened since then that could cause this) I'm on the release versions of Mingw and MSys (Mingw 3.1.0, Runtime 3.2 and MSys 1.0.10). I also have cygwin and the Visual C++ compiler on the system, but they are not referenced from mingw of course. I agree that this sounds like something might be off with the mingw installation. //Magnus
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Tuesday, April 06, 2004 10:55 PM > To: Dann Corbit > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Small suggestion on build script > > > "Dann Corbit" <DCorbit@connx.com> writes: > > I would like to suggest changing the symlinks to copy commands: > > That would cause make to fail to handle update dependencies > on the linked files. An unconditional copy will cause no breakage. It's not a big deal, I can always edit the files by hand. Or I can write a sed script that fixes it automatically. > > The reason is that under Mingw, I get random failures with the > > symlinks > > This is the worst sort of Microsoft imperialism that I hoped > we'd not be succumbing to by having a Windows port :-(. "If > it doesn't work on Windows then the rest of you have to give > up functionality." How about filing a bug report against the > Mingw breakage, instead of expecting us to try to work around it? The problem has nothing to do with Microsoft imperialism. Microsoft has no connection to Mingw, it is an independent tool set. Filing the bug report is a good idea.
> -----Original Message----- > From: Dann Corbit > Sent: Wednesday, April 07, 2004 10:34 AM > To: Tom Lane > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Small suggestion on build script > > > > -----Original Message----- > > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > Sent: Tuesday, April 06, 2004 10:55 PM > > To: Dann Corbit > > Cc: pgsql-hackers@postgresql.org > > Subject: Re: [HACKERS] Small suggestion on build script > > > > > > "Dann Corbit" <DCorbit@connx.com> writes: > > > I would like to suggest changing the symlinks to copy commands: > > > > That would cause make to fail to handle update dependencies > > on the linked files. > > An unconditional copy will cause no breakage. It's not a big > deal, I can always edit the files by hand. Or I can write a > sed script that fixes it automatically. > > > > The reason is that under Mingw, I get random failures with the > > > symlinks > > > > This is the worst sort of Microsoft imperialism that I hoped > > we'd not be succumbing to by having a Windows port :-(. "If > > it doesn't work on Windows then the rest of you have to give > > up functionality." How about filing a bug report against the > > Mingw breakage, instead of expecting us to try to work around it? > > The problem has nothing to do with Microsoft imperialism. > Microsoft has no connection to Mingw, it is an independent tool set. > > Filing the bug report is a good idea. The response from the Mingw team: >Comment By: Earnie Boyd (earnie) Date: 2004-04-08 07:33 Message: Logged In: YES user_id=15438 Symbolic links to files and directories do not work on Win32 in general. Support for symlink operation is limited to the source directory or file existing and being able to copy the source to the destination. You will need to modify the package to do the appropriate thing for the environment. Earnie
"Dann Corbit" <DCorbit@connx.com> writes:
> The response from the Mingw team:
>> Symbolic links to files and directories do not work on Win32
>> in general. Support for symlink operation is limited to the source
>> directory or file existing and being able to copy the source to the
>> destination.
The source does exist, and they should be able to copy it to the
destination, and they do manage to do so much of the time. I think
you failed to convey the critical point, which is that they randomly
fail to do what they claim to be able to do.
regards, tom lane
Tom Lane said: > "Dann Corbit" <DCorbit@connx.com> writes: >> The response from the Mingw team: > >>> Symbolic links to files and directories do not work on Win32 >>> in general. Support for symlink operation is limited to the source >>> directory or file existing and being able to copy the source to the >>> destination. > > The source does exist, and they should be able to copy it to the > destination, and they do manage to do so much of the time. I think you > failed to convey the critical point, which is that they randomly fail > to do what they claim to be able to do. > > I had a couple of thoughts about ways of dealing with this problem in an acceptable way: 1. make the symlinking more robust by doing it in a loop until it succeeeds - surely we can test for that rather than just assuming it has succeeded. 2. or instead of symlinking or making a lasting copy, make the dependency back to the real file location and the corresponding compile action would be copy/compile/delete copy. cheers andrew
Dann Corbit wrote: > The response from the Mingw team: > >Comment By: Earnie Boyd (earnie) > > Date: 2004-04-08 07:33 > > Message: > Logged In: YES > user_id=15438 > > Symbolic links to files and directories do not work on Win32 > in general. Support for symlink operation is limited to the source > directory or file existing and being able to copy the source to the > destination. > > You will need to modify the package to do the appropriate > thing for the environment. This is not something we should have to solve locally. Autoconf is supposed to do the right thing on platforms that don't support symlinks. I know Earnie Boyd has been doing a lot of work to get autoconfiscated packages to build smoothly on MinGW. Maybe you could try a later Autoconf version or convince the MinGW people to improve Autoconf? Then again, I still hear that the failures occur "randomly", which deserves a different kind of investigation.