Thread: timezone changes break windows and cygwin
The latest timezone lib changes seem to have broken Windows and Cygwin builds comprehensively. I assume that this checkin caused the problem: http://archives.postgresql.org/pgsql-committers/2005-07/msg00155.php : Restructure zic #define fprintf checks to use a NO_PGPORT macro instead. Extracts from buildfarm logs: Windows: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -g zic.o ialloc.o scheck.o localtime-zic.o -o zic.exe zic.o(.text+0xe99): In function `dolink': C:/msys/1.0/home/pgbf/pgbuildfarm/HEAD/pgsql.8032/src/timezone/zic.c:634: undefined reference to `pgsymlink' zic.o(.text+0xed5):C:/msys/1.0/home/pgbf/pgbuildfarm/HEAD/pgsql.8032/src/timezone/zic.c:613: undefined reference to `pgunlink' zic.o(.text+0x36ed): In function `writezone': C:/msys/1.0/home/pgbf/pgbuildfarm/HEAD/pgsql.8032/src/timezone/zic.c:1580: undefined reference to `pgunlink' localtime-zic.o(.text+0x14c): In function `tzload': C:/msys/1.0/home/pgbf/pgbuildfarm/HEAD/pgsql.8032/src/timezone/localtime-zic.c:161: undefined reference to `win32_open' Cygwin: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g zic.o ialloc.o scheck.o localtime-zic.o-o zic.exe zic.o(.text+0x86c): In function `dolink': /home/jim/pgbuildfarm/HEAD/pgsql.7860/src/timezone/zic.c:613: undefined reference to `_pgunlink' zic.o(.text+0x261a): In function `writezone': /home/jim/pgbuildfarm/HEAD/pgsql.7860/src/timezone/zic.c:1562: undefined reference to `_pgunlink' collect2: ld returned 1 exit status cheers andrew
Andrew Dunstan wrote: > > The latest timezone lib changes seem to have broken Windows and Cygwin > builds comprehensively. I assume that this checkin caused the problem: > > http://archives.postgresql.org/pgsql-committers/2005-07/msg00155.php : > > Restructure zic #define fprintf checks to use a NO_PGPORT macro instead. Actually, that patch was to fix my unix build. The big change was that zic no longer uses pgport routines, and that was done by someone else so zic would be run on the target matchine for cross-platform builds. I have applied the attached patch which should fix the problems you saw. It basically extends NO_PGPORT, which I expected might be required when I added it. --------------------------------------------------------------------------- > > > Extracts from buildfarm logs: > > Windows: > > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -g zic.o ialloc.o scheck.o localtime-zic.o -o zic.exe > zic.o(.text+0xe99): In function `dolink': > C:/msys/1.0/home/pgbf/pgbuildfarm/HEAD/pgsql.8032/src/timezone/zic.c:634: undefined reference to `pgsymlink' > zic.o(.text+0xed5):C:/msys/1.0/home/pgbf/pgbuildfarm/HEAD/pgsql.8032/src/timezone/zic.c:613: undefined reference to `pgunlink' > zic.o(.text+0x36ed): In function `writezone': > C:/msys/1.0/home/pgbf/pgbuildfarm/HEAD/pgsql.8032/src/timezone/zic.c:1580: undefined reference to `pgunlink' > localtime-zic.o(.text+0x14c): In function `tzload': > C:/msys/1.0/home/pgbf/pgbuildfarm/HEAD/pgsql.8032/src/timezone/localtime-zic.c:161: undefined reference to `win32_open' > > > Cygwin: > > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g zic.o ialloc.o scheck.o localtime-zic.o-o zic.exe > zic.o(.text+0x86c): In function `dolink': > /home/jim/pgbuildfarm/HEAD/pgsql.7860/src/timezone/zic.c:613: undefined reference to `_pgunlink' > zic.o(.text+0x261a): In function `writezone': > /home/jim/pgbuildfarm/HEAD/pgsql.7860/src/timezone/zic.c:1562: undefined reference to `_pgunlink' > collect2: ld returned 1 exit status > > > cheers > > andrew > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- 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 Index: src/include/port.h =================================================================== RCS file: /cvsroot/pgsql/src/include/port.h,v retrieving revision 1.77 diff -c -c -r1.77 port.h *** src/include/port.h 4 Jul 2005 19:54:51 -0000 1.77 --- src/include/port.h 5 Jul 2005 17:08:17 -0000 *************** *** 178,184 **** #define TZNAME_GLOBAL _tzname #endif ! #if defined(WIN32) || defined(__CYGWIN__) /* * Win32 doesn't have reliable rename/unlink during concurrent access, * and we need special code to do symlinks. --- 178,184 ---- #define TZNAME_GLOBAL _tzname #endif ! #if (defined(WIN32) || defined(__CYGWIN__)) && !defined(NO_PGPORT) /* * Win32 doesn't have reliable rename/unlink during concurrent access, * and we need special code to do symlinks. *************** *** 204,214 **** #define symlink(oldpath, newpath) pgsymlink(oldpath, newpath) #endif ! #endif /* defined(WIN32) || defined(__CYGWIN__) */ extern bool rmtree(char *path, bool rmtopdir); ! #if defined(WIN32) && !defined(__CYGWIN__) /* open() replacement to allow delete of held files and passing * of special options. */ --- 204,214 ---- #define symlink(oldpath, newpath) pgsymlink(oldpath, newpath) #endif ! #endif /* defined(WIN32) || defined(__CYGWIN__) && !defined(NO_PGPORT) */ extern bool rmtree(char *path, bool rmtopdir); ! #if defined(WIN32) && !defined(__CYGWIN__) && !defined(NO_PGPORT) /* open() replacement to allow delete of held files and passing * of special options. */
Cygwin seems fixed, but now on my Windows box I get this: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -I../../src/include -I./src/include/port/win32 -DEXEC_BACKEND "-I../../src/include/port/win32" -DBUILDING_DLL -I. -DNO_PGPORT -c -o zic.o zic.c zic.c: In function `dolink': zic.c:634: warning: implicit declaration of function `symlink' gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -I../../src/include -I./src/include/port/win32 -DEXEC_BACKEND "-I../../src/include/port/win32" -DBUILDING_DLL -I. -DNO_PGPORT -c -o ialloc.o ialloc.c gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -I../../src/include -I./src/include/port/win32 -DEXEC_BACKEND "-I../../src/include/port/win32" -DBUILDING_DLL -I. -DNO_PGPORT -c -o scheck.o scheck.c ln -s localtime.c localtime-zic.c gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -I../../src/include -I./src/include/port/win32 -DEXEC_BACKEND "-I../../src/include/port/win32" -DBUILDING_DLL -I. -DNO_PGPORT -c -o localtime-zic.o localtime-zic.c gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing zic.o ialloc.o scheck.o localtime-zic.o -o zic.exe zic.o(.text+0xe99):zic.c: undefined reference to `symlink' cheers andrew Bruce Momjian wrote: >Andrew Dunstan wrote: > > >>The latest timezone lib changes seem to have broken Windows and Cygwin >>builds comprehensively. I assume that this checkin caused the problem: >> >>http://archives.postgresql.org/pgsql-committers/2005-07/msg00155.php : >> >>Restructure zic #define fprintf checks to use a NO_PGPORT macro instead. >> >> > >Actually, that patch was to fix my unix build. The big change was that >zic no longer uses pgport routines, and that was done by someone else so >zic would be run on the target matchine for cross-platform builds. > >I have applied the attached patch which should fix the problems you saw. >It basically extends NO_PGPORT, which I expected might be required when >I added it. > > > >
OK, now we have a problem. :-( While using native versions of libc functions rather than our pgport enhanced versions is OK for zic, the use of symlink is a problem because there is no native Win32 version. Looking at zic.c::dolink, it calls symlink() if link() fails. I suppose we could bring in a file from pgport like we bring files in now from there for libpq. Is there a reason we can't still use pgport? --------------------------------------------------------------------------- Andrew Dunstan wrote: > Cygwin seems fixed, but now on my Windows box I get this: > > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing > -I../../src/include -I./src/include/port/win32 -DEXEC_BACKEND > "-I../../src/include/port/win32" -DBUILDING_DLL -I. -DNO_PGPORT -c -o > zic.o zic.c > zic.c: In function `dolink': > zic.c:634: warning: implicit declaration of function `symlink' > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing > -I../../src/include -I./src/include/port/win32 -DEXEC_BACKEND > "-I../../src/include/port/win32" -DBUILDING_DLL -I. -DNO_PGPORT -c -o > ialloc.o ialloc.c > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing > -I../../src/include -I./src/include/port/win32 -DEXEC_BACKEND > "-I../../src/include/port/win32" -DBUILDING_DLL -I. -DNO_PGPORT -c -o > scheck.o scheck.c > ln -s localtime.c localtime-zic.c > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing > -I../../src/include -I./src/include/port/win32 -DEXEC_BACKEND > "-I../../src/include/port/win32" -DBUILDING_DLL -I. -DNO_PGPORT -c -o > localtime-zic.o localtime-zic.c > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing > zic.o ialloc.o scheck.o localtime-zic.o -o zic.exe > zic.o(.text+0xe99):zic.c: undefined reference to `symlink' > > cheers > > andrew > > Bruce Momjian wrote: > > >Andrew Dunstan wrote: > > > > > >>The latest timezone lib changes seem to have broken Windows and Cygwin > >>builds comprehensively. I assume that this checkin caused the problem: > >> > >>http://archives.postgresql.org/pgsql-committers/2005-07/msg00155.php : > >> > >>Restructure zic #define fprintf checks to use a NO_PGPORT macro instead. > >> > >> > > > >Actually, that patch was to fix my unix build. The big change was that > >zic no longer uses pgport routines, and that was done by someone else so > >zic would be run on the target matchine for cross-platform builds. > > > >I have applied the attached patch which should fix the problems you saw. > >It basically extends NO_PGPORT, which I expected might be required when > >I added it. > > > > > > > > > -- 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, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, now we have a problem. :-(
No kidding. I said to begin with that this plan to use target-specific
configuration knowledge to build a program executable by the host would
not work. I'm for reverting Peter's initial patch; maybe we can someday
find an answer, but this ain't it.
regards, tom lane
Tom Lane said: > Bruce Momjian <pgman@candle.pha.pa.us> writes: >> OK, now we have a problem. :-( > > No kidding. I said to begin with that this plan to use target-specific > configuration knowledge to build a program executable by the host would > not work. I'm for reverting Peter's initial patch; maybe we can > someday find an answer, but this ain't it. > +1. cheers andrew
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > OK, now we have a problem. :-( > > No kidding. I said to begin with that this plan to use target-specific > configuration knowledge to build a program executable by the host would > not work. I'm for reverting Peter's initial patch; maybe we can someday > find an answer, but this ain't it. Yea, I knew my original NO_PGPORT wasn't going to be the last, but now we are stuck. Add to this something Magnus mentioned that I did not see until just now. The backend links in timezone/SUBSYS.o, which doesn't use pgport, so you have pgport versions and native versions of some functions in the same backend binary. I am not sure that will always work. Add to that, are those object files fully compatible with the backend? -- 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, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Add to this something Magnus mentioned that I did not see until just
> now. The backend links in timezone/SUBSYS.o, which doesn't use pgport,
> so you have pgport versions and native versions of some functions in the
> same backend binary. I am not sure that will always work. Add to that,
> are those object files fully compatible with the backend?
The patch was never supposed to change timezone/SUBSYS.o! Only the zic
executable. If it's having any side effects on what goes into SUBSYS.o,
it's simply wrong.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Add to this something Magnus mentioned that I did not see until just > > now. The backend links in timezone/SUBSYS.o, which doesn't use pgport, > > so you have pgport versions and native versions of some functions in the > > same backend binary. I am not sure that will always work. Add to that, > > are those object files fully compatible with the backend? > > The patch was never supposed to change timezone/SUBSYS.o! Only the zic > executable. If it's having any side effects on what goes into SUBSYS.o, > it's simply wrong. Well, my NO_PGPORT is affecting timezone/SUBSYS.o because there is no way to compile zic without removing pgport library symbols from the object files. -- 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, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> The patch was never supposed to change timezone/SUBSYS.o! Only the zic
>> executable. If it's having any side effects on what goes into SUBSYS.o,
>> it's simply wrong.
> Well, my NO_PGPORT is affecting timezone/SUBSYS.o because there is no
> way to compile zic without removing pgport library symbols from the
> object files.
We might have to move zic into a separate directory so that it can be
compiled on its own with its own copies of the relevant .o files.
In the meantime though it's utterly clear that this entire series of
patches is a failed experiment. Please revert the lot.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> The patch was never supposed to change timezone/SUBSYS.o! Only the zic > >> executable. If it's having any side effects on what goes into SUBSYS.o, > >> it's simply wrong. > > > Well, my NO_PGPORT is affecting timezone/SUBSYS.o because there is no > > way to compile zic without removing pgport library symbols from the > > object files. > > We might have to move zic into a separate directory so that it can be > compiled on its own with its own copies of the relevant .o files. > > In the meantime though it's utterly clear that this entire series of > patches is a failed experiment. Please revert the lot. I can pull out NO_PGPORT, but what commit causes the original problem? Was it only one? (I wasn't watching.) -- 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, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> In the meantime though it's utterly clear that this entire series of
>> patches is a failed experiment. Please revert the lot.
> I can pull out NO_PGPORT, but what commit causes the original problem?
> Was it only one? (I wasn't watching.)
This one:
2005-07-03 14:54 petere
* configure, configure.in, doc/src/sgml/installation.sgml,src/Makefile.global.in, src/timezone/Makefile: Support
crosscompilationby compiling "zic" with a native compiler. This relieson the output of zic being platform
independent,but that iscurrently the case.
and all the subsequent changes touching src/timezone/
regards, tom lane
Tom Lane wrote: > > I can pull out NO_PGPORT, but what commit causes the original > > problem? Was it only one? (I wasn't watching.) > > This one: > > 2005-07-03 14:54 petere Attached is the patch, in case someone wants to revert it. (I'd do it myself but I suppose this would interfere with rolling back the subsequent patches.) I apologize for all the trouble. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Tom Lane wrote: > We might have to move zic into a separate directory so that it can be > compiled on its own with its own copies of the relevant .o files. Up next: rewriting zic in Perl :-) No seriously, when the dust has settled I think we should just put in a note into the makefile (or perhaps at the end of configure) to the effect "you are cross-compiling, you will have problems here and here" as I had previously proposed. Those who are just looking for a cross build of libpq should be content with that. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Tom Lane wrote: > > > I can pull out NO_PGPORT, but what commit causes the original > > > problem? Was it only one? (I wasn't watching.) > > > > This one: > > > > 2005-07-03 14:54 petere > > Attached is the patch, in case someone wants to revert it. (I'd do it > myself but I suppose this would interfere with rolling back the > subsequent patches.) > > I apologize for all the trouble. I backed it out using CVS because this patch didn't contain the SGML changes that also needed to be reverted, I think. -- 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, Pennsylvania19073
OK, I have backed out Peter's change, and the NO_PGPORT workarounds. --------------------------------------------------------------------------- Peter Eisentraut wrote: > Tom Lane wrote: > > We might have to move zic into a separate directory so that it can be > > compiled on its own with its own copies of the relevant .o files. > > Up next: rewriting zic in Perl :-) > > No seriously, when the dust has settled I think we should just put in a > note into the makefile (or perhaps at the end of configure) to the > effect "you are cross-compiling, you will have problems here and here" > as I had previously proposed. Those who are just looking for a cross > build of libpq should be content with that. > > -- > Peter Eisentraut > http://developer.postgresql.org/~petere/ > -- 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, Pennsylvania19073