Let me have a go at answering based on my experiences.
There is OpenMP 3 support in recent versions of gcc. But to make it
usable you need two more pieces:
(a) libgomp to have been built with the compiler (it is optional). This
can be built statically or as a DLL: if the latter it needs to be
On 30/12/2011 13:55, Chris Sutcliffe wrote:
> On 30 December 2011 05:23, Kai Tietz wrote:
>> 2011/12/30 JonY:
>>> Thanks for the bug report, will investigate.
>>
>> Hmm, not sure if this is related to swprintf and mingw-POSIX variant.
>> I would assume the bug here is the use of %s for a wide-strin
On Sun, 11 Dec 2011, JonY wrote:
> On 12/11/2011 17:14, Prof Brian Ripley wrote:
>> And you still have the problem I reported about .exe's depending on DLLs
>> in other directories.
>>
>> Please take a look at the dependencies of cc1.exe, the C compiler pass
>
And you still have the problem I reported about .exe's depending on
DLLs in other directories.
Please take a look at the dependencies of cc1.exe, the C compiler
pass under libexec/gcc. This depends (directly) on both
libwinpthreads-1.dll and libstdc++-6.dll. I've never seen any other
insta
Assuming you are still updating 1.0, this comes from a bug report on
R built with a toolchain from Sept 2010 (but the bug is still present
in the 1.0 branch).
Suppose x is what is called in the C code MAXNUM, the maximum
normalized double. Then pow(x, y) is computed as INF for 0 < y <= 1,
whe
This has
#define EAI_NODATA EAI_NONAME
which causes a program I was trying to compile to complain about a
duplicate case.
MSDN does not list EAI_NODATA as a return value (and nor does POSIX
2008), but it does list WSANO_DATA (11004).
So I think that either EAI_NODATA should not be defined (it
I can't find a clear statement about the status of these two branches.
If there is one, can someone point me to it?
I guess the short version is 'is 2.0 intended for production use yet?'
Brian Ripley
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, h
On Fri, 4 Nov 2011, Kai Tietz wrote:
2011/11/4 Prof Brian Ripley :
On Fri, 4 Nov 2011, Kai Tietz wrote:
2011/11/4 Prof Brian Ripley :
Thanks for picking up on this. I am seeing about 100 examples of header
conflicts with R packages (after patching R itself to avoid the problem).
I'v
On Fri, 4 Nov 2011, Kai Tietz wrote:
2011/11/4 Prof Brian Ripley :
Thanks for picking up on this. I am seeing about 100 examples of header
conflicts with R packages (after patching R itself to avoid the problem).
I've now read the source code and I do not see anything in
winpthread
timer is standard Windows API calls.
Kai?
On Thu, 3 Nov 2011, Ozkan Sezer wrote:
On Tue, Oct 25, 2011 at 9:51 AM, Prof Brian Ripley
wrote:
I first noticed this in Ruben's 4.6.2 build, but the trunk has a
similar problem (if the winpthead library is installed).
time.h ends
#ifdef _
It seems this version has e.g. cc1.exe built against libstdc++6.dll.
Why does a C-code compiler front-end need C++ support? (The 4.6.2
version did not, nor does any cc1 I have ever seen.)
The issue is that you can normally run the 32-bit compiler as
/path/to/mingw32/bin/gcc
and the 64-bit on
I first noticed this in Ruben's 4.6.2 build, but the trunk has a
similar problem (if the winpthead library is installed).
time.h ends
#ifdef __cplusplus
}
#endif
#pragma pack(pop)
#include
/* Adding timespec definition. */
#include
#include
The problem is that as a result time.h includes
On Wed, 31 Aug 2011, Charles Wilson wrote:
> On 8/31/2011 5:39 PM, K. Frank wrote:
>> Wasn't there also some licensing issue? I never understood the
>> details, but I recall seeing warnings, perhaps on one of these
>> lists, that the pthreads-win32 license was not as liberal as that
>> of ming
The following article has the most info I have found:
http://msdn.microsoft.com/en-us/library/aa905330.aspx
It includes:
Before a 32 bit process is created, the following attributes are
checked to determine whether it is an installer:
Filename includes keywords such as "install," "setup,"
On Fri, 20 May 2011, NightStrike wrote:
On Fri, May 20, 2011 at 10:18 AM, NightStrike wrote:
On Fri, May 20, 2011 at 8:32 AM, Earnie wrote:
Prof Brian Ripley wrote:
for LP64 that have long long as undefined. Can you link to the
C99 definition?
You need to consult the standard, which
On Thu, 19 May 2011, Earnie wrote:
> Prof Brian Ripley wrote:
>> On Tue, 17 May 2011, Earnie wrote:
>>
>>> NightStrike wrote:
>>>> On Wed, May 11, 2011 at 12:28 PM, Earnie
>>>> wrote:
>>>>> RSPsoftware wrote:
>>>>>
On Tue, 17 May 2011, Earnie wrote:
> NightStrike wrote:
>> On Wed, May 11, 2011 at 12:28 PM, Earnie
>> wrote:
>>> RSPsoftware wrote:
for years I was thinking that size of int and long would change
to 8
>>>
>>> The you'll find http://www.unix.org/whitepapers/64bit.html an
>>> intere
Thanks to Kai for this.
One more thing to note:
gcc -m32 does not define WIN64
windres -F i386 does (which seems to me a buglet).
Brian Ripley
On Wed, 30 Mar 2011, Kai Tietz wrote:
2011/3/30 Prof Brian Ripley :
On Tue, 29 Mar 2011, John E. / TDM wrote:
On 3/29/2011 12:09 AM, Prof Brian
Consider the following C program:
#include
#include
#include
int main()
{
double x = 0.5;
printf("%f, %f\n", -expm1(x), 1-exp(x));
exit(0);
}
If I compile this under mingw-w64-1.0-bin_i686-mingw_20110401.zip I
get the correct:
-0.648721, -0.648721
However, if I compile it un
On Tue, 29 Mar 2011, John E. / TDM wrote:
> On 3/29/2011 12:09 AM, Prof Brian Ripley wrote:
>> dlltool -m i386 --as "as --32"
>>
>> but that syntax seems to fail as it does not unpack the quoting
>> GNU c:\R\TDM\bin\dlltool (GNU Binutils) 2.21
>>
>&g
I think I am missing something in getting dlltool to work 32-bit in a
multilib build (and I've tried a few, most recently TDM's gcc-4.5.2).
It seems I need
dlltool -m i386
but also to select a 32-bit assembler (or some of the output is
pe-x86-64): what I had expected might work is
dlltool -m
On Mon, 21 Mar 2011, NightStrike wrote:
On Sun, Mar 20, 2011 at 9:03 PM, Jim Michaels wrote:
I don't know who to go to to make this change request to the c library
standard (ANSI C Library?).
it would not break any existing code, but it would make the function EVER
more useful!
Microsoft mai
On Wed, 25 Aug 2010, Earnie wrote:
> John E. / TDM wrote:
>> On 8/24/2010 3:24 PM, Ruben Van Boxem wrote:
>>> I think there needs to be some code written to link win32-pthreads
>>> to the gcc std::thread API, just like OpenMP also uses
>>> win32-pthreads. Is this line of thought correct?
>>
>> T
at 3:11 PM, t66...@gmail.com wrote:
Hi,
On 15/07/2010 9:50 PM, Kai Tietz wrote:
2010/7/15 Kai Tietz:
2010/7/15 t66...@gmail.com:
Hi
On 15/07/2010 8:47 PM, Prof Brian Ripley wrote:
We're working towards switching over to post-April snapshots, but we
have 1000s of R packages to recompil
We're working towards switching over to post-April snapshots, but we
have 1000s of R packages to recompile. A couple of those (so far)
have thrown up header conflicts.
Specifically for this report I used
mingw-w64-1.0-bin_i686-mingw_20100702.zip but I first found the
problem with a Linux cros
On Thu, 6 May 2010, AA wrote:
> Hello,
>
> I must port a Linux application to Windows.
> Unfortunately my code uses the LP64 (standard Unix/Linux) convention
> instead of LLP64 (MS VC) and it's a bit difficult to modify all the C code.
>
> The difference between the two convention is the lenght of
On Tue, 4 May 2010, NightStrike wrote:
> The default changed in 4.4.0, I believe. Use gcc -static to avoid.
That does a lot more than stop linking to that one DLL. I'd say you
meant -static-libgcc.
Note the strictures in 'man gcc' about reasons why that might not be a
good idea for C++ and J
The R project (http://www.r-project.org) has been building under
MinGW-w64 since mid-January. We have ca 2500 extension packages, ca
800 of which contain DLLs in C/C++/Fortran/more-than-one-of-those.
In those couple of months the snapshots (at least the i686-mingw ones)
have gone from dynamic l
Suggestion for the list at
http://mingw-w64.sourceforge.net/
name = The R Project for Statistical Computing
url = http://www.r-project.org
The next release (2.11.0, release process starting now) will have
pre-built binaries using mingw-w64.
Thanks for Kai Tietz for sustained help (this port was
29 matches
Mail list logo
