From: Christof P. <chr...@pe...> - 2002-06-24 06:43:43
|
Hi Earnie, 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 different projects). Is there any chance to get it working again in future revisions (even copying without going into endless loops is better than now). Perhaps falling back to slow symlinks in the case of directories is an option? Also supplying 'which' might help with a lot of autogen.sh/configure.in scripts. [In my case a directory named Aux prompted for a rename of a full include hierarchy :-( ] Christof PS: find is somewhat slow (Win95, VFAT32) but not much slower than configure ;-P |
From: Jan D. W. <Jan...@zu...> - 2002-06-24 09:20:30
|
Hi List[eners], Christof Petig wrote: > > Hi Earnie, > > 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 > different projects). Is there any chance to get it working again in > future revisions (even copying without going into endless loops is > better than now). Perhaps falling back to slow symlinks in the case of > directories is an option? > > Also supplying 'which' might help with a lot of autogen.sh/configure.in > scripts. > what about aliasing type -p ? > [In my case a directory named Aux prompted for a rename of a full > include hierarchy :-( ] > > Christof > > PS: find is somewhat slow (Win95, VFAT32) but not much slower than > configure ;-P -- Jan Wegner Software Engineer Zuken GmbH Vattmannstrasse 3 D-33100 Paderborn Tel: +49 5251 150627 Fax: +49 5251 150700 ----*... and may all your GUIs be fast and friendly.*---- |
From: Earnie B. <ear...@ya...> - 2002-06-24 11:40:09
|
Christof Petig wrote: > > Hi Earnie, > > 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 > different projects). You don't state how it fails. Win32 itself doesn't support symlink. Using the copy method has increased the throughput by great measure. The 1.0.8 release will remove the ln script and replace it with a modified ln.exe and the symlink function now does the copy. I will do my best to get the `ln -s . foo' function working before official version release. > Is there any chance to get it working again in > future revisions (even copying without going into endless loops is > better than now). Perhaps falling back to slow symlinks in the case of > directories is an option? > 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 appropriatly. > Also supplying 'which' might help with a lot of autogen.sh/configure.in > scripts. > The bash command for `which' is `type -a'. > [In my case a directory named Aux prompted for a rename of a full > include hierarchy :-( ] > > Christof > > PS: find is somewhat slow (Win95, VFAT32) but not much slower than > configure ;-P > Find is even slower with symlink imitation. Earnie. |
From: Christof P. <chr...@pe...> - 2002-06-24 13:12:14
|
Earnie Boyd wrote: > Christof Petig wrote: > >>Hi Earnie, >> >>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 >>different projects). > > > 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: cmovne 0x8(%ebp),%eax ... 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 > appropriatly. 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 problem, too. >>Also supplying 'which' might help with a lot of autogen.sh/configure.in >>scripts. > > The bash command for `which' is `type -a'. > Oh it's not fully equivalent: $ type -a ecpg ecpg is /usr/bin/ecpg $ which ecpg /usr/bin/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) Christof PS: I found $ type -p ecpg /usr/bin/ecpg to give the desired answer. But isn't which more portable? |
From: Earnie B. <ear...@ya...> - 2002-06-24 14:17:45
|
Christof Petig wrote: > > But I have a different problem with 1.0.8: > > at offset 0x9a80b within msys-1.0.dll there is the following code: > > cmovne 0x8(%ebp),%eax > ... > Download a more recent snapshot. > 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. Yes, an unfortunate setting in my environment when I rebuilt for each architecture that I didn't catch. > > > 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 > > appropriatly. > > 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 > problem, too. > Yes, it would make it slower. > >>Also supplying 'which' might help with a lot of autogen.sh/configure.in > >>scripts. > > > > The bash command for `which' is `type -a'. > > > > Oh it's not fully equivalent: > > $ type -a ecpg > ecpg is /usr/bin/ecpg > $ which ecpg > /usr/bin/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) > I might consider it as a part of the msysDTK but it doesn't fit the Minimal quotient. It's not needed for a typical configure to execute. Earnie. |
From: Christof P. <chr...@pe...> - 2002-06-24 17:00:33
|
Earnie Boyd wrote: > Christof Petig wrote: > >>But I have a different problem with 1.0.8: >> >>at offset 0x9a80b within msys-1.0.dll there is the following code: >> >>cmovne 0x8(%ebp),%eax >>... >> > > > Download a more recent snapshot. more recent than 2002-6-18-1 ? Christof |
From: Luke D. <cod...@ho...> - 2002-06-25 01:19:28
|
----- Original Message ----- From: "Christof Petig" <chr...@pe...> To: "Earnie Boyd" <min...@li...> Sent: Tuesday, June 25, 2002 1:00 AM Subject: Re: [Mingw-msys] MSys experiences > Earnie Boyd wrote: > > Christof Petig wrote: > > > >>But I have a different problem with 1.0.8: > >> > >>at offset 0x9a80b within msys-1.0.dll there is the following code: > >> > >>cmovne 0x8(%ebp),%eax > >>... > >> > > > > > > Download a more recent snapshot. > > more recent than 2002-6-18-1 ? > > > Christof I did "grep cmov msys-1.0.8-i386-2002.06.18-1.odmp" and it appears that you are correct that the updated snapshot is still built for the wrong architecture. Luke |
From: Earnie B. <ear...@ya...> - 2002-06-25 11:15:57
|
Luke Dunstan wrote: > > ----- Original Message ----- > From: "Christof Petig" <chr...@pe...> > To: "Earnie Boyd" <min...@li...> > Sent: Tuesday, June 25, 2002 1:00 AM > Subject: Re: [Mingw-msys] MSys experiences > > > Earnie Boyd wrote: > > > Christof Petig wrote: > > > > > >>But I have a different problem with 1.0.8: > > >> > > >>at offset 0x9a80b within msys-1.0.dll there is the following code: > > >> > > >>cmovne 0x8(%ebp),%eax > > >>... > > >> > > > > > > > > > Download a more recent snapshot. > > > > more recent than 2002-6-18-1 ? > > > > > > Christof > > I did "grep cmov msys-1.0.8-i386-2002.06.18-1.odmp" and it appears that you > are correct that the updated snapshot is still built for the wrong > architecture. > Well, actually it was libgcc and libstdc++ that was built with the wrong architecture causing interesting results. Another plus for libgcc.dll and libstdc++.dll. Earnie. |
From: Bob F. <bfr...@si...> - 2002-06-24 15:41:50
|
On Mon, 24 Jun 2002, Earnie Boyd wrote: > > The bash command for `which' is `type -a'. Since 'which' is so easy to implement, and can be be a simple shell script (as it usually is in the Unix world), can we have it in a future version of MSYS? Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: Luke D. <cod...@ho...> - 2002-06-25 01:23:20
|
----- Original Message ----- From: "Bob Friesenhahn" <bfr...@si...> To: "Earnie Boyd" <min...@li...> Cc: "Christof Petig" <chr...@pe...> Sent: Monday, June 24, 2002 11:41 PM Subject: Re: [Mingw-msys] MSys experiences > On Mon, 24 Jun 2002, Earnie Boyd wrote: > > > > The bash command for `which' is `type -a'. > > Since 'which' is so easy to implement, and can be be a simple shell > script (as it usually is in the Unix world), can we have it in a > future version of MSYS? > > Bob The bash source code also contains an example 'which' script that apparently emulates the FreeBSD version of 'which'. See "msys/packages/bash/2.04/examples/functions/which" in CVS. Luke |