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 +0000, Jean-Pierre Flori a écrit :
>>
>> > Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a écrit :
>> >
>>
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 :
>>> >
>>&
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
&g
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.
>
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
Le Mon, 07 Apr 2014 10:42:13 +, Jean-Pierre Flori a écrit :
> Le Mon, 07 Apr 2014 09:49:27 +0000, 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
&
Le Mon, 07 Apr 2014 09:49:27 +, Jean-Pierre Flori a écrit :
> Le Mon, 07 Apr 2014 09:14:41 +0000, 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 o
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 (.
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 functi
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 assem
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
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 probl
zsxIWhVx8A/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.c
ould be ok, 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
--
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
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
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
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
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,
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:
>
>> Commit
>> http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc?
>> rev=1.286&content-type=text/x-cvsweb-markup&cvsroot=src would be
Le Thu, 31 Oct 2013 14:41:14 -0400, Christopher Faylor a écrit :
> On Thu, Oct 31, 2013 at 06:27:39PM +0000, 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 T
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 +0000, Jean-Pierre Flori a écrit :
>>
>> > Le Tue, 29 Oct 2013 16:59:35 -0400, Christopher Faylor a écrit :
>> >> If you
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
>&
Le Tue, 29 Oct 2013 20:41:07 +, Jean-Pierre Flori a écrit :
> Le Tue, 29 Oct 2013 19:40:10 +0000, 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 hardwa
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 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 fu
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 th
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 mul
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 wante
p with the same
name and wanted to be loaded at the same time, resulting in a "cannot
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,
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 basi
Le Fri, 21 Jun 2013 18:07:00 +, Jean-Pierre Flori a écrit :
> Le Fri, 21 Jun 2013 17:27:22 +0000, 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 l
Le Fri, 21 Jun 2013 17:27:22 +, Jean-Pierre Flori a écrit :
> Le Fri, 21 Jun 2013 17:06:03 +0000, Jean-Pierre Flori a écrit :
>
>>> I'll also check without assembly optimizations, or lowering gcc
>>> optimization level, etc.
>> So I'm going to try
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 th
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 segf
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 cas
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 ../libto
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 p
any advice to solve 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
39 matches
Mail list logo
