[Mingw-w64-public] OpenCL, crosscompiling, rubenvb builds

2014-08-03 Thread Asiga Nael
Hi!

Is there any easy way of adding OpenCL support to rubenvb builds? I'm still in 
an older release (4.6.x) (because I built it myself from source and has worked 
great all these years), but I just downloaded the latest 4.8 release and didn't 
find OpenCL headers nor libs either.

I'm using mingw-w64 for cross-compiling only (from either Linux or OSX, 
depending on the day), so installing the NVIDIA or AMD gpu sdk isn't an option 
(well, actually, I've them installed, but for my native builds on Linux and 
OSX, of course, but it's not possible to do so for a cross-compiling scenario).

I tend to believe I just need headers and some sort of lib that makes the 
mingw-w64 linker happy (because the real OpenCL DLL will be in the user machine 
and it depends on the user's gpu, drivers, etc...)

Can I simply add any headers or libs to the rubenvb 4.6.x toolchains and it 
will magically work? Or is it more complex than that?

Thanks!

asiga--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] OpenCL, crosscompiling, rubenvb builds

2014-08-03 Thread Ruben Van Boxem
2014-08-03 11:56 GMT+02:00 Asiga Nael :

> Hi!
>
> Is there any easy way of adding OpenCL support to rubenvb builds? I'm
> still in an older release (4.6.x) (because I built it myself from source
> and has worked great all these years), but I just downloaded the latest 4.8
> release and didn't find OpenCL headers nor libs either.
>

Yeah, I didn't include them in my builds.


>
> I'm using mingw-w64 for cross-compiling only (from either Linux or OSX,
> depending on the day), so installing the NVIDIA or AMD gpu sdk isn't an
> option (well, actually, I've them installed, but for my native builds on
> Linux and OSX, of course, but it's not possible to do so for a
> cross-compiling scenario).
>
> I tend to believe I just need headers and some sort of lib that makes the
> mingw-w64 linker happy (because the real OpenCL DLL will be in the user
> machine and it depends on the user's gpu, drivers, etc...)
>

Yes, all you need is some headers and maybe (I would say so) an import
library.

>
> Can I simply add any headers or libs to the rubenvb 4.6.x toolchains and
> it will magically work? Or is it more complex than that?
>

It should work: if you take the import library (libopencl.a or
libopencl.dll.a) from a GPU vendor's SDK, it should enable it to work on
all systems (if I understand all the OpenCL magic correctly).

Also: I strongly recommend switching to the mingw-builds toolchains. Mine
are quite old by now and the mingw-builds are better and newer ;-)

Cheers,

Ruben
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


[Mingw-w64-public] Mass rebuild report for August 03 2014

2014-08-03 Thread Erik van Pienbroek
This is a report for the 20140803 mass rebuild of all Fedora MinGW
packages against Fedora Rawhide and a list of all the changes which
have been applied since the previous mass rebuild.

During this mass rebuild the following toolchain was used:

* mingw-w64 git ec1ff7 20140730 trunk snapshot
* binutils 2.24
* gcc 4.9.1

Statistics about current mass rebuild:
--
Timestamp of mass rebuild: 20140803
Total packages: 200
Number of failed packages: 3
Number of succeeded packages: 197
Number of added packages since previous mass rebuild: 2
Time needed to perform mass rebuild: 24 hours, 26 minutes, 42 seconds

Statistics about previous mass rebuild:
---
Timestamp of previous mass rebuild: 20140602
Total packages: 198
Number of failed packages: 2
Number of succeeded packages: 196

===

The following packages were added since the previous rebuild:

mingw-gsm
mingw-libid3tag

===

The following packages FAILED to rebuild:

mingw-clucene-2.3.3.4-10
** Package failed to build while it succeeded during the previous mass 
rebuild **
Package owner: greghellings
Time to build: 2 minutes, 19 seconds
Build logs: 
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-clucene-2.3.3.4-10

mingw-dbus-1.6.12-2
** Package failed to build while it succeeded during the previous mass 
rebuild **
Package owner: ivanromanov
Time to build: 2 minutes, 4 seconds
Build logs: 
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-dbus-1.6.12-2

