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
