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
Tom Lane wrote:
Rocco Altier [EMAIL PROTECTED] 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
er that would be this patch.
Andrew Dunstan wrote:
Tom Lane wrote:
Rocco Altier [EMAIL PROTECTED] 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
Andrew Dunstan [EMAIL PROTECTED] 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
Andrew Dunstan [EMAIL PROTECTED] 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)
!
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
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] 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
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
Andrew Dunstan [EMAIL PROTECTED] 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
Andrew Dunstan [EMAIL PROTECTED] 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.
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] 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
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
Andrew Dunstan [EMAIL PROTECTED] 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
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)
Rocco Altier [EMAIL PROTECTED] 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
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)
16 matches
Mail list logo
