Re: mingw configure failure workaround

Peter Eisentraut wrote:

>Andrew Dunstan wrote:
>  
>
>>However, the problem is that the first line will actually appear to
>>have succeeded, i.e. MSys's ln is lying to us ;-(
>>    
>>
>
>Then msys needs to be fixed.  There is certainly a bunch of 
>autoconfiscated software that gets compiled on mingw/msys every day.  I 
>would like to know why we are the only ones having this problem.  Has 
>anyone contacted the msys authors about this?
>  
>

I don't know -  I recall hearing something, but I have found no trace. I 
will follow it up, but I do not think this absolves us of all 
responsibility. We work around all sorts of problems on all sorts of 
platforms.

>  
>
>>This comes from the autoconf macro _AC_OUTPUT_LINKS defined in its
>>status.m4, which I guess is what we'd need to override (is that
>>possible?)
>>    
>>
>
>No
>  
>

I will take your word for it, but see below.

>  
>
>>if we are going to detect the failure, or maybe there's
>>some more magical way that in my unfamiliarity with autoconf I am
>>unaware of.
>>    
>>
>
>No
>
>
>  
>
"No" is our answer too often.

A lot of reading and some experimentation showed that putting this in 
configure.in:

AC_OUTPUT_COMMANDS([ for linktarget in src/backend/port/dynloader.c 
src/backend/port/pg_sema.c src/backend/port/pg_shmem.c 
src/include/dynloader.h src/include/pg_config_os.h src/Makefile.port ; do   test -e $linktarget || echo " ***" link for
$linktargetfailed - 
 
please fix by hand done
])


yielded results looking like this:

config.status: executing default-1 commands*** link for src/backend/port/pg_shmem.c failed - please fix by hand*** link
forsrc/include/dynloader.h failed - please fix by hand
 

Which is more or less what I wanted as a minimum.


cheers

andrew