Earnie Boyd wrote:
> Christof Petig wrote:
>>First: MSys is great. My app (huge C++ project) compiled without many
>>problems on windows (I used to cross compile on Linux). Many thanks for
>>providing this easy-to-use package!
>>But one problem I came across:
>>- I'm not quite happy with the symlink = copy approach. There might be
>>good reasons but at least
>> ln -sf . foo
>>fails miserably (Not too uncommon make include paths compatible between
> You don't state how it fails. Win32 itself doesn't support symlink.
Didn't I? Well it goes into an endless recursion. At least it did the
last time I tried (actually the recursion is not endless, at one point
the system (Win95) froze/crashed - I'm not too eager to try it again).
But I have a different problem with 1.0.8:
at offset 0x9a80b within msys-1.0.dll there is the following code:
IIRC this is a PII command, so 1.0.8 simply gives illegal instruction on
my P5 (at this address). Of course I tested the 386 and 586 version.
Simply try gdb ls.exe, r on a P5.
> Again the symlink isn't supported by win32 and was a resource consumer
> to imitate. I will do my best to cause your example to function
I proposed to fall back to the old method only if a directory is
symlinked (if this is possible). But probably this makes it too slow.
I solved it for my program. But perhaps other programs show this
>>Also supplying 'which' might help with a lot of autogen.sh/configure.in
> The bash command for `which' is `type -a'.
Oh it's not fully equivalent:
$ type -a ecpg
ecpg is /usr/bin/ecpg
$ which ecpg
but of course a combination of sed and type -a does the trick. I simply
asked about future inclusion of 'which' (no matter whether it is a
binary or an alias script)
PS: I found
$ type -p ecpg
to give the desired answer. But isn't which more portable?