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
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 |