@0 () from /usr/bin/cygwin1.dll
#16 0x00401202 in cygwin_crt0 (f=0x401740 main)
at /usr/src/debug/cygwin-1.7.33-1/winsup/cygwin/lib/cygwin_crt0.c:22
#17 0x00401015 in mainCRTStartup ()
at /usr/src/debug/cygwin-1.7.33-1/winsup/cygwin/crt0.c:29
Best,
--
Jean-Pierre Flori
Le Mon, 07 Apr 2014 10:43:12 +0200, Corinna Vinschen a écrit :
On Apr 6 20:20, Jean-Pierre Flori wrote:
[...]
The problem we recently encountered was the following:
in gmp-impl.h, mpn_store (which can be either a macro or a function if
efficient assembly is available, and so is always
Le Mon, 07 Apr 2014 09:14:41 +, Jean-Pierre Flori a écrit :
Looking a little further, it seems the problematic functions are those
directly assembled from assembly code.
That was the case of mpn_store on x86_64.
And when I remove all dllimport, the call to the function mpn_addadd_n
also
Le Mon, 07 Apr 2014 11:39:32 +0200, Corinna Vinschen a écrit :
On Apr 7 09:14, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 10:43:12 +0200, Corinna Vinschen a écrit :
On Apr 6 20:20, Jean-Pierre Flori wrote:
Looking at the exes produced (.libs/t-neg.exe) gives with the
dllimport magic
Le Mon, 07 Apr 2014 09:49:27 +, Jean-Pierre Flori a écrit :
Le Mon, 07 Apr 2014 09:14:41 +, Jean-Pierre Flori a écrit :
Looking a little further, it seems the problematic functions are those
directly assembled from assembly code.
That was the case of mpn_store on x86_64.
And when I
Le Mon, 07 Apr 2014 10:42:13 +, Jean-Pierre Flori a écrit :
Le Mon, 07 Apr 2014 09:49:27 +, Jean-Pierre Flori a écrit :
Le Mon, 07 Apr 2014 09:14:41 +, Jean-Pierre Flori a écrit :
Looking a little further, it seems the problematic functions are those
directly assembled from
Le Mon, 07 Apr 2014 10:43:30 +, Jean-Pierre Flori a écrit :
Note in particular the __nm_ prefix.
It is as advertiserd here: http://www.cygwin.com/ml/cygwin/2002-01/
msg00236.html But when looking at the Cygwin32 produced import lib, I
don't see any nm prefix.
In fact, I see some
Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit :
I'm sorry, but I don't know how this works exactly. The nm prefix is
only added for external references, not for inlined functions, but I
don't know the gory details. You may be better off to ask on the gcc
mailing list.
No
Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a écrit :
On Apr 7 11:50, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit :
I'm sorry, but I don't know how this works exactly. The nm prefix is
only added for external references
Le Mon, 07 Apr 2014 13:28:19 +, Jean-Pierre Flori a écrit :
Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a écrit :
On Apr 7 11:50, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit :
I'm sorry, but I don't know how this works exactly
Le Mon, 07 Apr 2014 16:36:18 +0200, Corinna Vinschen a écrit :
On Apr 7 14:02, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 13:28:19 +, Jean-Pierre Flori a écrit :
Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a écrit :
On Apr 7 11:50, Jean-Pierre Flori wrote:
Le Mon, 07
Dear all,
Le Wed, 02 Apr 2014 11:07:50 +0200, Corinna Vinschen a écrit :
On Apr 2 00:07, Jean-Pierre Flori wrote:
Dear all,
It's amazing to see how well Cygwin64 is going.
Thanks for your hard work.
While preparing the new MPIR release, which will be the first one to
support Cygwin4
Le Wed, 02 Apr 2014 00:07:12 +0200, Jean-Pierre Flori a écrit :
Dear all,
It's amazing to see how well Cygwin64 is going.
Thanks for your hard work.
While preparing the new MPIR release, which will be the first one to
support Cygwin4, we encountered problems running MPIR testsuite when
/EAUoP4ybWOMJ
and the few following post for more details.
For sure, we don't get what's going on here.
Would you have any clue?
Might ld decide for some reason to trim the macro address to 4 bytes
rather than 8?
Best,
--
Jean-Pierre Flori
--
Problem reports: http://cygwin.com/problems.html
FAQ
, and indeed the symbol is here n the shared
lib, but in the end it did not make into the import lib.
What's surprising is that I had no issues with Cygwin32.
So is gcc/g++/ld/binutils configured/behaving differently?
Thanks in advance for your help.
Best,
--
Jean-Pierre Flori
--
Problem reports
Le Thu, 07 Nov 2013 14:20:20 +0100, Corinna Vinschen a écrit :
On Nov 6 22:30, Jean-Pierre Flori wrote:
Dear all,
Le Tue, 27 Aug 2013 23:59:43 -0400, Christopher Faylor a écrit :
On Thu, Jul 25, 2013 at 11:10:48PM -0400, Christopher Faylor wrote:
On Fri, Jul 26, 2013 at 06:16:10AM
Le Wed, 06 Nov 2013 23:04:26 -0500, Charles Wilson a écrit :
On 11/6/2013 5:31 PM, Jean-Pierre Flori wrote:
Is there a canonical way to do so?
dlltool --identify libfoo.a
Thanks that's exactly what I wanted and seems cleaner than using objdump!
--
Problem reports: http://cygwin.com
Le Thu, 07 Nov 2013 14:20:20 +0100, Corinna Vinschen a écrit :
On Nov 6 22:30, Jean-Pierre Flori wrote:
Dear all,
Le Tue, 27 Aug 2013 23:59:43 -0400, Christopher Faylor a écrit :
On Thu, Jul 25, 2013 at 11:10:48PM -0400, Christopher Faylor wrote:
On Fri, Jul 26, 2013 at 06:16:10AM
Dear all,
Le Tue, 27 Aug 2013 23:59:43 -0400, Christopher Faylor a écrit :
On Thu, Jul 25, 2013 at 11:10:48PM -0400, Christopher Faylor wrote:
On Fri, Jul 26, 2013 at 06:16:10AM +0800, JonY wrote:
On 7/26/2013 01:20, Christopher Faylor wrote:
On Fri, Jul 26, 2013 at 12:10:17AM +0800, JonY
Dear all,
Is there a canonical way to do so?
Best,
JP
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Le Thu, 31 Oct 2013 18:04:34 -0400, Larry Hall (Cygwin) a écrit :
On 10/31/2013 4:47 PM, Jean-Pierre Flori wrote:
snip
Commit
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc?
rev=1.286content-type=text/x-cvsweb-markupcvsroot=src would be
exactly what I need.
I'll just
Le Wed, 30 Oct 2013 10:33:13 +0100, Corinna Vinschen a écrit :
On Oct 29 21:22, Jean-Pierre Flori wrote:
Le Tue, 29 Oct 2013 21:19:14 +, Jean-Pierre Flori a écrit :
Le Tue, 29 Oct 2013 16:59:35 -0400, Christopher Faylor a écrit :
If you want this fixed, the easiest way to get
Le Thu, 31 Oct 2013 14:41:14 -0400, Christopher Faylor a écrit :
On Thu, Oct 31, 2013 at 06:27:39PM +, Jean-Pierre Flori wrote:
Le Wed, 30 Oct 2013 10:33:13 +0100, Corinna Vinschen a ??crit??:
On Oct 29 21:22, Jean-Pierre Flori wrote:
Le Tue, 29 Oct 2013 21:19:14 +, Jean-Pierre Flori
Le Fri, 25 Oct 2013 19:53:42 +, Jean-Pierre Flori a écrit :
Le Fri, 25 Oct 2013 17:08:50 +0200, Jean-Pierre Flori a écrit :
This is true both with Cygwin's shipped Python 2.7.x and the one I
built for Sage.
Here is a small snippet of code reproducing the problem:
[Blah python stuff
Le Tue, 29 Oct 2013 19:40:10 +, Jean-Pierre Flori a écrit :
For your info, I was unable to reproduce such a behavior on Cygwin 32 v
1.7.25 installs running on 64 bits Windows 7 both on real hardware and
VirtualBox 4.3...
JP
I went on with further testing and could reproduce the problem
Le Tue, 29 Oct 2013 16:59:35 -0400, Christopher Faylor a écrit :
If you want this fixed, the easiest way to get that to happen is to post
a simple test case which reproduces the problem. That is not the code
snippet that you sent. A real working example would be required.
Sorry about that.
Le Tue, 29 Oct 2013 20:41:07 +, Jean-Pierre Flori a écrit :
Le Tue, 29 Oct 2013 19:40:10 +, Jean-Pierre Flori a écrit :
For your info, I was unable to reproduce such a behavior on Cygwin 32
v 1.7.25 installs running on 64 bits Windows 7 both on real hardware
and VirtualBox 4.3
Le Tue, 29 Oct 2013 21:19:14 +, Jean-Pierre Flori a écrit :
Le Tue, 29 Oct 2013 16:59:35 -0400, Christopher Faylor a écrit :
If you want this fixed, the easiest way to get that to happen is to
post a simple test case which reproduces the problem. That is not the
code snippet that you
reloacte blah.dll at the same address.
Renaming one of the dll (C file and rebuilding) solved the problem.
I assume this is a windows limitations, is that right?
Thanks in advance for your help,
Best,
--
Jean-Pierre Flori
--
Problem reports: http://cygwin.com/problems.html
FAQ
Le Fri, 25 Oct 2013 15:07:34 -0400, Larry Hall (Cygwin) a écrit :
On 10/25/2013 11:08 AM, Jean-Pierre Flori wrote:
I have another quite unrelated question while I'm here:
I recently had trouble because in Sage two DLLs ended up with the same
name and wanted to be loaded at the same time
Le Fri, 25 Oct 2013 17:08:50 +0200, Jean-Pierre Flori a écrit :
This is true both with Cygwin's shipped Python 2.7.x and the one I built
for Sage.
Here is a small snippet of code reproducing the problem:
[Blah python stuff]
from multiprocessing import Pool p = Pool(3)
p.map(anything
Hey,
Thanks for the quick reply.
Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit :
/bin/sh ../libtool --tag=CC--mode=link gcc -std=gnu99 -m64 -O2
-march=corei7-avx -mtune=corei7-avx-o t-bswap.exe t-bswap.o
Uhm, are you sure this arch and tune options aren't the
Le Fri, 21 Jun 2013 11:43:44 +0200, Corinna Vinschen a écrit :
On Jun 21 09:27, Jean-Pierre Flori wrote:
Hey,
Thanks for the quick reply.
Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit :
/bin/sh ../libtool --tag=CC--mode=link gcc -std=gnu99 -m64 -O2
-march=corei7
Hi all,
Here is my experience with a shared version of the library after taking
Corinna's message into account, starting from a clean MPIR tarball (except
for updating the FSF config.sub/guess) without autoreconfing, and using
the Cygwin shipped yasm rather than the one included in MPIR (in
Le Fri, 21 Jun 2013 16:56:23 +, Jean-Pierre Flori a écrit :
And the bad news is: tests still segfault.
I'll also check with the static library now.
With the same changes but trying a static lib I get to the same point as
for the shared one:
* ld doesn't segfault anymore, so tests
Le Fri, 21 Jun 2013 17:06:03 +, Jean-Pierre Flori a écrit :
I'll also check without assembly optimizations, or lowering gcc
optimization level, etc.
So I'm going to try that now.
If i disable ASM routines by passing MPN_PATH=generic to configure, then
(in the static setting at least) most
Le Fri, 21 Jun 2013 17:27:22 +, Jean-Pierre Flori a écrit :
Le Fri, 21 Jun 2013 17:06:03 +, Jean-Pierre Flori a écrit :
I'll also check without assembly optimizations, or lowering gcc
optimization level, etc.
So I'm going to try that now.
If i disable ASM routines by passing
Le Fri, 21 Jun 2013 18:07:00 +, Jean-Pierre Flori a écrit :
Le Fri, 21 Jun 2013 17:27:22 +, Jean-Pierre Flori a écrit :
Le Fri, 21 Jun 2013 17:06:03 +, Jean-Pierre Flori a écrit :
I'll also check without assembly optimizations, or lowering gcc
optimization level, etc.
So I'm
Le Fri, 21 Jun 2013 22:10:15 +, Jean-Pierre Flori a écrit :
Now there is also a x86_64w dir for windows assembly but yasm does not
like its syntax.
I'll be looking into that.
In fact its not yasm which is used I guess.
We should indeed use the *w directories and basically do quite
these issues?
Thanks in advance for your help,
Best,
--
Jean-Pierre Flori
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
40 matches
Mail list logo
