Hi all,
I have restructured my Personal build directories, moving all previous
builds to "old".
Two new "release channels" will become available:
1) release: released GCC versions, with the then latest MinGW-w64 CRT
together with trunk binutils/gdb will be placed here. The two latter things
are p
Many thanks here
On Mon, Apr 30, 2012 at 04:16, Ruben Van Boxem wrote:
> Hi all,
>
> I have restructured my Personal build directories, moving all previous
> builds to "old".
>
> Two new "release channels" will become available:
> 1) release: released GCC versions, with the then latest MinGW-w64
Hi Ruben,
On 29 April 2012 16:16, Ruben Van Boxem wrote:
> I am uploading 4.7.0 at the time of writing. I plan on building 4.6.3 as
> well, and perhaps a 4.5.3. Unfortunately, I am still unable to build a
> native ada compiler/library. As before, these are now built with
> -mtune=corei7 and a bunc
2012/5/4 Chris Sutcliffe
> Hi Ruben,
>
> On 29 April 2012 16:16, Ruben Van Boxem wrote:
> > I am uploading 4.7.0 at the time of writing. I plan on building 4.6.3 as
> > well, and perhaps a 4.5.3. Unfortunately, I am still unable to build a
> > native ada compiler/library. As before, these are now
HI Ruben,
On 5 May 2012 06:00, Ruben Van Boxem wrote:
> 2012/5/4 Chris Sutcliffe
>
>> Would it be possible for you to create a 32-bit to 64-bit cross
>> compiler (i.e. a compiler that runs on 32-bit Windows that creates
>> binaries for 64-bit Windows)?
>
>
> I have uploaded builds for 32-bit Wind
max() for std C++ headers. Is that expected or unexpected, a bug or a
>> feature? :p
>
>
>
This was supposed to be a reply to
>
> [Mingw-w64-public] rubenvb GCC 4.7.0 release build
> From: Ruben Van Boxem - 2012-04-29 20:16
>
> as I guess a new mail popped out and got
You can easily see the problem, by just compiling the one-liner cpp in the
attachment which merely #include and getting messages like "error:
'max' was not declared in this scope". The file compiles OK with your
4.7.0-3 build.
And I did the tests all with the w64-mingw32 builds, if that helps.
By
Hi Ruben, I have been looking into some openmp crashes we've had with
blender and i have read the info in your first email on this thread.
It looks like we may have been experiencing the same problem
unfortunately. We are using the ray-linn build so if the default
behaviour is this for every MinGW6
2012/5/22 Antony Riakiotakis
> Hi Ruben, I have been looking into some openmp crashes we've had with
> blender and i have read the info in your first email on this thread.
> It looks like we may have been experiencing the same problem
> unfortunately. We are using the ray-linn build so if the def
Hi, thanks for the quick response. I will try to get a backtrace
though last time I tried I remember I got some assembly mumbo-jumbo,
related to openmp for certain(If memory serves right, something like
omp_get_thread_name hit a null pointer or something similar).
Unfortunately I don't have a unix
2012/5/22 Antony Riakiotakis
> Hi, thanks for the quick response. I will try to get a backtrace
> though last time I tried I remember I got some assembly mumbo-jumbo,
> related to openmp for certain(If memory serves right, something like
> omp_get_thread_name hit a null pointer or something simil
Hi,
Trying your latest 4.7 build here without problems (on an i5 :)
).Looks like indeed I had -march in mind when criticizing the use of
-mtune. The two are similar but -march impiles -mtune rather than the
opposite.
Personally I don't mind using a toolchain with sse3 support
requirements but we
On Tue, May 22, 2012 at 10:13 AM, Antony Riakiotakis wrote:
> Personally I don't mind using a toolchain with sse3 support
> requirements but we have a policy towards backwards compatibility for
> the program itself going back to 32 bit single core systems. For the
> build systems I am not sure...
On Tue, May 22, 2012 at 9:06 AM, Ruben Van Boxem
wrote:
>
> My new builds (along with the 4.5.3) will be built with
> -march=nocona -mtune=core2
>
Have you considered passing the options directly to the assembler.
You can be specific with your refinements of the extensions added.
--
Earnie
-- h
I mean in terms of processors supported by the compiler itself. As far
as operating systems go we support up to windows 2000 I think? Not
quite sure.
--
Live Security Virtual Conference
Exclusive live event will cover all
On 22 May 2012 20:10, Antony Riakiotakis wrote:
> I mean in terms of processors supported by the compiler itself. As far
> as operating systems go we support up to windows 2000 I think? Not
> quite sure.
Bad phrasing, compiler supports all processors: I meant processors
that the compile is able t
Hmm, it has been several weeks since then and I'd like to bump this tiny
issue. The source of these errors was within
i686-w64-mingw32/include/d3dx9math.inl where some inline functions were
using the 'max()' and 'min()' macros that never seemed to get a chance to
be defined thanks to the default se
Usually I use MinGW.org (32bit) and TDM64 for libusb/libusbx/libusbk
related testing. So today I gave the personal build of rubenvb a try
and tried to build libusbx 1.0.12 release but somehow it failed.
TDM64 is okay. Tested under Windows XP 64bit.
The reason might be the bundled dlltool.exe insid
On Sun, Jun 17, 2012 at 1:07 PM, Xiaofan Chen wrote:
> Usually I use MinGW.org (32bit) and TDM64 for libusb/libusbx/libusbk
> related testing. So today I gave the personal build of rubenvb a try
> and tried to build libusbx 1.0.12 release but somehow it failed.
> TDM64 is okay. Tested under Window
2012/6/17 Xiaofan Chen
> On Sun, Jun 17, 2012 at 1:07 PM, Xiaofan Chen wrote:
> > Usually I use MinGW.org (32bit) and TDM64 for libusb/libusbx/libusbk
> > related testing. So today I gave the personal build of rubenvb a try
> > and tried to build libusbx 1.0.12 release but somehow it failed.
> >
Yes, the .def file has a syntax error and should be fixed.
there is a LIBRARY command specifying no library name, which is a syntax error.
Change .def file from
LIBRARY
EXPORTS
libusb_alloc_transfer
...
to:
LIBRARY "libusb.dll"
EXPORTS
libusb_alloc_transfer
...
and everything will work as
On Sun, Jun 17, 2012 at 6:13 PM, Kai Tietz wrote:
> Yes, the .def file has a syntax error and should be fixed.
>
> there is a LIBRARY command specifying no library name, which is a syntax
> error.
>
> Change .def file from
>
> LIBRARY
> EXPORTS
> libusb_alloc_transfer
> ...
>
> to:
> LIBRARY "li
2012/6/17 Xiaofan Chen
> On Sun, Jun 17, 2012 at 6:13 PM, Kai Tietz
> wrote:
> > Yes, the .def file has a syntax error and should be fixed.
> >
> > there is a LIBRARY command specifying no library name, which is a syntax
> error.
>
I disagree. The library name is optional:
http://msdn.microsoft
On Sun, Jun 17, 2012 at 7:26 PM, Ruben Van Boxem
wrote:
> 2012/6/17 Xiaofan Chen
>> On Sun, Jun 17, 2012 at 6:13 PM, Kai Tietz
>> wrote:
>> > Yes, the .def file has a syntax error and should be fixed.
>> >
>> > there is a LIBRARY command specifying no library name,
>> > which is a syntax error.
On Mon, Jun 18, 2012 at 10:39 AM, Xiaofan Chen wrote:
> On Sun, Jun 17, 2012 at 7:26 PM, Ruben Van Boxem
> wrote:
>> 2012/6/17 Xiaofan Chen
>>> On Sun, Jun 17, 2012 at 6:13 PM, Kai Tietz
>>> wrote:
>>> > Yes, the .def file has a syntax error and should be fixed.
>>> >
>>> > there is a LIBRARY c
After sorting out issues with the libusbx build, my next experiment
is with libusbK examples build. Take note we only support WDK
for the driver build and WDK/MSVC for the library, tools and driver
installer. We do support MSVC and MinGW-w64 for the examples
build. So far we use TDM64 as the offici
On Mon, Jun 18, 2012 at 2:41 PM, Ruben Van Boxem
wrote:
> You're. Somehow trying to build with -m32, which is multilib, which is not
> enabled in my build. I'm not sure why gcc doesn't complain; it should. If
> you want to build 32-bit binaries with my toolchains, you will have to
> download the
On Mon, Jun 18, 2012 at 4:05 PM, Xiaofan Chen wrote:
> On Mon, Jun 18, 2012 at 2:41 PM, Ruben Van Boxem
> wrote:
>> You're. Somehow trying to build with -m32, which is multilib, which is not
>> enabled in my build. I'm not sure why gcc doesn't complain; it should. If
>> you want to build 32-bit
28 matches
Mail list logo
