Re: Cygwin - make check broken - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Cygwin - make check broken
Date
Msg-id 2193.1123430908@sss.pgh.pa.us
Whole thread Raw
In response to Re: Cygwin - make check broken  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Cygwin - make check broken  (Marko Kreen <marko@l-t.ee>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Cygwin - make check broken
Next
From: Tom Lane
Date:
Subject: Race condition in backend process exit