On 5/21/2016 10:15 PM, Eliot Moss wrote:
[snip]
>> You surely tried this already: strip --strip-unneeded or --strip-debug?
>
> A helpful thought, but no, it did not occur to me. Getting pypy to run
> that extra step in the middle of its build would involve hacking its
> process
> of generating a
(Sorry for top post: meant to send this to the list
in the first place ... EM)
Forwarded Message
Subject: Re: Help debugging a dll issue
Date: Sat, 21 May 2016 23:14:09 -0400
From: Eliot Moss
Reply-To: m...@cs.umass.edu
To: Duncan Roe
On 5/21/2016 10:58 PM, Duncan Roe wrote
On Sat, May 21, 2016 at 07:30:37PM -0400, Eliot Moss wrote:
> On 5/19/2016 10:54 PM, Eliot Moss wrote:
> >Dear Cygwin friends --
> >
> >I am trying to get pypy to build under cygwin. (It used to do so, but
> >has not been maintained.) I am very close, but there is something quite
> >odd happening
On 5/21/2016 9:45 PM, René Berber wrote:
On 5/21/2016 6:30 PM, Eliot Moss wrote:
[snip]
I used binary search, eliminating .o files from the .dll on the thought
that it was either a particular .o file that was leading to a problem,
or possibly the overall size (this is a huge link!). I found th
On 5/21/2016 6:30 PM, Eliot Moss wrote:
[snip]
> I used binary search, eliminating .o files from the .dll on the thought
> that it was either a particular .o file that was leading to a problem,
> or possibly the overall size (this is a huge link!). I found that a .dll
> with 58725 section 1 symbo
On 5/19/2016 10:54 PM, Eliot Moss wrote:
Dear Cygwin friends --
I am trying to get pypy to build under cygwin. (It used to do so, but
has not been maintained.) I am very close, but there is something quite
odd happening when trying to access the large dll that the system builds:
the first call
On 5/20/2016 9:36 AM, Duncan Roe wrote:
On Fri, May 20, 2016 at 08:02:20AM -0400, Eliot Moss wrote:
On 5/20/2016 7:26 AM, Duncan Roe wrote:
Hi Eliot,
Do you know what is the name of the totally different symbol? (maybe from nm -D)
Yes -- I have been using nm and objdump to examine the relev
On Fri, May 20, 2016 at 08:02:20AM -0400, Eliot Moss wrote:
> On 5/20/2016 7:26 AM, Duncan Roe wrote:
>
> >Hi Eliot,
> >
> >Do you know what is the name of the totally different symbol? (maybe from nm
> >-D)
>
> Yes -- I have been using nm and objdump to examine the relevant files. The
> dll
> i
On 5/20/2016 7:26 AM, Duncan Roe wrote:
Hi Eliot,
Do you know what is the name of the totally different symbol? (maybe from nm -D)
Yes -- I have been using nm and objdump to examine the relevant files. The dll
is called libpypy-c.dll. The symbol I want to bind to is pypy_main_startup, and
i
On Fri, May 20, 2016 at 06:37:57AM -0400, Eliot Moss wrote:
> On 5/19/2016 11:28 PM, Sam Habiel wrote:
> >I had trouble with dlopen in Cygwin, where it did not behave intuitively. In
> >my case, I was
> >dlopening libicu and friends. If you search using my name on the Cygwin
> >mailing list, you
On 5/19/2016 11:28 PM, Sam Habiel wrote:
I had trouble with dlopen in Cygwin, where it did not behave intuitively. In my
case, I was
dlopening libicu and friends. If you search using my name on the Cygwin mailing
list, you should be
able to find out how I resolved the issue. I don't recall exac
Dear Cygwin friends --
I am trying to get pypy to build under cygwin. (It used to do so, but
has not been maintained.) I am very close, but there is something quite
odd happening when trying to access the large dll that the system builds:
the first call into that dll goes wild and causes a segf
12 matches
Mail list logo
