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 $linktarget failed -
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 for src/include/dynloader.h failed - please fix by hand

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

cheers

andrew