Re: Cygwin - make check broken

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Rocco Altier <RoccoA(at)Routescape(dot)com>
Subject: Re: Cygwin - make check broken
Date: 2005-08-07 16:08:28
Message-ID: 2193.1123430908@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-08-07 16:47:16 Race condition in backend process exit
Previous Message Tom Lane 2005-08-07 16:02:24 Re: Cygwin - make check broken