mingw-wpcap-4.1.final2-13
** Package failed to build while it succeeded during the previous mass 
rebuild **
Package owner: sailer
Time to build: 1 minute, 11 seconds
Build logs: 
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-wpcap-4.1.final2-13

===

The following packages were updated since the previous rebuild:

mingw-boost-1.55.0-1.fc21
--
* Mon Jun 30 2014 Thomas Sailer  - 1.55.0-1
- update to 1.55.0


mingw-crossreport-201406-1.fc21

* Wed Jun 11 2014 Richard W.M. Jones  - 201406-1
- Update the database against packages in Fedora 20.


mingw-crt-3.1.999-0.12.trunk.gitec1ff7.20140730.fc21
-
* Wed Jul 30 2014 Erik van Pienbroek  - 
3.1.999-0.12.trunk.gitec1ff7.20140730
- Update to 20140730 snapshot (git rev ec1ff7)
- Fixes invalid value of the global variable in6addr_loopback (RHBZ #1124368)
- Fixes missing memmove_s symbol on Windows XP/Server 2003


mingw-gcc-4.9.1-3.fc21
---
* Wed Jul 30 2014 Erik van Pienbroek  - 4.9.1-3
- Use /usr/lib instead of %{_libdir} (like also is done in
  the native gcc and cross-gcc packages)

* Mon Jul 28 2014 Erik van Pienbroek  - 4.9.1-2
- Really enable std::threads support

* Fri Jul 18 2014 Erik van Pienbroek  - 4.9.1-1
- Update to gcc 4.9.1


mingw-glib2-2.41.2-1.fc21
--
* Tue Jul 22 2014 Erik van Pienbroek  - 2.41.2-1
- Update to 2.41.2

* Sat Jun 14 2014 Erik van Pienbroek  - 2.41.0-3
- Prevent an invalid @CARBON_LIBS@ from appearing in the .pc files (GNOME BZ 
#731657)


mingw-glibmm24-2.41.1-1.fc21
-
* Tue Jul 01 2014 Thomas Sailer  - 2.41.1-1
- update to 2.41.1


mingw-gnutls-3.3.5-1.fc21
--
* Tue Jul 01 2014 Michael Cronenworth  - 3.3.5-1
- Update to 3.3.5

* Mon May 26 2014 Michael Cronenworth  - 3.3.2-1
- Update to 3.3.2


mingw-gtk2-2.24.24-2.fc21
--
* Wed Jul 30 2014 Erik van Pienbroek  - 2.24.24-2
- Fix build failure on environments with older gtk-doc

* Tue Jul 22 2014 Erik van Pienbroek  - 2.24.24-1
- Update to 2.24.24


mingw-headers-3.1.999-0.12.trunk.gitec1ff7.20140730.fc21
-
* Wed Jul 30 2014 Erik van Pienbroek  - 
3.1.999-0.12.trunk.gitec1ff7.20140730
- Update to 20140730 snapshot (git rev ec1ff7)


mingw-libtasn1-4.0-1.fc21
--
* Tue Jul 01 2014 Michael Cronenworth  - 4.0-1
- Update to 4.0


mingw-llvm-3.0-9.fc21
--
* Wed Jul 23 2014 Yaakov Selkowitz  - 3.0-9
- Do not strip during make install (#1106207)


mingw-opusfile-0.6-1.fc21
--
* Sat Jun 14 2014 David King  0.6-1
- Update to 0.6


mingw-pango-1.36.5-2.fc21
--
* Wed Jul 30 2014 Erik van Pienbroek  - 1.36.5-2
- Fix build failure on environments with older gtk-doc

* Tue Jul 22 2014 Erik van Pienbroek  - 1.36.5-1
- Update to 1.36.5


mingw-poppler-0.26.3-1.fc21

* Mon Jul 21 2014 Sandro Mani  - 0.26.3-1
- Update to 0.26.3

* Thu Jun 19 2014 Sandro Mani

Re: [Mingw-w64-public] Mass rebuild report for August 03 2014

2014-08-03 Thread Erik van Pienbroek
Erik van Pienbroek schreef op zo 03-08-2014 om 14:14 [+0200]:
> Statistics about current mass rebuild:
> --
> Timestamp of mass rebuild: 20140803
> Total packages: 200
> Number of failed packages: 3
> Number of succeeded packages: 197
> Number of added packages since previous mass rebuild: 2
> Time needed to perform mass rebuild: 24 hours, 26 minutes, 42 seconds

We've reached the milestone of 200 mingw packages in Fedora! Congrats to
everybody who has been involved in this project since its start in 2008!

> The following packages FAILED to rebuild:
> 
> mingw-clucene-2.3.3.4-10
>   ** Package failed to build while it succeeded during the previous mass 
> rebuild **
>   Package owner: greghellings
>   Time to build: 2 minutes, 19 seconds
>   Build logs: 
> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-clucene-2.3.3.4-10

In file included
from 
/builddir/build/BUILD/clucene-core-2.3.3.4/src/shared/CLucene/config/threads.cpp:9:0:
/builddir/build/BUILD/clucene-core-2.3.3.4/src/shared/CLucene/config/_threads.h:55:104:
 error: conflicting declaration of C function 'void* _beginthread(void 
(__attribute__((__stdcall__)) *)(void*), unsigned int, void*)'
 void* _beginthread( void( __stdcall *start_address )( void * ),
unsigned stack_size, void *arglist );

/usr/i686-w64-mingw32/sys-root/mingw/include/process.h:29:29: note:
previous declaration 'uintptr_t _beginthread(void
(__attribute__((__cdecl__)) *)(void*), unsigned int, void*)'
   _CRTIMP uintptr_t __cdecl _beginthread(void (__cdecl *_StartAddress)
(void *),unsigned _StackSize,void *_ArgList);

Conflicting declaration of _beginthread. Can the mingw-w64 devs indicate
which declaration is correct and whether the fix should be applied in
mingw-w64 itself or in upstream clucene?


> mingw-dbus-1.6.12-2
>   ** Package failed to build while it succeeded during the previous mass 
> rebuild **
>   Package owner: ivanromanov
>   Time to build: 2 minutes, 4 seconds
>   Build logs: 
> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-dbus-1.6.12-2

  CCLD dbus-daemon.exe
/usr/lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/bin/ld:
cannot find -lrt

This should already be resolved in the latest stable version of dbus


> mingw-wpcap-4.1.final2-13
>   ** Package failed to build while it succeeded during the previous mass 
> rebuild **
>   Package owner: sailer
>   Time to build: 1 minute, 11 seconds
>   Build logs: 
> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-wpcap-4.1.final2-13

In file included from ../libpcap/Win32/Include/inetprivate.h:37:0,
 from ../libpcap/Win32/Src/getnetbynm.c:22:
../libpcap/Win32/Include/net/netdb.h:62:24: fatal error: netinet/in.h:
No such file or directory
 #include 

No idea what triggered this, but netinet/in.h is not available on
mingw-w64 and shouldn't be used when compiling for the Windows target.


Regards,

Erik van Pienbroek




--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] Mass rebuild report for August 03 2014

