Here is the patch jon_y asked for. It contains 1 change:
- Add _libm_dummy.c to lib32_libmoldname_a_SOURCES and
lib64_libmoldname_a_SOURCES so the archive isn't empty. This is
necessary to support tools that can't process empty archives (eg
flexlink on cygwin).
I'm unable to produce the ma
Thank you for your explaination.
Patch is ok.
Thanks
Kai
Am 13.07.2013 20:03 schrieb "dw" :
>
> > Point 3 should not force none-inline version. Please expain why you
> > think that is required.
>
> While I removed the inline asm from these 3 routines, the routines
> themselves are still __CRT_INL
> Point 3 should not force none-inline version. Please expain why you
> think that is required.
While I removed the inline asm from these 3 routines, the routines
themselves are still __CRT_INLINE. And the routines they call are
either __CRT_INLINE or __MINGW_INTRIN_INLINE. If you examine th
On Thu, Jul 4, 2013 at 8:40 PM, Dongsheng Song wrote:
> δΊ 2013/7/4 17:18, Kai Tietz ει:
>> 2013/7/4 Dongsheng Song :
>>> On 2013/7/4 4:49, Earnie Boyd wrote:
On Wed, Jul 3, 2013 at 12:28 PM, Dongsheng Song wrote:
> On Thu, Jul 4, 2013 at 12:09 AM, Kai Tietz
> wrote:
>> That is a
Hi
patch looks ok to me. Beside one nit.
Point 3 should not force none-inline version. Please expain why you think
that is required.
Kai
Am 13.07.2013 15:11 schrieb "dw" :
> 1) Move these functions to intrin-impl.h:
>
> __readfsbyte, __readfsword, __readfsdword
> __writefsbyte, __writefsword, _
On Sat, Jul 13, 2013, Baruch Burstein wrote:
> On Wed, Jul 10, 2013 at 5:30 PM, Jon wrote:
> > But "interpreting" or "implying" or "inferring" is not useful. Explicit
> > clarification
> > from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why
> > this hasn't
> > happened is th
1) Move these functions to intrin-impl.h:
__readfsbyte, __readfsword, __readfsdword
__writefsbyte, __writefsword, __writefsdword
__readgsbyte, __readgsword, __readgsdword, __readgsqword
__writegsbyte, __writegsword, __writegsdword, __writegsqword
2) Update inline asm code:
*a) Change __write* s
On Wed, Jul 10, 2013 at 5:30 PM, Jon wrote:
>
>
...SNIP...
>
But "interpreting" or "implying" or "inferring" is not useful. Explicit
> clarification
> from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why
> this hasn't
> happened is that both already have too much on their
Erik van Pienbroek schreef op do 23-05-2013 om 23:29 [+0200]:
> Hi,
>
> During review of one of our Fedora packages we noticed an unexpected
> change in behavior in recent mingw-w64 trunk snapshots. We noticed that
> several libraries which were built against recent mingw-w64 trunk
> snapshots sud
On Sat, Jul 13, 2013, Ray Donnelly wrote:
> > - package gnustep which will help test the objc toolchain
>
> Have you seen http://www.cocotron.org/ too?
I hadn't. It's interesting but at the same time, I'm a bit worried
because they mention patching ld and gcc. =/
In any case, I'll have a look at
> - package gnustep which will help test the objc toolchain
Have you seen http://www.cocotron.org/ too?
On Sat, Jul 13, 2013 at 12:22 PM, Adrien Nader wrote:
> Hi,
>
> On Fri, Jul 12, 2013, Jon wrote:
>> On Fri, 12 Jul 2013 19:43:04 +0200
>> Kai Tietz wrote:
>> > a) yes, b) yes (we need people
Hi,
On Fri, Jul 12, 2013, Jon wrote:
> On Fri, 12 Jul 2013 19:43:04 +0200
> Kai Tietz wrote:
> > a) yes, b) yes (we need people in charge for that and doing this
> > reliable), c) yes, we are actual in discussion with mingw-builds
> > venture to go together (and/or co-operate more closely).
> >
12 matches
Mail list logo
