Thread: Cygwin - make check broken

Cygwin - make check broken

From
"Rocco Altier"
Date:
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


Re: Cygwin - make check broken

From
Tom Lane
Date:
"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


Re: Cygwin - make check broken

From
Reini Urban
Date:
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

From
yuanjia lee
Date:
test


    
__________________________________ 
Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 
http://tour.mail.yahoo.com/mailtour.html 



Re: Cygwin - make check broken

From
Andrew Dunstan
Date:

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


Re: Cygwin - make check broken

From
Andrew Dunstan
Date:
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)
          {

Re: Cygwin - make check broken

From
Tom Lane
Date:
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


Re: Cygwin - make check broken

From
Tom Lane
Date:
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


Re: Cygwin - make check broken

From
Marko Kreen
Date:
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



Re: Cygwin - make check broken

From
Andrew Dunstan
Date:

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;


Re: Cygwin - make check broken

From
Andrew Dunstan
Date:

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






Re: Cygwin - make check broken

From
Tom Lane
Date:
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


Re: Cygwin - make check broken

From
Tom Lane
Date:
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


Re: Cygwin - make check broken

From
Andrew Dunstan
Date:

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


Re: Cygwin - make check broken

From
Jason Tishler
Date:
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


Re: Cygwin - make check broken

From
Tom Lane
Date:
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


Re: Cygwin - make check broken

From
Reini Urban
Date:
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/