Greetings, Al!
>> You didn't read my reply to the end, but I accept your explanation.
>> Still, that specific point of code is suspicious for my taste of
>> fool-proof'ness.
>>
> Sure you could reflect about the length of minor versions here. But
> does that address the original topic? :-)
> Aft
>
> You didn't read my reply to the end, but I accept your explanation.
> Still, that specific point of code is suspicious for my taste of
> fool-proof'ness.
>
Sure you could reflect about the length of minor versions here. But
does that address the original topic? :-)
After python 2.7 there is 3
Greetings, Al!
>> I'm fairly certain, that the script is bugged in this specific case.
>> It should be looking for python2.* instead.
>> Minor version could have any length... potentially. (And yes, I know, there
>> wouldn't be .10 for now)
> Definitly not. It would also find "python2.6-config" w
Greetings, Al!
>> For instance, this one: Either we always remove the .exe suffix from
>> a file, or we have to check for each file with a .exe suffix, whether
>> it's executable or not.
> Probably without checking it. No sane program would use the .exe
> suffix as extension of a mere textfile.
> I'm fairly certain, that the script is bugged in this specific case.
> It should be looking for python2.* instead.
> Minor version could have any length... potentially. (And yes, I know, there
> wouldn't be .10 for now)
Definitly not. It would also find "python2.6-config" which is not
wanted. It
>> 1.) When a file is made executable .exe is appended, but only visible
>> from Windows API.
> How would this work with non-Cygwin programs? They wouldn't be handled
> under
> (1).
Depends on how you install or mount them.
But yes, as a prerequest there would be two types of filessystem
handli
Greetings, Al!
> I have another interesting case where .exe magic doesn't work as
> transparently as one would expect.
> I have a file python2.6.exe. A script tries to find it with "ls
> python2.?". It is not found.
I'm fairly certain, that the script is bugged in this specific case.
It should b
On 9/15/2010 12:23 PM, Al wrote:
For instance, this one: Either we always remove the .exe suffix from
a file, or we have to check for each file with a .exe suffix, whether
it's executable or not.
Probably without checking it. No sane program would use the .exe
suffix as extension of a mere te
>
> For instance, this one: Either we always remove the .exe suffix from
> a file, or we have to check for each file with a .exe suffix, whether
> it's executable or not.
Probably without checking it. No sane program would use the .exe
suffix as extension of a mere textfile.
What would be the id
> I'd love to drop the .exe suffix from readdir(), I'm just not sure what
> unwelcome side-effects we create.
>
Yes, that's always the point. All programs would break, that are only
build against the .exe suffix. Like mine after patching it. :-)
Don't know if Cygwin has a testing state to fix tho
On Sep 15 15:50, Corinna Vinschen wrote:
> On Sep 15 15:38, Al wrote:
> > >
> > > True. In theory we would have to remove .exe and .lnk suffixes from
> > > directory listings as well, but that was never the case in Cygwin.
> > >
> > >
> >
> > That's the way it has always been... isn't a strong ar
On Sep 15 15:38, Al wrote:
> >
> > True. In theory we would have to remove .exe and .lnk suffixes from
> > directory listings as well, but that was never the case in Cygwin.
> >
> >
>
> That's the way it has always been... isn't a strong argument in development.
It wasn't an argument, it was jus
>
> True. In theory we would have to remove .exe and .lnk suffixes from
> directory listings as well, but that was never the case in Cygwin.
>
>
That's the way it has always been... isn't a strong argument in development.
I guess there are some other reasons to do it this way. If not one
should
On Sep 15 13:40, Al wrote:
> Hello,
>
> I have another interesting case where .exe magic doesn't work as
> transparently as one would expect.
>
> I have a file python2.6.exe. A script tries to find it with "ls
> python2.?". It is not found.
>
> Here the script needs a modification to work with C
Hello,
I have another interesting case where .exe magic doesn't work as
transparently as one would expect.
I have a file python2.6.exe. A script tries to find it with "ls
python2.?". It is not found.
Here the script needs a modification to work with Cygwin, but we can't
really say that there is
>
> I got a little bit confused now. Should I report now upstream at Perl
> that Configure
> has a problem by adding .exe, or is it just a problem with your layout?
>
> AFAIK perl does not symlink tr.exe, just its own files when using
> -Dmksymlinks.
> And failing to read a wrong tr.exe symlink do
>
> I got a little bit confused now. Should I report now upstream at Perl
> that Configure
> has a problem by adding .exe, or is it just a problem with your layout?
>
> AFAIK perl does not symlink tr.exe, just its own files when using
> -Dmksymlinks.
> And failing to read a wrong tr.exe symlink do
2010/9/6 Al:
>> The magic is to *add* the .exe suffix automatically, not *removing* it
>
> Aaaahh!
>
> That is one point I missed. The magic is still more limited than I
> assumed. It felt to work bidirectional.
>
> I have tested this. The unidirectonal magic also works for symlinks,
> if t
> The magic is to *add* the .exe suffix automatically, not *removing* it
Aaaahh!
That is one point I missed. The magic is still more limited than I
assumed. It felt to work bidirectional.
I have tested this. The unidirectonal magic also works for symlinks,
if the symlink has the .exe suf
On Sep 6 14:56, Al wrote:
> >
> > It's definitely a bug in perl's Configure. If the name of the symlink
> > is "foo", there's not the faintest reason to assume that "foo.exe" should
> > work at all.
> >
> >
> > Corinna
> >
>
> Magic is when it does the right thing magically. With your approach
>
>
> It's definitely a bug in perl's Configure. If the name of the symlink
> is "foo", there's not the faintest reason to assume that "foo.exe" should
> work at all.
>
>
> Corinna
>
Magic is when it does the right thing magically. With your approach
you don't need any magic at all.
Al
--
Problem
On Sep 6 12:36, Al wrote:
> >> That's what Perls "Configure" does. Still the magic works only in the
> >> target directory, but not on the level of the symlink itself.
> >
> > Uh, I see. That's a bug in perl's Configure. It shouldn't use the
> > .exe suffix at all.
> >
> >
>
> Right, Perl wants
>> That's what Perls "Configure" does. Still the magic works only in the
>> target directory, but not on the level of the symlink itself.
>
> Uh, I see. That's a bug in perl's Configure. It shouldn't use the
> .exe suffix at all.
>
>
Right, Perl wants to be superschlau and adds the .exe suffix.
On Sep 6 11:53, Al wrote:
> It does not:
>
> > It does:
> >
> > $ cd tmp
> > $ mkdir dir1 dir2
> > $ cp /bin/echo.exe dir1
> > $ ln -s `pwd`/dir1/echo.exe dir2/echo
> > $ ls -l dir*
> > dir1:
> > total 52
> > -rwxr-xr-x 1 corinna vinschen 49166 2010-09-06 10:59 echo.exe
> >
> > dir2:
> >
It does not:
> It does:
>
> $ cd tmp
> $ mkdir dir1 dir2
> $ cp /bin/echo.exe dir1
> $ ln -s `pwd`/dir1/echo.exe dir2/echo
> $ ls -l dir*
> dir1:
> total 52
> -rwxr-xr-x 1 corinna vinschen 49166 2010-09-06 10:59 echo.exe
>
> dir2:
> total 1
> lrwxrwxrwx 1 corinna vinschen 31 2010-09-06
On Sep 5 16:28, Al wrote:
> I came accross the following. These two files existed.
>
> /home/prefix/gentoo/bin/tr.exe
> /home/prefix/gentoo/usr/bin/tr -> /home/prefix/gentoo.bin/tr.exe
^^^
dot,
>
> Sounds like you didn't run autoreconf (which would have been done
> automatically via the supported mechanism).
>
I have added the autoreconf step to the Emerge scripts.
Only one conflicts with a Gentoo patches, which I had to disable.
Works fine now. Solved all problems from that corner.
2010/9/3 Al :
> 2010/9/3 Al :
Right. I applied it the traditional way.
>>>
>>> Ah, you have to understand this about cygport patches: they only contain
>>> patches for the source files, not the autogenerated ones. So they have
>>> patches for e.g. Makefile.am, configure.ac; but not for confi
2010/9/3 Al :
>>> Right. I applied it the traditional way.
>>
>> Ah, you have to understand this about cygport patches: they only contain
>> patches for the source files, not the autogenerated ones. So they have
>> patches for e.g. Makefile.am, configure.ac; but not for configure or even
>> Makef
>> Right. I applied it the traditional way.
>
> Ah, you have to understand this about cygport patches: they only contain
> patches for the source files, not the autogenerated ones. So they have
> patches for e.g. Makefile.am, configure.ac; but not for configure or even
> Makefile.in. It's vitall
> Cygport is rather similar to emerge/ebuild already. You might find it
> worthwhile to give it a look.
>
I am aware of this. I want come to a solution, that builds me from
sources on any of Windows, Mac and Linux. One to rule them all. I did
only find Gentoo Prefix to be able to do this.
> If
On 9/2/2010 7:46 PM, Dave Korn wrote:
> I did once try running cygport on a linux box (with a cross-compiler). I
> don't remember exactly what went wrong, it didn't work directly out of the
> box, but it shouldn't be hard to fix.
It's only the most recent release of cygport (0.10.0) that has
ru
On 02/09/2010 21:44, Al wrote:
>> Sounds like you didn't run autoreconf (which would have been done
>> automatically via the supported mechanism).
>
> Right. I applied it the traditional way.
Ah, you have to understand this about cygport patches: they only contain
patches for the source files,
On 9/2/2010 3:44 PM, Al wrote:
>> setup.exe to download the sources and several prerequisite tools (cygport,
>> autoconf, ...), then using 'cygport coreutils-8.5-1 prep make'. Other ways
>> work, but I won't support them on this list. See also
>
> As a want to come a hybrid of Cygwin and Gentoos
> Sounds like you didn't run autoreconf (which would have been done
> automatically via the supported mechanism).
Right. I applied it the traditional way.
> setup.exe to download the sources and several prerequisite tools (cygport,
> autoconf, ...), then using 'cygport coreutils-8.5-1 prep make'.
On 09/02/2010 02:06 PM, Al wrote:
I first compiled coreutils without the cygwin patch. It did compile
but afterwards the compilation of findutils, etc. was broken. For
example configure.status of wget was truncated at the top and out of
order at the bottom. That stopped all further efforts of min
>
> Coreutils tends to be an exception, because it is so core to the system.
> Other tools that I also maintain, like m4 or findutils, port with 0
> patches.
>
Thank you. That gives me back some optimism.
I first compiled coreutils without the cygwin patch. It did compile
but afterwards the comp
On 09/02/2010 01:25 PM, Al wrote:
Hello,
I would like to estimate theexpenses to port general linux sources to
Cygwin.
I did look into Cygwins patch for coreutils. It has 1231 lines of diff
code. A lot of the stuff is related to the ".exe" magic done by
cygwin.
Do I have to implement that
On Jun 19 02:04, Charles Wilson wrote:
> Corinna Vinschen wrote:
> >Apart from that, I don't like what libtool does. I think it's a
> >terrible idea to have a script and a binary with the same name (only
> >differing by the .exe suffix) in the same directory. This behaviour
> >breaks the CYGWIN=t
Corinna Vinschen wrote:
Apart from that, I don't like what libtool does. I think it's a
terrible idea to have a script and a binary with the same name (only
differing by the .exe suffix) in the same directory. This behaviour
breaks the CYGWIN=transparent_exe option and there's no reliable way
a
Hi Chuck,
On Apr 18 22:40, Charles Wilson wrote:
> * libltdl/config/ltmain.m4sh [func_mode_link]: move wrapper
> script writing from here...
> [func_emit_libtool_wrapper_script]: to this new function, and
> write to stdout
> [func_mode_link]: move cwrapper source code writing f
[This is a copy of a message already sent to the libtool and
libtool-patches lists. sourceware was being very picky about the
updated [Was: ...] subject line and bounced it, twice. So, I'm
resending it under the original subject line. For fear of offending the
filters again, I'm not even typ
Hello Charles, all,
* Charles Wilson wrote on Wed, Apr 18, 2007 at 08:49:31PM CEST:
> [added libtool to CC list]
Thanks.
> Corinna Vinschen wrote:
> >
> >Is there any chance that this could be changed in libtool?
>
> Absolutely. I outlined the steps necessary to do this:
> http://cygwin.com/ml
[added libtool to CC list]
Corinna Vinschen wrote:
On Apr 18 04:49, Charles Wilson wrote:
The current .exe behavior has benefited from many years of tweaking and
fine-tuning, across many different packages (cygwin, gcc, gdb, binutils,
automake, autoconf, libtool, bash, coreutils, ...) to work
Dave Korn wrote:
> Hear, hear. I don't think anything so drastic as this should be
attempted
> without a deprecation period of a year or so for the old behaviour.
And in
> fact I think it would probably transpire to be a serious limitation on
the
> utility of cygwin. Remember, if you just want
On 18 April 2007 09:49, Charles Wilson wrote:
> Eric Blake wrote:
>> Interesting thought. But it is more than just cygwin 1.7.0 that would
>> have to be changed; we would also need a new release of gcc that no longer
>> added an automatic .exe to files as they are compiled. And there might be
>>
On Apr 18 04:49, Charles Wilson wrote:
> The current .exe behavior has benefited from many years of tweaking and
> fine-tuning, across many different packages (cygwin, gcc, gdb, binutils,
> automake, autoconf, libtool, bash, coreutils, ...) to work together to
> give the current, mostly coherent
Eric Blake wrote:
Interesting thought. But it is more than just cygwin 1.7.0 that would have to
be changed; we would also need a new release of gcc that no longer added an
automatic .exe to files as they are compiled. And there might be some severe
repurcussions in automake/autoconf where the
Frank Fesevur wrote:
Larry Hall (Cygwin) wrote:
Here's a naive thought. See if it makes any sense. We have lots of
complicated logic to try to transparently handle ".exe" extensions.
We have ".exe" extensions because Windows 9x/Me requires it to execute
binaries. For the upcoming Cygwin 1.7 r
Larry Hall (Cygwin) wrote:
Here's a naive thought. See if it makes any sense. We have lots of
complicated logic to try to transparently handle ".exe" extensions.
We have ".exe" extensions because Windows 9x/Me requires it to execute
binaries. For the upcoming Cygwin 1.7 release (date TBD), we'
Eric Blake wrote:
> Larry Hall (Cygwin cygwin.com> writes:
>
>> Here's a naive thought. See if it makes any sense. We have lots of
>> complicated logic to try to transparently handle ".exe" extensions.
>> We have ".exe" extensions because Windows 9x/Me requires it to execute
>> binaries. For t
Larry Hall (Cygwin cygwin.com> writes:
>
> Here's a naive thought. See if it makes any sense. We have lots of
> complicated logic to try to transparently handle ".exe" extensions.
> We have ".exe" extensions because Windows 9x/Me requires it to execute
> binaries. For the upcoming Cygwin 1.7
Christopher Faylor wrote:
On Wed, Jul 20, 2005 at 04:04:54PM +0200, Krzysztof Duleba wrote:
But how does gprof know that foo doesn't exist? It has to open or stat it.
I thought that both open and stat calls support exe magic.
Sorry. That's not how it works. The only "exe magic" in the cygwi
On Wed, Jul 20, 2005 at 04:04:54PM +0200, Krzysztof Duleba wrote:
>But how does gprof know that foo doesn't exist? It has to open or stat it.
>I thought that both open and stat calls support exe magic.
Sorry. That's not how it works. The only "exe magic" in the cygwin DLL
is in the stat call.
>
> But how does gprof know that foo doesn't exist? It has to open or stat it.
> I thought that both open and stat calls support exe magic.
stat() and exec*() support exe magic, open() does not. I don't know
exactly how gprof works, but it is probably doing an open() and failing,
and as such ne
Dave Korn wrote:
.exe magic doesn't work with gprof. Any ideas why?
And indeed, it doesn't work the other way round... [carrying on from your
testcase:]
[EMAIL PROTECTED] /artimi/firmware/test> mv foo.exe foo
[EMAIL PROTECTED] /artimi/firmware/test> rm gmon.out
[EMAIL PROTECTED] /artimi/fir
Original Message
>From: Krzysztof Duleba
>Sent: 20 July 2005 07:07
> .exe magic doesn't work with gprof. Any ideas why?
And indeed, it doesn't work the other way round... [carrying on from your
testcase:]
[EMAIL PROTECTED] /artimi/firmware/test> mv foo.exe foo
[EMAIL PROTECTED] /artimi
57 matches
Mail list logo
