I'd like to package and maintain nosleep for Cygwin. nosleep runs a
command while inhibiting the computer from sleeping or hibernating until
the command finishes executing. By default nosleep just prevents the
computer from going to sleep during idle periods. More aggressive options
are
On 10/09/2011 02:57, Chris Sutcliffe wrote:
Hi All,
Just a heads up around an issue I encountered with rtorrent after
executing rebaseall. I ran in to some forking issues so I executed
rebaseall after which rtorrent started to crash constantly during
various operations. Through trial and
Sometimes it started properly but usually not.
$ screen --version
Screen version 4.00.03 (FAU) 23-Oct-06
$ screen
2 [main] screen 2876 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
1058 [main] screen 2876 open_stackdumpfile: Dumping stack trace to
screen.exe.stackdump
$ cat ~/.vimrc
syntax on
$ vim
Error detected while processing /cygdrive/e/home/.vimrc:
line1:
E484: Can't open file /usr/share/vim/syntax/syntax.vim
Press ENTER or type command to continue
This issue reported previously:
http://cygwin.com/ml/cygwin/2006-07/msg00105.html
--
Problem
Hi list,
Not sure if this counts as a packaging issue so I'm sending it here first.
The problem I'm having is that the above-mentioned libraries all have
libstdc++ ('-lstdc++' to be precise) listed as a dependent lib in the .la
files that are generated by libtool during compilation (and
On 25/09/2011 15:51, Dave Korn wrote:
I'd be happier if this could either be fixed in the distro, or if someone
could tell me why these libs think they need to link against libstdc++?
It seems I'm not the first to have run into this problem:
On 2011-09-25 PM 11:51, Dave Korn wrote:
before you can compile it from source, and that it might be worth backing up
the .la files just in case this -lstdc++ actually is required somewhere, but
I'd be happier if this could either be fixed in the distro, or if someone
could tell me why these
On 25/09/2011 07:07, Dave Korn wrote:
Sourceware CVS is down right now but I'll be
sending the attached to binutils when it's working again,
Yeah, d'oh. Maybe I'll send the file with the actual patch in it, instead
of the fresh diff I tried to generate when CVS wasn't working! Attached,
On 2011-09-25 PM 11:51, Dave Korn wrote:
before you can compile it from source, and that it might be worth backing up
the .la files just in case this -lstdc++ actually is required somewhere, but
I'd be happier if this could either be fixed in the distro, or if someone
could tell me why these
On 25/09/2011 16:42, jojelino wrote:
lstdc++ is included in postdeps in libtool for some reason.
postdeps=-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname
-lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd
-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt
[ Fixed dup in subject line! ]
On 25/09/2011 16:47, jojelino wrote:
Why we got postdeps instead of postdeps_CXX?
My answer to that crossed in the ether with this post, I'll just make one
further point explicit:
This problem comes from *executing libtool commands*
If a problem arises
On 2011-09-26 AM 12:57, Dave Korn wrote:
I think this is just libtool working normally; $postdeps is the current
dependencies for this particular invocation, and internally it's doing
something like postdeps=${postdeps_${tag}} so it's setting
postdeps=$postdeps_CXX in response to getting
On 2011-09-26 AM 1:00, Dave Korn wrote:
This problem comes from *executing libtool commands*
If a problem arises from executing libtool commands, that usually means that
something the user did in Makefile.am has tricked automake into generating
incorrect libtool commands in the first place,
On 2011-09-24 AM 5:10, jojelino wrote:
The attached is report gprof produced when invoked *id* . as you can
see, format_process_maps consumes 70% of the lifetime(0.5s with
profiling overhead). this is reproducible whenever we do
open('/proc/self/maps').
the problem is, the cost is too expensive.
On 25/09/2011 18:41, jojelino wrote:
The problem is from pango/opentype/libharfbuzz.la
It has .cc source and recognized as needed c++ source file although it
is c source. and cc source is compiled with --tag=CXX
we should teach libtool cc is c source file.
Or upstream should add an
On 25 September 2011 02:07, Dave Korn wrote:
I finally nailed this one down. Stray base relocs against references to
symbols in discarded COMDAT sections remaining in the .eh_frame data cause the
stack unwind lookup to get lost. Sourceware CVS is down right now but I'll be
sending the
On 9/23/2011 4:10 PM, jojelino wrote:
It fixed the relocation problem. but led performance issue :(
$ time id /dev/null
real0m0.141s
user0m0.000s
sys 0m0.000s
Well, the libiconv distributed as an official cygwin package *SHOULD*
not have been built with --enable-relocation,
On 25/09/2011 21:31, Chris Sutcliffe wrote:
On 25 September 2011 02:07, Dave Korn wrote:
I finally nailed this one down. Stray base relocs against references to
symbols in discarded COMDAT sections remaining in the .eh_frame data cause
the
stack unwind lookup to get lost. Sourceware CVS
On Mon, 2011-09-26 at 02:15 +0100, Dave Korn wrote:
The problem is in binutils, and the fact that it generates base relocs for
entries from EH data that should be just ignored.
http://sourceware.org/ml/binutils/2011-09/msg00174.html
contains more detail, if you want to ask more let's do
On 2011-09-26 AM 9:50, Charles Wilson wrote:
Well, the libiconv distributed as an official cygwin package *SHOULD*
not have been built with --enable-relocation, so only a subset of the
relocation code *OUGHT* to be involved -- just enough for any calls to
relocate() to return the passed-in
20 matches
Mail list logo
