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 .dl
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 plat
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 was
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
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
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
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-n
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 goo
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
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),
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
> tha
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 cygw
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 p
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)
"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 ha
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) $(NA
16 matches
Mail list logo
