On 9/26/2011 5:15 AM, Yaakov (Cygwin/X) wrote:
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
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 stri
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
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. Sourcewa
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-reloc
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 at
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 expl
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 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-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 --
[ 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 fr
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 -lmsvcr
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 libs
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 libs
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:
http://lists.freedesktop.org/archives/cairo/2009
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 sub
$ 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
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
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
20 matches
Mail list logo
