Thread: Cygwin - make check broken
It looks like when we changed regress/GNUmakefile to pull rules from Makefile.shlib, cygwin got broken in the process. The problem is that regess.dll ends up being a symlink back to itself, because we do a: $(NAME)$(DLSUFFIX): $(shlib) rm -f $(NAME)$(DLSUFFIX) $(LN_S) $(shlib) $(NAME)$(DLSUFFIX) And from Makefile.shlib (for cygwin) ifeq ($(PORTNAME), cygwin) shlib = $(NAME)$(DLSUFFIX) Thus regress.dll gets unhappy :-( I don't know enough about the rest of the way the cygwin port is put together, but it seems that the other platforms all have shlib=lib$(NAME)... -rocco
"Rocco Altier" <RoccoA@Routescape.com> writes:
> It looks like when we changed regress/GNUmakefile to pull rules from
> Makefile.shlib, cygwin got broken in the process.
> ...
> I don't know enough about the rest of the way the cygwin port is put
> together, but it seems that the other platforms all have
> shlib=lib$(NAME)...
Seems to me that defining shlib that way for Cygwin too would be a
reasonable answer, but I'm not sure if there will be any side-effects.
Can someone try it?
regards, tom lane
Rocco Altier schrieb: > It looks like when we changed regress/GNUmakefile to pull rules from > Makefile.shlib, cygwin got broken in the process. > > The problem is that regess.dll ends up being a symlink back to itself, > because we do a: > $(NAME)$(DLSUFFIX): $(shlib) > rm -f $(NAME)$(DLSUFFIX) > $(LN_S) $(shlib) $(NAME)$(DLSUFFIX) > > And from Makefile.shlib (for cygwin) > ifeq ($(PORTNAME), cygwin) > shlib = $(NAME)$(DLSUFFIX) > > Thus regress.dll gets unhappy :-( > > I don't know enough about the rest of the way the cygwin port is put > together, but it seems that the other platforms all have > shlib=lib$(NAME)... For cygwin the normal rule is cyg$(NAME)$(DLSUFFIX), but the postgresql maintainers refused to changed the prefix for 8.0 -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/
test
__________________________________
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
Tom Lane wrote: >"Rocco Altier" <RoccoA@Routescape.com> writes: > > >>It looks like when we changed regress/GNUmakefile to pull rules from >>Makefile.shlib, cygwin got broken in the process. >>... >>I don't know enough about the rest of the way the cygwin port is put >>together, but it seems that the other platforms all have >>shlib=lib$(NAME)... >> >> > >Seems to me that defining shlib that way for Cygwin too would be a >reasonable answer, but I'm not sure if there will be any side-effects. >Can someone try it? > > > > The attached patch worked for me. The second part should not be applied - I simply include it to illustrate the hack (taken from a recent clue on the Cygwin mailing list) that I found necessary to get around brokenness on the latest release of Cygwin. The good news is that they do seem to be trying to find out what broke and fix it. cheers andrew
er that would be this patch.
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
>> "Rocco Altier" <RoccoA@Routescape.com> writes:
>>
>>
>>> It looks like when we changed regress/GNUmakefile to pull rules from
>>> Makefile.shlib, cygwin got broken in the process.
>>> ...
>>> I don't know enough about the rest of the way the cygwin port is put
>>> together, but it seems that the other platforms all have
>>> shlib=lib$(NAME)...
>>>
>>
>> Seems to me that defining shlib that way for Cygwin too would be a
>> reasonable answer, but I'm not sure if there will be any side-effects.
>> Can someone try it?
>>
>>
>>
>>
>
> The attached patch worked for me. The second part should not be
> applied - I simply include it to illustrate the hack (taken from a
> recent clue on the Cygwin mailing list) that I found necessary to get
> around brokenness on the latest release of Cygwin. The good news is
> that they do seem to be trying to find out what broke and fix it.
>
>
Index: src/Makefile.shlib
===================================================================
RCS file: /projects/cvsroot/pgsql/src/Makefile.shlib,v
retrieving revision 1.95
diff -c -r1.95 Makefile.shlib
*** src/Makefile.shlib 13 Jul 2005 17:00:44 -0000 1.95
--- src/Makefile.shlib 7 Aug 2005 13:21:58 -0000
***************
*** 234,240 ****
endif
ifeq ($(PORTNAME), cygwin)
! shlib = $(NAME)$(DLSUFFIX)
# needed for /contrib modules, not sure why
SHLIB_LINK += $(LIBS)
haslibarule = yes
--- 234,240 ----
endif
ifeq ($(PORTNAME), cygwin)
! shlib = lib$(NAME)$(DLSUFFIX)
# needed for /contrib modules, not sure why
SHLIB_LINK += $(LIBS)
haslibarule = yes
Index: src/backend/storage/file/fd.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/storage/file/fd.c,v
retrieving revision 1.118
diff -c -r1.118 fd.c
*** src/backend/storage/file/fd.c 4 Jul 2005 04:51:48 -0000 1.118
--- src/backend/storage/file/fd.c 7 Aug 2005 13:22:00 -0000
***************
*** 327,332 ****
--- 327,334 ----
elog(WARNING, "dup(0) failed after %d successes: %m", used);
break;
}
+ if (used >= 250)
+ break;
if (used >= size)
{
Andrew Dunstan <andrew@dunslane.net> writes:
> ... The second part should not be
> applied - I simply include it to illustrate the hack (taken from a
> recent clue on the Cygwin mailing list) that I found necessary to get
> around brokenness on the latest release of Cygwin. The good news is
> that they do seem to be trying to find out what broke and fix it.
You mean this?
> *** src/backend/storage/file/fd.c 4 Jul 2005 04:51:48 -0000 1.118
> --- src/backend/storage/file/fd.c 7 Aug 2005 13:22:00 -0000
> ***************
> *** 327,332 ****
> --- 327,334 ----
> elog(WARNING, "dup(0) failed after %d successes: %m", used);
> break;
> }
> + if (used >= 250)
> + break;
>
> if (used >= size)
> {
Looking at that code, I wonder why we don't make the loop stop at
max_files_per_process opened files --- the useful result will be
bounded by that anyhow. Actively running the system out of FDs,
even momentarily, doesn't seem like a friendly thing to do.
This wouldn't directly solve your problem unless you reduced the
default value of max_files_per_process, but at least that would
be something reasonable to do instead of hacking the code.
regards, tom lane
Andrew Dunstan <andrew@dunslane.net> writes:
>> Tom Lane wrote:
>>> Seems to me that defining shlib that way for Cygwin too would be a
>>> reasonable answer, but I'm not sure if there will be any side-effects.
>>> Can someone try it?
>>
>> The attached patch worked for me.
> ifeq ($(PORTNAME), cygwin)
> ! shlib = $(NAME)$(DLSUFFIX)
> # needed for /contrib modules, not sure why
> SHLIB_LINK += $(LIBS)
> haslibarule = yes
> --- 234,240 ----
> endif
> ifeq ($(PORTNAME), cygwin)
> ! shlib = lib$(NAME)$(DLSUFFIX)
> # needed for /contrib modules, not sure why
> SHLIB_LINK += $(LIBS)
> haslibarule = yes
Couple thoughts here --- one, someone upthread suggested
"cyg$(NAME)$(DLSUFFIX" as the proper value for shlib. I didn't
see why at first, but now it occurs to me that it might avoid name
collisions with Windows-native builds, which use the "lib" prefix.
I'm not sure if DLLs for Cygwin and native builds would ever go
into the same directory though. Is this worth worrying about?
Second, in view of Rocco's recent fixes for AIX, I wonder whether that
hack addition to SHLIB_LINK is still needed?
regards, tom lane
On Sun, Aug 07, 2005 at 12:08:28PM -0400, Tom Lane wrote: > Couple thoughts here --- one, someone upthread suggested > "cyg$(NAME)$(DLSUFFIX" as the proper value for shlib. I didn't > see why at first, but now it occurs to me that it might avoid name > collisions with Windows-native builds, which use the "lib" prefix. > I'm not sure if DLLs for Cygwin and native builds would ever go > into the same directory though. Is this worth worrying about? .exe's in different directories than .dll's but all in PATH. -- marko
Tom Lane wrote:
>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>... The second part should not be
>>applied - I simply include it to illustrate the hack (taken from a
>>recent clue on the Cygwin mailing list) that I found necessary to get
>>around brokenness on the latest release of Cygwin. The good news is
>>that they do seem to be trying to find out what broke and fix it.
>>
>>
>
>You mean this?
>
>
>
>>*** src/backend/storage/file/fd.c 4 Jul 2005 04:51:48 -0000 1.118
>>--- src/backend/storage/file/fd.c 7 Aug 2005 13:22:00 -0000
>>***************
>>*** 327,332 ****
>>--- 327,334 ----
>> elog(WARNING, "dup(0) failed after %d successes: %m", used);
>> break;
>> }
>>+ if (used >= 250)
>>+ break;
>>
>> if (used >= size)
>> {
>>
>>
>
>Looking at that code, I wonder why we don't make the loop stop at
>max_files_per_process opened files --- the useful result will be
>bounded by that anyhow. Actively running the system out of FDs,
>even momentarily, doesn't seem like a friendly thing to do.
>
>This wouldn't directly solve your problem unless you reduced the
>default value of max_files_per_process, but at least that would
>be something reasonable to do instead of hacking the code.
>
>
>
>
Turns out that works as is on Cygwin - no adjustment necessary, at least
for me. 250 was just a number I plucked out of the air to get me around
the crashing problem. I just ran successfully with the attached patch.
Given the problems the Cygwin people are having with the stable branch
from just this piece of code, I think this or something similar should
be applied to the 8.0 branch as well as HEAD.
cheers
andrew
Index: src/backend/storage/file/fd.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/storage/file/fd.c,v
retrieving revision 1.118
diff -c -r1.118 fd.c
*** src/backend/storage/file/fd.c 4 Jul 2005 04:51:48 -0000 1.118
--- src/backend/storage/file/fd.c 7 Aug 2005 17:00:10 -0000
***************
*** 315,321 ****
fd = (int *) palloc(size * sizeof(int));
/* dup until failure ... */
! for (;;)
{
int thisfd;
--- 315,321 ----
fd = (int *) palloc(size * sizeof(int));
/* dup until failure ... */
! for ( ; used <= max_files_per_process ; )
{
int thisfd;
Marko Kreen wrote: >On Sun, Aug 07, 2005 at 12:08:28PM -0400, Tom Lane wrote: > > >>Couple thoughts here --- one, someone upthread suggested >>"cyg$(NAME)$(DLSUFFIX" as the proper value for shlib. I didn't >>see why at first, but now it occurs to me that it might avoid name >>collisions with Windows-native builds, which use the "lib" prefix. >>I'm not sure if DLLs for Cygwin and native builds would ever go >>into the same directory though. Is this worth worrying about? >> >> > >.exe's in different directories than .dll's but all in PATH. > > > Especially DLLs in the system directory. Anyway, I see no point *not* to observe the platform's convention. I just tested it and make check worked fine. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Looking at that code, I wonder why we don't make the loop stop at
>> max_files_per_process opened files --- the useful result will be
>> bounded by that anyhow. Actively running the system out of FDs,
>> even momentarily, doesn't seem like a friendly thing to do.
> Turns out that works as is on Cygwin - no adjustment necessary, at least
> for me. 250 was just a number I plucked out of the air to get me around
> the crashing problem. I just ran successfully with the attached patch.
> Given the problems the Cygwin people are having with the stable branch
> from just this piece of code, I think this or something similar should
> be applied to the 8.0 branch as well as HEAD.
I back-patched 7.4 as well, which is the oldest branch that has this
code. The Cygwin people still need to fix their bug, since it's
entirely possible to run the system out of FDs after we're up and
running ... but it's surely a waste of cycles to do it deliberately
during postmaster startup.
regards, tom lane
Andrew Dunstan <andrew@dunslane.net> writes:
> Marko Kreen wrote:
>> On Sun, Aug 07, 2005 at 12:08:28PM -0400, Tom Lane wrote:
>>> Couple thoughts here --- one, someone upthread suggested
>>> "cyg$(NAME)$(DLSUFFIX" as the proper value for shlib.
>>
>> .exe's in different directories than .dll's but all in PATH.
> Especially DLLs in the system directory. Anyway, I see no point *not* to
> observe the platform's convention.
> I just tested it and make check worked fine.
OK, applied with the "cyg" prefix.
When you get a chance, would you see if the SHLIB_LINK += $(LIBS)
bit is still needed?
regards, tom lane
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>Marko Kreen wrote: >> >> >>>On Sun, Aug 07, 2005 at 12:08:28PM -0400, Tom Lane wrote: >>> >>> >>>>Couple thoughts here --- one, someone upthread suggested >>>>"cyg$(NAME)$(DLSUFFIX" as the proper value for shlib. >>>> >>>> >>>.exe's in different directories than .dll's but all in PATH. >>> >>> > > > >>Especially DLLs in the system directory. Anyway, I see no point *not* to >>observe the platform's convention. >> >> > > > >>I just tested it and make check worked fine. >> >> > >OK, applied with the "cyg" prefix. > >When you get a chance, would you see if the SHLIB_LINK += $(LIBS) >bit is still needed? > > > > I commented it out of the Cygwin stanza and all seemed fine - contrib built and passed installcheck quite happily. cheers andrew
On Sun, Aug 07, 2005 at 02:51:12PM -0400, Tom Lane wrote: > I back-patched 7.4 as well, which is the oldest branch that has this > code. The Cygwin people still need to fix their bug, since it's > entirely possible to run the system out of FDs after we're up and > running ... but it's surely a waste of cycles to do it deliberately > during postmaster startup. AFAICT, this should be fixed in Cygwin CVS: http://cygwin.com/ml/cygwin/2005-08/msg00249.html Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> When you get a chance, would you see if the SHLIB_LINK += $(LIBS)
>> bit is still needed?
> I commented it out of the Cygwin stanza and all seemed fine - contrib
> built and passed installcheck quite happily.
Great ... one less platform-specific kluge is always a good thing.
regards, tom lane
Andrew Dunstan schrieb: > Tom Lane wrote: >> Andrew Dunstan writes: >>> Marko Kreen wrote: >>>> On Sun, Aug 07, 2005 at 12:08:28PM -0400, Tom Lane wrote: >>>>> Couple thoughts here --- one, someone upthread suggested >>>>> "cyg$(NAME)$(DLSUFFIX" as the proper value for shlib. >>>> >>>> .exe's in different directories than .dll's but all in PATH. >> >>> Especially DLLs in the system directory. Anyway, I see no point *not* >>> to observe the platform's convention. >>> >>> I just tested it and make check worked fine. >> >> OK, applied with the "cyg" prefix. >> >> When you get a chance, would you see if the SHLIB_LINK += $(LIBS) >> bit is still needed? > > I commented it out of the Cygwin stanza and all seemed fine - contrib > built and passed installcheck quite happily. Ok, thanks a lot! This was my hack. The magic cyg prefix makes it easier for libtool and the gcc linker to detect dll's for import libraries, and also makes it easier to mix both (cygwin vs. mingw and msvc) client libs and have both of them in the path. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/