Thanks for the detailed explanation.
I now realize that there are many different values that are
similarly affected.
Cheers,
Rob
On Wed, May 8, 2024 at 1:09 AM LIU Hao wrote:
> 在 2024-05-07 19:05, sisyphus 写道:
> > Although I often test 32-bit gcc on Windows, I don't actually r
Hi,
Demo program:
/*** DBL_MAX.c ***/
#include
#define MY_DBL_MAX 0x1.fp+1023
int main(void) {
if(MY_DBL_MAX == 1.7976931348623157e+308) printf("OK1\n");
else printf("%a\n%a\n", MY_DBL_MAX, 1.7976931348623157e+308);
return 0;
}
/
Given that I have, in my path, a mingw-w64 port of version 13.2.0 of
gcc.exe, is there a gcc command that I can run to determine whether this
gcc uses UCRT ?
I thought that running "gcc --version" would do that - and it does for
Brecht Sanders builds ... but niXman's UCRT and MSVCRT builds both re
On Sat, Jul 15, 2023 at 12:42 AM LIU Hao wrote:[snip
> [snip]
> Looks like our `fpclassify()` doesn't handle `__float128`:
Thank you for explaining.
Is there some action I should take in order to improve the chances of this
being fixed ?
The problem arose in relation to the compilation of a pe
Hi,
I've tested this with 64-bit gcc-11.3.0 and (both 32-bit and 64-bit)
gcc-13.1.0 nad am seeing the same brokenness.
The demo:
//
/* isfinite.c */
#include
#include
#include
int main(void) {
__float128 x = 1.0Q;
if(isfinite(x)) printf("OK\n");
else printf("NOT ok\n");
On Sat, Apr 29, 2023 at 8:36 PM LIU Hao wrote:
> 在 2023-04-29 17:20, sisyphus 写道:
> > Hi,
> > If I fix the "shr" nameclash (by renaming "shr") I still get "invalid
> use of register" errors in
> > relation to assembler directives that don
Hi,
If I fix the "shr" nameclash (by renaming "shr") I still get "invalid use
of register" errors in relation to assembler directives that don't involve
any symbols from cpoly.c
That is, I think there's something else happening as well.
Would you like more detail about this ?
In any case, the "-m
On Fri, Apr 28, 2023 at 1:36 AM LIU Hao wrote:
>
> Anyway `-masm=att` will solve this issue.
>
Indeed it does.
Thank you.
Cheers,
Rob
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/li
Hi,
I have 2 snapshots of gcc-13.0.1.
One was built by LH_Mouse, the other by Brecht Sanders (https://winlibs.com
).
LH_Mouse's compiler is tripping over some code that Sanders' build handles
without issue.
Attached are 2 files (cpoly.c and cpoly.h) taken from the source of a perl
module named PDL
On Tue, Apr 18, 2023 at 8:26 PM Martin Storsjö wrote:
The most robust way forward would, IMO, be to just stop trying to redefine
> it, and stop undeffing/overriding the system's setjmp() function, since
> that's what it is going to be using in the end anyway.
Yes - and the elegance and simplici
On Mon, Apr 17, 2023 at 8:56 PM Martin Storsjö wrote:
> On Mon, 17 Apr 2023, sisyphus wrote:
>
> > On Mon, Apr 17, 2023 at 1:02 AM Martin Storsjö wrote:
> [snip]
>
> As you can see, the aim is, for 32-bit builds only, to:
> > # define setjmp(x) _setjmp(x)
> >
&g
On Mon, Apr 17, 2023 at 1:02 AM Martin Storsjö wrote:
> mingw-w64 never defined USE_NO_MINGW_SETJMP_TWO_ARGS. Do the perl sources
> define it?
>
Yes - and for quite a long time. (But only for 32-bit builds of course.)
https://github.com/Perl/perl5/blob/blead/dist/threads/threads.xs begins with
Hi,
I was having difficulty building threaded 32-bit perl using gcc-13.0.1.
No problem building threaded 64-bit perl with gcc-13.0.1.
Also no problem building threaded perls (both 32-bit and 64-bit) with
gcc-12.2.0 or earlier.
I tried fixing the issue by making a few modifications to dist/threads.
Now testing fine for me.
Thanks,
Rob
On Wed, Apr 12, 2023 at 5:40 PM LIU Hao wrote:
> 在 2023/4/12 09:56, sisyphus 写道:
> > Thanks LIU.
> > No urgency, from my point of view.
> > When the amended version hits https://gcc-mcf.lhmouse.com/, I'll
> download
> > i
Thanks LIU.
No urgency, from my point of view.
When the amended version hits https://gcc-mcf.lhmouse.com/, I'll download
it and try it out.
Cheers,
Rob
On Tue, Apr 11, 2023 at 11:24 PM LIU Hao wrote:
> 在 2023-04-11 21:14, LIU Hao 写道:
> > It's because `__emutls_get_address()` returns two distin
Hi,
The demo program:
#
#include
#include
#include
#include
void *foo( void *ptr );
int main(void) {
pthread_t thread1;
char *message1 = "precision in thread1:";
int iret1;
if(mpfr_buildopt_tls_p()) printf("mpfr was built with TLS support\n");
el
On Tue, Jun 14, 2022 at 1:57 AM LIU Hao wrote:
> ...
> I am putting this on hold for a while, until I have some time to look into
> it.
>
>
I think the different results can also be expressed as:
(1/3) ^ 5 produces 3f70db20a88f4695
1 / (3 ^ 5) produces 3f70db20a88f4696
The latter is a far less e
On Fri, Jun 3, 2022 at 2:16 PM LIU Hao wrote:
> ...
> I still consider it a bad idea to declare functions with the same names as
> standard ones. Why not
> rename it to `my_inet_ntop` for example? it would be much less error-prone.
>
>
Yes - there's wisdom in what you say.
However, "acting wisel
On Fri, Jun 3, 2022 at 12:28 AM sisyphus wrote:
> On Thu, Jun 2, 2022 at 10:47 PM LIU Hao wrote:
>
>> 在 2022/6/2 20:37, sisyphus 写道:
>> > On Thu, Jun 2, 2022 at 12:28 PM sisyphus wrote:
>>
>
>
> What's the error? Is it caused by re-declaration w
On Thu, Jun 2, 2022 at 10:47 PM LIU Hao wrote:
> 在 2022/6/2 20:37, sisyphus 写道:
> > On Thu, Jun 2, 2022 at 12:28 PM sisyphus wrote:
> >
> >> Hi,
> >> In the Perl source, we hard code our own implementation of inet_ntop()
> >> and inet_pton().
> >
On Thu, Jun 2, 2022 at 12:28 PM sisyphus wrote:
> Hi,
> In the Perl source, we hard code our own implementation of inet_ntop()
> and inet_pton().
> This results in a fatal compile-time error if the Windows (ws2tcpip.h)
> implementation is also present.
>
> I'm theref
Hi,
In the Perl source, we hard code our own implementation of inet_ntop() and
inet_pton().
This results in a fatal compile-time error if the Windows (ws2tcpip.h)
implementation is also present.
I'm therefore looking for a portable way of detecting whether the compiler
is a mingw-w64 one && the W
On Tue, Mar 8, 2022 at 3:18 AM Stephen Kitt wrote:
>
> You can ask GCC itself:
>
> $ x86_64-w64-mingw32-gcc -E -include windows.h -
> <<<"__MINGW64_VERSION_MAJOR" | tail -n 1
> 9
>
>
Nice idea - works fine in a bash shell (cygwin and msys2) for me, but not
in a cmd shell.
With cmd.exe, there's no
On Mon, Mar 7, 2022 at 6:27 PM Gisle Vanem wrote:
>
> > A command that displays only the value of __MINGW64_VERSION_MAJOR would
> > probably suffice.
>
> Some .bat-file with:
>
> setlocal
> set %find=%WinDir%\system32\find.exe
> if %MINGW32%. == . set MINGW32=f:\MinGW32\TDM-gcc
>
> type "%MINGW32
Hi,
Is there a simple command that I can run to see the (mingw-w64) runtime
version number - something akin to "gcc -dumpversion" ?
A command that displays only the value of __MINGW64_VERSION_MAJOR would
probably suffice.
Cheers,
Rob
___
Mingw-w64-publ
On Fri, Aug 27, 2021 at 3:56 PM Biswapriyo Nath
wrote:
> I don't know what the issue is. But to compile perl with mingw-w64
> toolchain, I have to patch some files. You can see the changes here
> https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-perl.
>
>
I'm dealing with the issue th
On Thu, Aug 26, 2021 at 10:12 PM Biswapriyo Nath
wrote:
> The output from v9 matches with the output of same code compiled with
> MSVC.
>
Thank you - I've since checked that, and found it to be so. (Not that I
doubted you ;-)
Interestingly, perl builds fine for me straight out of the box with M
Hi,
The following script demonstrates a change between runtime version 8 and
runtime version 9.
/***/
#define WIN32_LEAN_AND_MEAN
#include
#ifndef _WINSOCKAPI_
#define NO__WINSOCKAPI_YET
# include
# include
#endif
#include
int main(void) {
#ifdef NO__WIN
On Mon, Jun 14, 2021 at 1:33 PM Liu Hao wrote:
> 在 6/11/21 12:26 PM, sisyphus 写道:
>
[snip]
> The loss of accuracy itself with sin() annoys me a little - mainly because
> > I'm seeing it as being unnecessary. (Perhaps I'm being unfair. Is it
> > actually necessa
On Fri, Jun 11, 2021 at 1:22 AM LRN wrote:
> On 10.06.2021 10:03, Liu Hao wrote:
> [snip]
> > Before doing that, I would like to ask, does the inaccuracy really
> matter?
>
> I always assumed that when dealing with floating-point math there's no
> such
> thing as "yielding precisely this number".
Hi,
The demo:
##
/* trig.c */
#define __USE_MINGW_ANSI_STDIO 1
#include
#include
#include
int main( int argc, char *argv[] ) {
double s1 = sin(strtod(argv[1], NULL));
double s2 = sin(3.1415926535897931);
printf("gcc version: %d.%d.%d\n", __GNUC__, __GNUC_MINOR__,
__GNUC_PATCH
On Sat, May 8, 2021 at 11:13 PM Zach Bacon wrote:
> Because of trademarks, if it has mingw in the name, then it could
> constitute as a violation, regardless if it has -w64 in it or not.
>
Yeah, but that needs to be tested in a court first.
Keith has implied that it's "fait accompli", and that's
On Sat, May 8, 2021 at 9:28 PM Joachim Wuttke
wrote:
> Keith Marshall argues at https://stackoverflow.com/a/62865466/1017348
> that you are doing illegal things, and that perhaps I am rendering
> myself culpable by recommending use of your software.
>
> What is your position on this?
>
>
:-))
On Tue, Sep 22, 2020 at 9:28 PM wrote:
> [snip]
>
> yes, I plan to continue releasing compiler builds but they will be
> hosted here: https://github.com/niXman/mingw-builds/releases
Great news !!
Cheers,
Rob
___
Mingw-w64-public mailing list
Mingw
On Wed, Aug 26, 2020 at 7:01 PM Vincent Torri
wrote:
> -
> #include
>
> #include
>
> int main(int argc, char* argv[])
> {
> FILE* f;
> if (argc < 2)
> {
> printf("%s\n", argv[0]);
> return 1;
> }
>
> f = fopen(argv[1], "rb");
>
t report myself ? (I couldn't see an obvious way of doing
it.)
Cheers,
Rob
On Sat, Apr 25, 2020 at 2:32 PM JonY via Mingw-w64-public <
mingw-w64-public@lists.sourceforge.net> wrote:
> On 4/24/20 1:30 PM, sisyphus wrote:
> > Bloody Hell,
> > I know it's not re
Bloody Hell,
I know it's not really spam, but could you guys at least address something
that I care about (eg https://sourceforge.net/p/mingw-w64/bugs/728 )
instead of all the piffle that has been filling this list of late ??
Or maybe I should just unsubscribe. I'll accept such a view as valid
adv
Martin,
Thanks for all your work.
I couldn't locate mingw-w64-crt/math/x86/pow.def.h on the internet (URL ?),
but I assume the patch is concerned with raising a NaN to a power.
Given that raising an input NaN to a power does not always result in a NaN,
it seems a little suspicious that this has com
uadmath
The build works fine - the only problem is the demo.exe runtime crash.
Cheers,
Rob
On Mon, Jun 3, 2019 at 3:34 AM Zach van Rijn wrote:
> On Thu, 2019-05-30 at 11:10 +1000, sisyphus wrote:
> > Kudos to you, Zach, for providing those !!
> >
> > FYI:
> > Unfor
Kudos to you, Zach, for providing those !!
FYI:
Unfortunately, the absence of quadmath is a blocker for me.
Also, I've never used a compiler that has win32 threads. For me, it has
always been posix threads. (However, that might not be an issue.)
Cheers,
Rob
On Thu, May 30, 2019 at 7:39 AM Zach
Hi,
I'm aware of problems with strtold's capacity to parse hex strings. See:
https://sourceforge.net/p/mingw-w64/bugs/725/
That report provides a demo script and also mentions the workaround (of
using __mingw_strtold instead).
I *think* it's still unfixed, but I'm unaware of it affecting anything
I, too, get the impression that providing up-to-date releases is not of
much interest to the developers.
IMO that would be a pity and a pathetically weak business model.
I recently used msys2's pacman to grab gcc-8.2.1, hoping to use it in a
native win32 situation.
It seems to have a dependency on
Hi,
Alternatively, you can compile the program with -D__USE_MINGW_ANSI_STDIO :
C:\_32\C>type try.c
/* try.c */
#include
int main() {
char buf[5] = "";
int ret = snprintf(buf, 3, "%d", 123456789);
printf("buf=%s ret=%d\n", buf, ret);
return 0;
}
C:\_32\C>gcc -o try.exe try
Hi,
I don't know if you can reset the default without recompiling gcc - I
suspect you can't, but others might know better.
Closest I can get to satisfying your spec is to create a batch file called
"gcc.bat" that contains the following 2 lines:
@echo off
C:/_64/gcc-mingw-810/mingw64/bin/gcc.exe
Hi,
All of those https://musl.cc links are currently unreachable for me (with
both Internet Explorer and Firefox).
I'll try again later today.
IMO, it's a great pity that the Win32/Personal Builds/mingw-builds
directory is not updated more regularly.
Where does one locate the instructions on how
- Original Message -
From: "Lajos Foldy"
To:
Sent: Wednesday, September 12, 2012 12:29 AM
Subject: Re: [Mingw-w64-public] -ffloat-store not needed with 64-bit
compiler
> On Tue, Sep 11, 2012 at 3:01 PM, Sisyphus
> wrote:
>>
>> Is there a way to get the
- Original Message -
From: "Ruben Van Boxem"
> I feel compelled to say that if you are subtracting floats to check for
> equality, you should be smacked in the face.
No, I'm not doing that :-)
But I should have provided a brief description of what it *is*
demonstrating.
It demonstrat
- Original Message -
From: "Kai Tietz"
To:
Sent: Monday, September 10, 2012 10:15 PM
Subject: Re: [Mingw-w64-public] -ffloat-store not needed with 64-bit
compiler
> 2012/9/8 Sisyphus :
>> Hi,
>>
>> Attached is a small demo program (demo.c).
>>
Hi,
Attached is a small demo program (demo.c).
With 32-bit mingw compilers (both mingw.org's 4.5.2 and mingw64's 4.6.3) the
output of that program differs, depending upon whether I build it
with -ffloat-store or not.
I've no problem with that - I think I understand what's going on.
To get the
Thanks JonY,
http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=8cf166fedd1aa110VgnVCM10a360ea10RCRD
is a handy reference.
Naturally, the "%De" (and friends) format doesn't work, as the MSC runtime
doesn't accomodate it. (It seems there's quite a few p
Hi,
I'm using a mingw64 port of gcc-4.7.0 on Windows Vista64:
#
C:\_32\C>x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=c:/_64/alt/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper.exe
Target: x86_64-w64-min
- Original Message -
From: "Kai Tietz"
To:
Sent: Tuesday, June 26, 2012 11:03 PM
Subject: Re: [Mingw-w64-public] dll files in mingw/lib
andx86_64-w64-mingw32\lib
> Hello Rob,
>
> 2012/6/26 Sisyphus :
>> Hi,
>>
>> When we unzip the mingw-
Hi,
When we unzip the mingw-w64-bin_i686-mingw_MMDD.zip cross-compilers we
find a number of dll files (including libgcc_s_sjlj-1.dll and
libstdc++-6.dll) in mingw/lib and x86_64-w64-mingw32/lib, but not in the
'bin' folder.
Are we supposed to :
a) copy those dll's to the 'bin' folder ?
or
- Original Message -
From: "Mark Dootson"
To:
Sent: Tuesday, March 20, 2012 6:28 PM
Subject: Re: [Mingw-w64-public] Switching versions of libgcc_s_sjlj-1.dll
> Hi Rob, me again :-)
>
> On 20/03/2012 02:04, Sisyphus wrote:
>
>> Better if someone knows of a
- Original Message -
From: "kmx"
>>> Better if someone knows of a way to have Strawberry Perl stick to
>>> loading
>>> the correct (4.4.7) libgcc_s_sjlj-1.dll, but still allow these perl dll
>>> files to load the 4.7.0 libgcc_s_sjlj-1.dll .
>>>
>> Yes, this issue is caused by the fact t
Hi,
I have a C app (Strawberry Perl) built using the 64-bit gcc-4.4.7 compiler.
Whenever that perl starts up it loads libgcc_s_sjlj-1.dll. If I were to
replace that 4.4.7 version of libgcc_s_sjlj-1.dll that it loads with a 4.7.0
version of libgcc_s_sjlj-1.dll, would that be something that:
a)
- Original Message -
From: "David Cleaver"
>>> He has informed me that he is not in a cygwin environment. However, I
>>> forgot to
>>> ask what OS he was using.
He *is* watching - but a bit pressed for time.
The OS is Windows Vista64 - so I expect we're seeing a difference in msvc
r
- Original Message -
From: "Ruben Van Boxem"
Hi Ruben,
> Please note that far from all tests run when you run make check. I
> tried reporting it to the gmp-bugs list, but I was a bit too
> unfriendly to their liking. Be sure to go to all the mpz/mpn/...
> subdirectories and run make che
- Original Message -
From: "Torbjorn Granlund"
> Oops, one patch had been omitted (although the change log claimed it was
> there). You should have more luck with this snapshot:
>
> ftp://gmplib.org/pub/snapshot/gmp-5.0.90-20110706.tar.bz2
>
Yes, that's better - all tests pass.
H
- Original Message -
From: "Torbjorn Granlund"
Dropping mingw-users from the CC's.
> I have tested this on an Intel Nehalem, running windoze 7 with cygwin and
> the mingw compilers. It would be great if people could test
>
> configure && make && make check
During make check:
###
Hi,
I have a mingw64 4.6.0 cross-compiler (20100414) which I'm in the process of
phasing out, as it doesn't comply with MSVC standards regarding the
decoration of library symbols.
With that compiler, I inserted into both mingw/include/_mingw.h and
x86_64-w64-mingw32/include/_mingw.h the follow
- Original Message -
From: "Sisyphus"
> Apart from 'gcc -v' or 'gcc --version' there's apparently nothing - and I
> have at least one mingw64 64-bit compiler that doesn't report the date
> even
> then.
But on the mingw64 mailing list
- Original Message -
From: "Ruben Van Boxem"
>> Is there a simple way for a program to determine the date that the
> compiler
>> was built ?
>> (A #define that tells us would be ideal, if such exists.)
>
> I hope you're not planning on using the old compilers with wrong
> underscore
> p
- Original Message -
From: "Jason"
>> > That's the secret then - just use a compiler later than 20100428. (If
>> > only I'd waited another fortnight before I downloaded that compiler :-)
>>
>
> Our configure system can reject bad compilers , but for the test to work
> our
> assembler ya
- Original Message -
From: "Ozkan Sezer"
> Win64-targeting builds from mingw-w64 up to 2010-04-27 didn't
> follow MSVC x64 convention and did *not* prepend an undersocore
> to the symbols: this is why you are seeing the incompatibilities
> with the newer toolchains.
>
> All win64-targe
- Original Message -
From: "Ozkan Sezer"
> Win64-targeting builds from mingw-w64 up to 2010-04-27 didn't
> follow MSVC x64 convention and did *not* prepend an undersocore
> to the symbols: this is why you are seeing the incompatibilities
> with the newer toolchains.
>
> All win64-tar
Hi,
On Windows Vista I have been using the 64-bit 4.6.0 cross-compiler
(automated build 20100414) for close on 12 months.
I'm now finding that the static and import libraries built using it are
unusable by any of the recent 64-bit compilers (and vice versa). Looks like
they require different g
- Original Message -
From: "Ruben Van Boxem"
To: "Ralf Tautenhahn"
Cc: "mingw64"
Sent: Tuesday, April 19, 2011 8:55 PM
Subject: Re: [Mingw-w64-public] netCDF with MSYS/mingw-w64
>I am forwarding this to the mingw-w64 mailing list as well.
>
I have built netcdf-4.0.1, and I find the
- Original Message -
From: "Ruben Van Boxem"
>
> Three tests of MPFR 3.0.1 fail on mingw-w64, (sezero's 4.5.2 x64
> build). The "make check" log is attached.
>
If your build is seen as a cross-compilation (which, I think, happens if you
provide --build and --host arguments to configure
- Original Message -
From: "Jason"
> Did "make check" pass OK?
No - same problem when 'make check' tried to compile t-bswap.exe.
> You need to link with -lmpir and include "mpir.h" , or configure with --
> enable-gmpcompat to get librarys and headers called -lgmp and include
> "gmp.h"
- Original Message -
From: "Jason"
To:
Sent: Monday, April 11, 2011 3:47 AM
Subject: [Mingw-w64-public] projects using MinGW64
> Hi
>
> MPIR a fork of GMP now fully runs under MinGW64 see
>
> http://www.mpir.org/
Doesn't build for me actually, it builds ok (ie 'make' works), but
Hi,
On Windows Vista 64, the demo program:
#
C:\_64\c>type try.c
#include
#include
int main(void) {
double _Complex rop, op, power;
__real__ op = 3.0;
__imag__ op = 0.0;
__real__ power = 2.0;
__imag__ power = 0.0;
rop = cpow(
- Original Message -
From: "Jim Michaels"
>
> 128-bit constants are not allowed in mingw-w64 apparently. they must be
> designed into the language.
>
> I don't know why there isn't a 128-bit data type - there are UUID's on
> UNIX, the
> MAC, and the equivalent GUID on windows (a 128-bi
- Original Message -
From: "Jim Michaels"
> cool! I've been wanting to work with a 128-bit data type for a while
> now...
> now I can work with GUIDs easier.
> is this available under stdint.h as uint128_t and int128_t?
Not in my version (4.6.0 20100414) of the compiler - I can't spea
- Original Message -
From: "Kai Tietz"
>
> for an unsigned variant you can create an new type __uint128 as following:
>
> #ifdef _WIN64
> #ifndef __SIZEOF_INT128__
> typedef unsigned int __uint128 __attribute__ ((__mode__ (TI)));
> #endif
> #endif
> #endif /* __GNUC__ */
>
> Hope this he
Hi ,
I'm running Vista64, and I have a build of mingw64 from last year that has
the signed __int128 type, but (apparently) no unsigned __int128.
Do we have a (pre-built) mingw64 compiler that provides the unsigned
__int128 type ?
Cheers,
Rob
-
- Original Message -
From: "Dock, Dion"
> Any thoughts on where `__GSHandlerCheck' and `__security_check_cookie' are
> defined? There has to be > a way to link with a Visual Studio created
> lib.
When I build programs with my (64-bit) "Microsoft Platform SDK for Windows
Server 2003
- Original Message -
From: "Ozkan Sezer"
To: "Sisyphus"
>> That failure I reported happens when using the cross-compiler.
>> Ozkan, I've just now finished building 2.7.8 with one of your builds and
>> it
>> went fine.
> Well, I did
- Original Message -
From: "Ozkan Sezer"
To: "Sisyphus"
Cc: "mingw64"
Sent: Wednesday, November 17, 2010 9:00 PM
Subject: Re: [Mingw-w64-public] 64-bit dynamic libxml2
On Wed, Nov 17, 2010 at 11:31 AM, Sisyphus
wrote:
Reposting to list - last me
Reposting to list - last message blocked.
- Original Message -
From: "Ozkan Sezer"
>> These issues should be fixed in libxml2-2.7.8, please try
>> it, instead.
>>
>> --
>> O.S.
>>
>
> Or, if you insist on using 2.7.7, see this bugzilla entry:
> https://bugzilla.gnome.org/show_bug.cgi?id=
Hi,
Trying to build a 64-bit dynamic libxml2-2.7.7 and, during the make stage, I
keep getting hammered by:
*** Warning: linker path does not have real file for library -lz.
*** I have the capability to make that library automatically link in when
***
Hi,
The demo:
##
#include
#include
int main(void) {
double x;
char * ptr;
x = strtod("nan", &ptr);
printf("%f\n", x);
x = strtod("INf", &ptr);
printf("%f\n", x);
return 0;
}
##
With the mingw.org compilers
- Original Message -
From: "Chris Saunders"
To: "MinGW 64-bit"
Sent: Monday, August 09, 2010 9:30 AM
Subject: [Mingw-w64-public] Installing MinGW 64-bit and MSYS
I had the 64-bit version installed before but had to re-install my OS. I
downloaded the file mingw-w64-v1.0-snapshot-2010
- Original Message -
From: "Ozkan Sezer"
>> you're supposed to include winsock2.h before windows.h, as windows.h by
>> default includes the incompatible and older winsock.h.
>>
>> Plenty of software packages make this mistake. You'll need to fix up
>> this assumptions.
>
> Well, I think
Hi,
I have binaries for gcc-4.4.4 20100208 and gcc-4.6.0 20100414
(cross-compilers).
The former builds libssh2-1.2.6 fine (in msys shell), but the latter
doesn't.
The errors produced by 4.6.0 (during the 'make' stage) are attached in
m.txt.
Any ideas on how this change of behaviour from on
- Original Message -
From: "Kai Tietz"
To: "Sisyphus"
Cc: "mingw64"
Sent: Monday, May 31, 2010 8:59 PM
Subject: Re: [Mingw-w64-public] Multiple definitions of __do_global_ctors,
__do_global_dtors and __main
> "Sisyphus" wrote on 31.05.2
Hi,
I'm on Windows Vista64, using the x64 crosscompiler.
The command being run (it's part of a build of a perl extension named PDL) :
###
x86_64-w64-mingw32-g++ -o
..\..\blib\arch\auto\PDL\Minuit\Minuit.dll -Wl,--base-file -Wl,dll.base -mdll
-s -L"c:\_64\perl512_M\li
- Original Message -
From: "Brian Lewis"
> Have you built DLLs, though?
Alas, no.
Assuming you're gcc executable is named 'gcc.exe', you should be able to
start with './config shared no_asm'. Then, in the resultant top level
Makefile, remove the one occurrence of '-march=i486'. I t
- Original Message -
From: "Sisyphus"
> Then, in the test/Makefile, add ' -lws2_32 -lgdi32' to LIBDEPS (wherever I
> find an assignment to 'LIBDEPS' in that Makefile).
Same applies to apps/Makefile. (Seems to be the
- Original Message -
From: "Brian Lewis"
To:
Sent: Tuesday, May 18, 2010 7:57 AM
Subject: [Mingw-w64-public] openssl
> Has anyone built openssl 0.9.8n?
Been bangin' my head against the same wall for more hours than I care to
admit.
Here's how I've hacked my way through it.
I've per
- Original Message -
From: "NightStrike"
To: "Doug Semler"
>> LIBRARY_PATH is ignored in cross compilers.
>
> The toolchain in question is host=win32 target=win64. So it is meant
> to cross compile from a 32-bit windows generating binaries for a
> 64-bit windows. It just so happens
- 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 variable
not honoured.
Oops, should have qualified that - i meant th
- Original Message -
From: "Doug Semler"
To: "Sisyphus"
Cc: "mingw64"
Sent: Monday, April 19, 2010 10:30 PM
Subject: Re: [Mingw-w64-public] [Repost] LIBRARY_PATH environment variable
not honoured.
Can you post the output of gcc -v so I can see what
- Original Message -
From: "Doug Semler"
>> With mingw64, is there currently some way I can avoid having to use
>> the -L
>> switch in relation to libraries in that location ?
>> If not, are there any plans to introduce such a feature ?
> This is an environment/gcc thing, and not a min
Hi,
I asked about this on 14 Oct last year
(http://sourceforge.net/mailarchive/forum.php?thread_name=A00A469F7EBE4419992A92CBC29D03F5%40desktop2&forum_name=mingw-w64-public)
and didn't get any replies - so I thought I'd ask again and see what
information I can glean this time.
With mingw32 (fr
- Original Message -
From: "DougS"
To: "Sisyphus"
Cc: "mingw64"
Sent: Thursday, March 25, 2010 1:48 PM
Subject: Re: [Mingw-w64-public] Problem building a static gsl-1.14
> Well. You now know why we can't reproduce in a cross compiler. I do
- Original Message -
From: "Doug Semler"
> Actually, the command that's failing is:
>
> x86_64-w64-mingw32-ar t
> "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a" | sort | sort -uc
>
> (The error message is misleading because it prepends the extract
> directory onto the archive name, a
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 is of a very similar type. In that particular instance it turned out
to be a libtool (ltmain.sh)
Hi,
At http://sourceforge.net/projects/mingw-w64/files/ I see
mingw-w64-bin_i686-linux_20100307.tar.bz2 but no
mingw-w64-bin_i686-mingw_20100307.zip. Are the "mingw" cross compiler builds
no longer being made available ?
Cheers,
Rob
--
- Original Message -
From: "JonY"
To: "Ozkan Sezer"
Cc: "Sisyphus" ;
Sent: Wednesday, January 20, 2010 1:06 AM
Subject: Re: [Mingw-w64-public] Bulding gmp-5.0.0 with MinGW64 (in MSYS
shell).
> On 1/19/2010 21:55, Ozkan Sezer wrote:
>>
1 - 100 of 120 matches
Mail list logo
