[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: _AS_LN_S_PREPARE question
From: |
Duft Markus |
Subject: |
RE: _AS_LN_S_PREPARE question |
Date: |
Fri, 8 Feb 2008 12:25:03 +0100 |
Ralf Wildenhues <mailto:address@hidden> wrote:
> Hello Markus,
>
> * Duft Markus wrote on Fri, Feb 08, 2008 at 10:44:39AM CET:
>>
>> I have aquestion: I'm porting to windows (cross compiled from
>> interix). Interix has a working ln, but windows doesn't understand
>> those links. Now I wanted to check for winnt in _AS_LN_S_PREPARE.
>> Can I use AC_CANONICAL_HOST for this? What I'd need is the
>> config.guess output.
>
> No, _AS_LN_S_PREPARE comes very early in the scripts, and you
> basically cannot rely on any other macros. Can you explain what goes
> wrong with the test, because if ln is working as expected, then
> _AS_LN_S_PREPARE should just detect that? Adding `set -x' before and
> `set +x' after the test, in the configure script, is a good method to
> see what's happening.
No, the test goes ok, but i have the following situation:
I configure something with --build=i586-pc-winnt on an i586-pc-interix*
host. I use build to keep anybody from thinking, that we're cross
compiling (in reality i am cross-compiling, but still i can execute
those binaries). As compiler i use a wrapper that calls microsoft's
cl.exe in native windows.
Now autoconf detects (correctly) that softlinks work fine, and everybody
is happy - except cl.exe which doesn't understand those softlinks. I
manage to catch most of them (e.g. links to libraries) in my wrapper
around cl.exe, but i cannot catch linked header files, since the
.c/.cc/.cpp files just say include, and the compiler looks up the files.
If one of those include'd files is a link, cl.exe crashes.
For this reason i have in my latest libtool HEAD patch:
AC_REQUIRE([AC_PROG_LN_S])dnl
test -z "$LN_S" && LN_S="ln -s"
# on winnt, the microsoft compiler is used behind the scenes.
# the wrapper around it is capable of resolving links, but still
# cl.exe chokes on header files which are linked (the wrapper
# cannot know of these...).
# this should be fixed in autoconf (_AS_LN_S_PREPARE), not here,
# but i don't know autoconf that well, and i have no idea how i
# can check the host_os at that point...
case $host_os in
winnt*) LN_S="cp -p" ;;
esac
_LT_DECL([], [LN_S], [1], [Whether we need soft or hard links])dnl
I don't really like that one, because it's not a libtool issue really.
It would be cool if autoconf would know that...
Note: i586-pc-winnt is the host triplet i chose for my wrapper around
microsoft's tools, see
http://lists.gnu.org/archive/html/libtool-patches/2008-02/msg00004.html.
Cheers, Markus
>
> Also, please note that the macro has undergone some changes since
> 2.61.
>
> Cheers,
> Ralf