I honestly can't figure out the logic behind the implementation of
fesetnenv. Why is an sse2 instruction outside of the guard? In addition,
why is there a (retrieve parameters) call to the fpu that reenables all the
exception masks? Kai was the last person to make the changefour years
ago...s
Ah, it was -malign-data, not -falign-data no wonder I didn't find it. DUH
-Original Message-
From: Liu Hao [mailto:lh_mo...@126.com]
Sent: Wednesday, August 02, 2017 11:54 AM
To: mingw-w64-public@lists.sourceforge.net; Madalinski Piotr
Subject: Re: [Mingw-w64-public] FW: Section sizes
If I remember correctly, the default alignment for structure starts on a 32
byte boundary, to help prevent data member misalignments with SSE type
instructions. What you are seeing is the result of padding. I add an
integer in the same section
__attribute__((section("test_section"))) test_struct_t
On Thursday, July 22, 2010 09:44:08 Ozkan Sezer wrote:
> On Thu, Jul 22, 2010 at 12:29 PM, Ruben Van Boxem
>
> wrote:
> > Hi,
> >
> > Would it be feasable to provide an extension to the POSIX dirent.h
> > functionality? I found a small patch in some compatibility layer (in git
> > source) that a
On Saturday, July 10, 2010, Ruben Van Boxem wrote:
> Hi,
>
> I have always had trouble with gdb and QtCreator using mingw-w64. Don't know
> if it's a QtCreator issue or just something on my system, but I'd like of
> someone else confirmed this for me. Every time I click "debug application
> (lo
On Mon, 05 Jul 2010 19:29:50 Paarvai Naai wrote:
> Hi Doug,
>
> > Since no headers are required for wmain definitions
> > themselves, the only workaround at this time is to document that when
> > compiling with the g++ compiler,
> >
> > #ifdef __cplusplus
> > extern "C"
> > #endif
> > int wmain(i
On Thu, Jul 1, 2010 at 1:13 PM, Paarvai Naai wrote:
> On Wed, Jun 30, 2010 at 8:59 PM, JonY wrote:
>> GCC probably recognizes main() so it doesn't mangle it.
>>
>> Adding extern "C" is fine, I usually see it accompanying WinMain/wWinMain
>> and wmain in C++ code, just to be explicit.
>
> Okay, th
I'm sorry if I didn't convey my meaning properly, I was interrupted
before I completed.
Here's a better example, while pretty contrived, that shows how the
compiler can optimize away things due to aliasing rules.
What do you expect the output of the printf to be? In the -O2 and
better case, I ca
On Wed, Jun 30, 2010 at 10:20 PM, JonY wrote:
> On 7/1/2010 10:21, Paarvai Naai wrote:
>> As I have mentioned in some recent emails, I am building my mingw-w64
>> toolchain using upstream binutils-2.20.1, gcc 4.5.0, and
>> mingw-w64-v1.0-20100604 snapshot. The host is i386-linux and the
>> target
On Wed, Jun 30, 2010 at 3:32 PM, Paarvai Naai wrote:
> Hi all,
>
> I am trying to build a mingw-w64 cross-compiler using the instructions
> outlined on the web.
>
> Originally I was successful in building a multilib cross-compiler
> using GCC 4.5.0, but now I want to backtrack to GCC 4.4.4. This
On Wed, Jun 23, 2010 at 1:38 PM, Kolb, Jeremy wrote:
> I keep getting compile errors
>
>
>
> $ ./configure --enable-shared --disable-static --enable-cross-compile
> --enable-cross-compile --cross-prefix=x86_64-w64-mingw32- --arch=amd64
> --target-os=mingw32 --enable-w32threads
>
>
>
> make
>
> ...
On Tue, Jun 22, 2010 at 3:24 AM, t66...@gmail.com wrote:
> On 21/06/2010 10:43 PM, Doug Semler wrote:
>>
>> On Sun, Jun 20, 2010 at 11:38 PM, t66...@gmail.com
>> wrote:
>>>
>>> Hello:
>>>
>>> Yesterday I encountered a really weird / od
On Sun, Jun 20, 2010 at 11:38 PM, t66...@gmail.com wrote:
> Hello:
>
> Yesterday I encountered a really weird / oddly gcc bug.
> AFAICT , that gcc-4_5 branch during that last past month that the C++
> was changed.
> Now that the C99 implementation of C++ is in GCC 4.5 branch which indeed
> breaks
On Sun, Jun 20, 2010 at 12:03 PM, Henry N. wrote:
> Hello,
>
> in the 32 bit build environment a simple include like
>
> >>> cat check.c >>>
> #include
> <<< end check.c <<<
>
> works with that command line:
>
> i686-pc-mingw32-gcc -c check.c
>
> With the 64 bit toolchain (20100604_seze
On Wed, Jun 16, 2010 at 10:27 AM, Ruben Van Boxem
wrote:
> 2010/6/16 Ruben Van Boxem
>>
>> 2010/6/16 JonY
>>>
>>> On 6/16/2010 18:51, Ruben Van Boxem wrote:
> Either way, without more of the config log it's difficult to tell why
> it's trying to use a half-msvc toolchain.
>
ore the error I got from make check? I used MSYS
> to build MPFR using "./configure --disable-shared --host=x86_64-w64-mingw32
> --with-gmp-build=/home/chris/gmp-5.0.1" and make check ran with no errors.
>
> Regards
> Chris Saunders
>
> ------
On Thu, Jun 10, 2010 at 4:10 PM, Chris Saunders wrote:
> The error was:
>
> n = 97327602995864283868534915224192610...(cut this because it was very
> long)
>
> n was destroyed, but perfpow_p still believes n is a perfect power
>
> This application has requested the Runtime to terminate it in an un
On Thu, Jun 10, 2010 at 3:25 PM, Chris Saunders wrote:
> I have installed MinGW 64-bit and am attempting to get MSYS to work with
> it. I attempted to configure GMP-5.0.1. Here is the command line I used to
> run configure and the first few lines of output (My OS is Windows 7
> 64-bit.):
>
> $ .
On Thu, Jun 10, 2010 at 9:17 AM, Doug Semler wrote:
> On Thu, Jun 10, 2010 at 3:36 AM, Mook wrote:
>> On 2010-06-09 3:00 AM, Hradec wrote:
>>> I notice this problem when trying to build openexr package with the
>>> automated build mingw64...
>>
>>&
On Thu, Jun 10, 2010 at 3:36 AM, Mook wrote:
> On 2010-06-09 3:00 AM, Hradec wrote:
>> I notice this problem when trying to build openexr package with the
>> automated build mingw64...
>
>> Notice the last path in the "libraries" searchpath...
>> "/Users/jchesney/mingw..."
> That is an artifact of
On Tue, Jun 1, 2010 at 10:13 PM, Hradec wrote:
> also, by doing a grep _eLut, this is the result:
>
> hradec$ grep '_eLut'
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/./build/mingw/ilmbase-1.0.1/lib/*
>
> Binary file
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OI
Posted. sprintf now strcpy for the calls...
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-p
On Sun, May 16, 2010 at 4:52 PM, Wolfgang Glas wrote:
> On 2010-05-16 22:43, Ozkan Sezer wrote:
>> On Sun, May 16, 2010 at 11:03 PM, Wolfgang Glas
>> wrote:
>
> [snip]
>
>> For the next builds, I will include this, thanks.
>> BTW, same effect can also be accomplished by
>> adding a format string
2010/5/14 Tony Theodore :
> 2010/5/15 Mario Rodríguez :
>> Hi,
>>
>> I want to use *MKL*`s lapack & BLAS in my *mingw* project.
>>
>> I use this libraries for 32 bits linking: mkl_intel_c_dll.lib,
>> mkl_intel_thread_dll.lib, mkl_core_dll.lib. In 32b arquitecture, it´s
>> enought adding this files
On Sat, May 8, 2010 at 10:52 PM, t66...@gmail.com wrote:
> On 9/05/2010 3:53 AM, Doug Semler wrote:
>>
>> If you want to see the actual compile command, either configure with
>> --disable-silent-rules
>>
>> or
>>
>> make V=1 ...
>>
>
>
>> In the build log, gcc command line is silenced.
>> CC libavformat/utils.o
>>
>> Is this a bug in the binutils or gcc-4.5 branch?
>
> You really should provide the actual compiler command.
>
If you want to see the actual compile command, either configure with
--disable-silent-rules
or
mak
On Tue, May 4, 2010 at 11:52 AM, t66...@gmail.com wrote:
> On 4/05/2010 11:49 PM, Ozkan Sezer wrote:
>> On Tue, May 4, 2010 at 4:46 PM, t66...@gmail.com wrote:
>>
>>> On 4/05/2010 11:17 PM, Ozkan Sezer wrote:
>>>
On Tue, May 4, 2010 at 4:00 PM, t66...@gmail.com
wrote:
>
Yo
On Tue, Apr 27, 2010 at 1:37 AM, Mario Emmenlauer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Hi Doug,
>
> On 04/26/2010 03:37 PM, Doug Semler wrote:
>> On Mon, Apr 26, 2010 at 6:25 AM, Mario Emmenlauer
>> wrote:
>>>> On 04/25/20
On Mon, Apr 26, 2010 at 6:25 AM, Mario Emmenlauer wrote:
>> Hi Kai,
>>
>> On 04/25/2010 04:48 PM, Kai Tietz wrote:
>>> 2010/4/25 Mario Emmenlauer :
Hi all,
I fail to build a canadian cross with mingw Revision: 2263 (current
trunk).
The error happens during "make
On Wed, Apr 21, 2010 at 3:30 PM, NightStrike wrote:
> On Wed, Apr 21, 2010 at 11:41 AM, Doug Semler wrote:
>> Well, it looks like the compiler may be being built with host !=
>> target... In other words it wasn't bootstrapped and has been
>> configured as a cross comp
2010/4/21 Ozkan Sezer :
> On Wed, Apr 21, 2010 at 11:38 AM, 罗勇刚(Yonggang Luo)
> wrote:
>> E:/CI/Tools//phoenix/mingw32/bin\gcc.exe -mno-cygwin -shared -s
>> build\temp.win32-2.6\Release\dulwich\_objects.o
>> build\temp.win32-2.6\Release\dulwich\_objects.def
>> -LE:\CI\tools\Python\libs -LE:\CI\too
On Wed, Apr 21, 2010 at 6:05 AM, Sisyphus wrote:
>
> - Original Message - From: "Doug Semler"
> To: "Sisyphus"
> Cc: "mingw64"
> Sent: Wednesday, April 21, 2010 2:45 AM
> Subject: Re: [Mingw-w64-public] [Repost] LIBRARY_PATH environment v
Oops, should have qualified that - i meant the output during
compileIOW make CFLAGS=-v
Sorry
On Tue, Apr 20, 2010 at 5:41 AM, Sisyphus wrote:
>
> - Original Message - From: "Doug Semler"
> To: "Sisyphus"
> Cc: "mingw64"
> Sent:
Can you post the output of gcc -v so I can see what the search path
actually ends up being on that link attempt ( without the -L param
that is).
Thx
On Sunday, April 18, 2010, Sisyphus wrote:
>
> - Original Message - From: "Doug Semler"
>
>
> With mingw64, is
On Sun, 18 Apr 2010 10:52:26 Sisyphus wrote:
> Hi,
>
> I asked about this on 14 Oct last year
> (http://sourceforge.net/mailarchive/forum.php?thread_name=A00A469F7EBE44199
> 92A92CBC29D03F5%40desktop2&forum_name=mingw-w64-public) and didn't get any
> replies - so I thought I'd ask again and see wh
2010/4/13 Doug Semler :
> I have to run but I quickly looked at it and it looks like there may
> be an parentheses around %1 in InterlockedIncrement64 and
> InterlockedDecrement16 inline declarations in winnt.h which are being
> expanded to ((%rcx)) in the assembly (which is incorr
I have to run but I quickly looked at it and it looks like there may
be an parentheses around %1 in InterlockedIncrement64 and
InterlockedDecrement16 inline declarations in winnt.h which are being
expanded to ((%rcx)) in the assembly (which is incorrect).
Doug
2010/4/13 Hervé Pagès :
> Hi Kai,
>
> Kai Tietz wrote:
>> 2010/4/13 Hervé Pagès :
>>> Hi,
>>>
>>> While trying to compile samtools 0.1.7a
>>> (http://samtools.sourceforge.net/) with the x86_64-w64-mingw32-gcc
>>> compiler (on a Windows Server 2008 R2 Enterprise (64-bit) box),
>>> I get the followin
On Apr 9, 2010, at 15:51, NightStrike wrote:
> On Mon, Oct 26, 2009 at 10:35 AM, Kai Tietz
> wrote:
>> 2009/10/26 NightStrike :
>>> On Thu, Sep 10, 2009 at 3:40 AM, Kai Tietz
>>> wrote:
2009/9/10 GCC G++ :
> Since dlltool delay import has been add in the newest
> binutils-2.2
On Thu, 25 Mar 2010 08:36:19 Dmitrijs Ledkovs wrote:
> After spending a lot of time in Debian chroot's used for building
> package I thought that there must be an easier way of building
> circular dependencies.
>
> The cunning feature is to build --with-sysroot & --with-build-sysroot.
> Binutils &
Is it me or did HJ's commit 157665 completely break w64-mingw32 builds
(it really trashes the stdlib.h during fixincludes)?
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling,
:)
Sent from my iPod
On Mar 24, 2010, at 21:14, "Sisyphus" wrote:
>
> - Original Message ----- From: "Doug Semler"
>
>
>> Actually, the command that's failing is:
>>
>> x86_64-w64-mingw32-ar t
>> "/c/_64/comp/gsl-1.14/blo
On Wed, Mar 24, 2010 at 2:24 PM, Doug Semler wrote:
> On Wed, Mar 24, 2010 at 1:26 PM, JonY wrote:
>> On 3/24/2010 20:15, Sisyphus wrote:
>>> Hi,
>>>
>>> I've posted to gsl-bugs about this ... without success. I'm not even sure
>>> that i
On Wed, Mar 24, 2010 at 1:26 PM, JonY wrote:
> On 3/24/2010 20:15, Sisyphus wrote:
>> Hi,
>>
>> I've posted to gsl-bugs about this ... without success. I'm not even sure
>> that it's a gsl bug - there's a thread at
>> http://www.mail-archive.com/bug-libt...@gnu.org/msg00374.html where the
>> error
Noticed a typo when configuring the leading underscores in the crt:
configuration output says:
configure:5078: checking whether to disable leading underscores
configure:5103: result: no
when the --disable-leading-underscores is passed (and result: yes when
not passed). In other words, "whether
On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer wrote:
> On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz wrote:
>>
>> It is the use of USER, right? This is fine at the moment, but I
>
> Yes, the USER_H mechanism.
>
>> dislike it as we then have to maintain changes of gcc within our
>> headers. What's abo
On Tue, Mar 23, 2010 at 9:02 AM, Ozkan Sezer wrote:
> On Tue, Mar 23, 2010 at 3:00 PM, NightStrike wrote:
>> On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer wrote:
>>> I can't understand, how can a fixinclude fix this thing??
>>
>> As I understand it, our headers are already being fixincluded. It's
On Tue, Mar 23, 2010 at 9:00 AM, NightStrike wrote:
> On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer wrote:
>> I can't understand, how can a fixinclude fix this thing??
>
> As I understand it, our headers are already being fixincluded. It's
> fixincludes that causes GCC to override us. That means
On Mon, Mar 22, 2010 at 3:11 PM, Kai Tietz wrote:
> 2010/3/22 Doug Semler :
>> On Mon, Mar 22, 2010 at 12:08 PM, Doug Semler wrote:
>>> On Mon, Mar 22, 2010 at 11:32 AM, Kai Tietz wrote:
>
>> Caveats that I see (not really on the binutils side but still there
>>
On Mon, Mar 22, 2010 at 3:39 PM, Kai Tietz wrote:
> 2010/3/22 Doug Semler :
>> On Sun, Mar 21, 2010 at 8:31 PM, NightStrike wrote:
>>> On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler wrote:
>
> Well, in fact is this entry-point a no issue. By a recent patch, ld is
>
On Sun, Mar 21, 2010 at 8:31 PM, NightStrike wrote:
> On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler wrote:
>> On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
>>> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler wrote:
>>> > Yeah, I kinda decided to give up on multili
On Mon, Mar 22, 2010 at 12:08 PM, Doug Semler wrote:
> On Mon, Mar 22, 2010 at 11:32 AM, Kai Tietz wrote:
>> Hello,
>>
>> I prepared a patch which supports underscoring option for ld for
>> x64/x86 pe-coff targets. I post it first here, so that possibly Doug
>>
On Mon, Mar 22, 2010 at 11:32 AM, Kai Tietz wrote:
> Hello,
>
> I prepared a patch which supports underscoring option for ld for
> x64/x86 pe-coff targets. I post it first here, so that possibly Doug
> could comment on it.
>
> I have to add for it some additional test-cases in testsuite before
> p
On Sun, Mar 21, 2010 at 8:51 PM, NightStrike wrote:
> On Sun, Mar 21, 2010 at 7:41 PM, Doug Semler wrote:
>> On Sun, 21 Mar 2010 19:22:48 NightStrike wrote:
>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer wrote:
>>> > For some reason yet unknown to me, the g
On Sun, 21 Mar 2010 19:22:48 NightStrike wrote:
> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer wrote:
> > For some reason yet unknown to me, the gcc-provided headers
> > have priority over the system provided headers and float.h is
> > especially problematic: Not installing or deleting it is the s
On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler wrote:
> > Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The
> > target DLLs for things like libstdc++, etc are installed into the
> > completely wrong
fort. And
> >> this will all be fixed for 4.6, o we won't need to worry about it.
> >>
> >> If users really want it, though, I can rework things to exclude 32-bit
> >> entirely. It's just a little messy in Makefile.am.
> >>
> >> O
On Sun, 21 Mar 2010 13:21:12 NightStrike wrote:
> Well, this is a problem, yes. It only affects the multilib builds,
> though, which don't really work anyway without a lot of effort. And
> this will all be fixed for 4.6, o we won't need to worry about it.
>
> If users really want it, though, I c
Quick question:
Are you sure you want to disable the leading underscore on the 32bit side with
the --disable-leading-underscore and multilib? Looking at it (without testing
it, that is), it doesn't seem to me that it is appropriate...
---
>
> Do you mean that your toolchain is multilib with 32-bit as the
> primary? Otherwise, I don't see how a 32-bit chain builds a 64-bit
> lib.
>
Yes, of course...
binutils compiled with --target=i686-w64-mingw32
--enable-targets=i686-w64-mingw32,x86_64-w64-mingw32
gcc configured appropriately f
Found a bug in the build system of the crt when using a 32 bit (ie.
i386-w64-mingw32) toolchain to build the 64 bit crt --- the correct
--as-flags are not passed to dlltool for the 64 bit libraries. This
means that when dlltool compiles its generated assembler, the
assembler, if it picks up the 32
It would help to know how redc.s is built (directly compiled from the
assembler it looks like...), and how the file is linked...
if it is hand assembly, did you remember run as with the -g option so
that source information is saved in the object?
If it is linked in a dll, did you try to load the
On Mon, Mar 15, 2010 at 4:47 AM, Kai Tietz wrote:
> Hello David,
>
> The problem you've shown is reasoned by using a gdb built without
> libexpat. You can download a more current version from our SF file
> sections (see Tools), which is build with libexpat. If gdb isn't built
> by it, debugging in
On Sun, 07 Mar 2010 14:59:50 Kai Tietz wrote:
> 2010/3/7 Doug Semler :
> > On Thu, 04 Mar 2010 17:20:07 Jim Michaels wrote:
> >> in MSVC,
> >> __int64 x=12345678901234567i64;
> >>
> >> point 1: this type __int64 doesn't require me to #include to
On Thu, 04 Mar 2010 17:20:07 Jim Michaels wrote:
> in MSVC,
> __int64 x=12345678901234567i64;
>
> point 1: this type __int64 doesn't require me to #include to
> define it. in mingw and mingw-w64, one must #include . why?
>
> point 2: there are also __int32 __int16 and __int8 types.
If I rememb
On Sun, 21 Feb 2010 09:56:46 JonY wrote:
> On 2/21/2010 21:35, NightStrike wrote:
> > On Fri, Jan 15, 2010 at 8:32 AM, Chris Sutcliffe
wrote:
> >> Hi All,
> >>
> >> Is it possible for i686-w64-mingw and x86_64-w64-mingw32 to coexist in
> >> the same directory? I realize the majority of the dire
On Sat, Feb 20, 2010 at 9:53 AM, NightStrike wrote:
> I changed that at one point. I forget why :(
>
> I'll look into it and change it back if that makes the most sense.
>
> On Sat, Feb 20, 2010 at 8:46 AM, Doug Semler wrote:
>> I notice that the crt .o and .a file
I notice that the crt .o and .a files are installed as scripts rather
than data, which causes their file mode to be installed as executable
(in a cross compile environment)
Is there a specific reason for this? It seems to me that files such
as crt32_SCRIPTS, lib32_SCRIPTS, etc should actually be
68 matches
Mail list logo