2014-08-03 Thread Ruben Van Boxem
2014-08-03 15:00 GMT+02:00 Erik van Pienbroek :

> Erik van Pienbroek schreef op zo 03-08-2014 om 14:14 [+0200]:
> > Statistics about current mass rebuild:
> > --
> > Timestamp of mass rebuild: 20140803
> > Total packages: 200
> > Number of failed packages: 3
> > Number of succeeded packages: 197
> > Number of added packages since previous mass rebuild: 2
> > Time needed to perform mass rebuild: 24 hours, 26 minutes, 42 seconds
>
> We've reached the milestone of 200 mingw packages in Fedora! Congrats to
> everybody who has been involved in this project since its start in 2008!
>
> > The following packages FAILED to rebuild:
> >
> > mingw-clucene-2.3.3.4-10
> >   ** Package failed to build while it succeeded during the previous
> mass rebuild **
> >   Package owner: greghellings
> >   Time to build: 2 minutes, 19 seconds
> >   Build logs:
> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-clucene-2.3.3.4-10
>
> In file included
> from
> /builddir/build/BUILD/clucene-core-2.3.3.4/src/shared/CLucene/config/threads.cpp:9:0:
> /builddir/build/BUILD/clucene-core-2.3.3.4/src/shared/CLucene/config/_threads.h:55:104:
> error: conflicting declaration of C function 'void* _beginthread(void
> (__attribute__((__stdcall__)) *)(void*), unsigned int, void*)'
>  void* _beginthread( void( __stdcall *start_address )( void * ),
> unsigned stack_size, void *arglist );
>
> /usr/i686-w64-mingw32/sys-root/mingw/include/process.h:29:29: note:
> previous declaration 'uintptr_t _beginthread(void
> (__attribute__((__cdecl__)) *)(void*), unsigned int, void*)'
>_CRTIMP uintptr_t __cdecl _beginthread(void (__cdecl *_StartAddress)
> (void *),unsigned _StackSize,void *_ArgList);
>
> Conflicting declaration of _beginthread. Can the mingw-w64 devs indicate
> which declaration is correct and whether the fix should be applied in
> mingw-w64 itself or in upstream clucene?
>

