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.portThe 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>
Import Notes
Resolved by subject fallback
-----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 scriptHi 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 scriptI 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.portThe 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>
Import Notes
Resolved by subject fallback
-----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 scriptHi 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
Import Notes
Resolved by subject fallback
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>
Import Notes
Resolved by subject fallback
"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
Import Notes
Resolved by subject fallback
-----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
symlinksThis 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.
Import Notes
Resolved by subject fallback
-----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
symlinksThis 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
Import Notes
Resolved by subject fallback
"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=15438Symbolic 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.