I'm having problems linking a program on Fedora 18 that uses
mingw64-cairo-static because some of the dependencies are not enumerated in the
package and other dependencies are both not enumerated and not available as a
static library.
In particular. pixman-1 is a dependency that is not enumerat
I've been on this mailing list for some time now and use mingw (both the 32-bit
and 64-bit versions) for several production systems. What I would like to see
is not a commitment to a release schedule but a document that clearly states
the commitment to specific principles. For example:
* Can co
compiler version: i686-w64-mingw32-g++ (GCC) 4.7.0 20120322 (Fedora MinGW
4.7.0-2.fc17)
Structures with Bitfields defined as "unsigned int" are not being packed
properly. They are being packed properly if the bitfields are defined with
"uint8_t".
Test program:
#include
#include
struct v1 {
Greetings. I develop computer forensic tools using mingw64.
It's very important that these tools be statically linked.
Would it be possible for the mingw32-libgnurx.noarch and the
mingw64-libgnurx.noarch be expanded to include statically linked versions in
addition to the DLLs?
Thanks,
Sims
Greetings. I develop computer forensic tools using mingw64.
It's very important that these tools be statically linked.
Would it be possible for the mingw32-libgnurx.noarch and the
mingw64-libgnurx.noarch be expanded to include statically linked versions in
addition to the DLLs?
Thanks,
Sims
I'm resending this. I have a work-around, which involves putting PRId64 in a
global variable, but that doesn't seem right. Is there a bug in the #include
files?
Simson
When I #include with mingw64-g++ the PRId64 value is no longer
interpreted correctly.
Here is the test program:
#define _
When I #include with mingw64-g++ the PRId64 value is no longer
interpreted correctly.
Here is the test program:
#define __STDC_FORMAT_MACROS
#include
#include
#include
#include
#include
#include
int main(int argc,char **argv)
{
uint64_t val=1234567890;
printf("%"PRId64"\n",val);
When I #include with mingw64-g++ the PRId64 value is no longer
interpreted correctly.
Here is the test program:
#define __STDC_FORMAT_MACROS
#include
#include
#include
#include
#include
#include
int main(int argc,char **argv)
{
uint64_t val=1234567890;
printf("%"PRId64"\n",val);
>
> Message: 7
> Date: Tue, 10 Jul 2012 22:24:01 +0800
> From: JonY
> Subject: Re: [Mingw-w64-public] problem with static linking -
> libgcc_s_sjlj-1.dll - pthreadGC2.dll not statically linked
> To: mingw-w64-public@lists.sourceforge.net
> Message-ID: <4ffc3b01.7040...@users.sourceforge.net
ssage-ID: <1341860575.674.4.camel@erik-laptop>
> Content-Type: text/plain; charset="UTF-8"
>
> Simson Garfinkel schreef op ma 09-07-2012 om 11:16 [-0400]:
>> When I try to run under wine (where it's easier to do testing), I get this
>> error:
>>
>&
Greetings.
I'm now using mingw-w64 on Fedora Core 17. For those on this list who may
remember me, my goal in using mingw-w64 is to create 64-bit binaries of my open
source computer forensic tools for users who need to run Windows. I'm able to
cross-compile on Linux or Mac or compile natively o
Hi. I am looking for simple instructions that tell me how to compile mingw64 on
a Mac to output 32-bit and 64-bit windows executables. I thought that this
would be straightforward, but I just can't find the documentation in either the
downloads or the website. I know it is possible to do this b
12 matches
Mail list logo