CLucene shouldn't declare Win32 (eh, MS VCRT actually) API functions. It
should just include 

The __cdecl one in MinGW-w64 is correct according to MSDN
<http://msdn.microsoft.com/en-us/library/kdzttdcb.aspx>. Only
_beginthreadex uses __stdcall.

Ruben


>
> > mingw-dbus-1.6.12-2
> >   ** Package failed to build while it succeeded during the previous
> mass rebuild **
> >   Package owner: ivanromanov
> >   Time to build: 2 minutes, 4 seconds
> >   Build logs:
> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-dbus-1.6.12-2
>
>   CCLD dbus-daemon.exe
> /usr/lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/bin/ld:
> cannot find -lrt
>
> This should already be resolved in the latest stable version of dbus
>
>
> > mingw-wpcap-4.1.final2-13
> >   ** Package failed to build while it succeeded during the previous
> mass rebuild **
> >   Package owner: sailer
> >   Time to build: 1 minute, 11 seconds
> >   Build logs:
> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140803/mingw-wpcap-4.1.final2-13
>
> In file included from ../libpcap/Win32/Include/inetprivate.h:37:0,
>  from ../libpcap/Win32/Src/getnetbynm.c:22:
> ../libpcap/Win32/Include/net/netdb.h:62:24: fatal error: netinet/in.h:
> No such file or directory
>  #include 
>
> No idea what triggered this, but netinet/in.h is not available on
> mingw-w64 and shouldn't be used when compiling for the Windows target.
>
>
> Regards,
>
> Erik van Pienbroek
>
>
>
>
>
> --
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] OpenCL, crosscompiling, rubenvb builds

2014-08-03 Thread Asiga Nael

On Sunday, August 3, 2014 2:09 PM, Ruben Van Boxem  
wrote:
> It should work: if you take the import library (libopencl.a or 
> libopencl.dll.a) 
> from a GPU vendor's SDK, it should enable it to work on all systems (if I 
> understand all the OpenCL magic correctly).

I just realized I don't really want to link to OpenCL, because my executables 
would depend on the OpenCL runtime, and I want OpenCL to be an optional feature 
(used if available, ignored otherwise). So, I'm going to load the OpenCL lib 
dynamically, in a fashion similar to GLEW with OpenGL.

Moreover, this way I don't even need any headers nor import libs at all, just 
the wrangler library.

> Also: I strongly recommend switching to the mingw-builds toolchains. Mine are 
> quite old by now and the mingw-builds are better and newer ;-)

I understand, but 4.6.x is still serving me great, and I even built it for G5 
PPC when I installed it on my systems. My time is so limited that currently I 
don't have time to do enhancements to stuff that just works... but anyway I 
suppose I'll update some day...

Thanks!

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public