On 2016-02-25 17:12, JonY wrote:
On 2/26/2016 01:44, Yaakov Selkowitz wrote:
JonY,
It has been brought to my attention that /usr/lib/w32api is now taking
precedence over /usr/lib, which is a result of this commit:
https://gcc.gnu.org/viewcvs/gcc?view=revision=227962
Greetings, Eliot Moss!
> Dear Cygwin-ers -- I solicit suggestions around the following.
> For a long time I have used cygwin (32 bit) almost exclusively,
> and in that universe my home directory is /home/moss, which in
> Windows land is C:\cygwin\home\moss. Now I also have cygwin64
> installed
Dear Cygwin-ers -- I solicit suggestions around the following.
For a long time I have used cygwin (32 bit) almost exclusively,
and in that universe my home directory is /home/moss, which in
Windows land is C:\cygwin\home\moss. Now I also have cygwin64
installed under C:\cygwin64, with another
On Tue, Feb 23, 2016 at 9:50 PM, Achim Gratz wrote:
>
> That's because the filename really is LibXML.pm (not the upper case L at
> the beginning). Why ls doesn't complain about the filename I'm not sure
> (case insensitive FS search most likely), but find always gets the
> correct case from
On 2/26/2016 01:44, Yaakov Selkowitz wrote:
> JonY,
>
> It has been brought to my attention that /usr/lib/w32api is now taking
> precedence over /usr/lib, which is a result of this commit:
>
> https://gcc.gnu.org/viewcvs/gcc?view=revision=227962
>
JonY,
It has been brought to my attention that /usr/lib/w32api is now taking
precedence over /usr/lib, which is a result of this commit:
https://gcc.gnu.org/viewcvs/gcc?view=revision=227962
https://github.com/gcc-mirror/gcc/commit/c1b7008c95f97dd7c11997e7be7be7b58d113db0
This is incorrect,
On Wed, Feb 24, 2016 at 9:29 PM, Mark Geisert wrote:
> Just a guess: your 64-bit windres is generating a 64-bit .res file that the
> 32-bit g++ can't grok. Look at 'windres -h'. There's a "-F" == "--target"
> flag that can specify a target type. I would try adding "-F pe-i386" after
> the "-O
> Seeking opinions from other package maintainers: is it desirable to have
> Bash (et al.) completion scripts as part of the main package they're
> associated with, or should they be packaged separately?
It seems simpler and completely reasonable to me to include the completion
scripts as part of
Seeking opinions from other package maintainers: is it desirable to have
Bash (et al.) completion scripts as part of the main package they're
associated with, or should they be packaged separately?
Currently, the two packages I maintain (fzf and Git) both have separate
packages for their Bash
On Feb 25 00:47, Mark Geisert wrote:
> On Tue, 23 Feb 2016, Corinna Vinschen wrote:
> >On Feb 22 23:36, Mark Geisert wrote:
> >>On Mon, 22 Feb 2016, Jon Turney wrote:
> >>>There doesn't seem to be anything specific to profiling about this, so it
> >>>could be written in a more generic way, as
On Tue, 23 Feb 2016, Corinna Vinschen wrote:
On Feb 22 23:36, Mark Geisert wrote:
On Mon, 22 Feb 2016, Jon Turney wrote:
There doesn't seem to be anything specific to profiling about this, so it
could be written in a more generic way, as "call a callback function for
each thread".
I saw your
11 matches
Mail list logo
