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 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
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 9:14 AM, Chris Sutcliffe wrote:
> On 17 June 2012 09:29, Ruben Van Boxem wrote:
>> I have uploaded the newest GCC release 4.7.1 to the MinGW-w64 SF.net
>> website.
>
> Anybody else have them as showing non-downloadable even though they
> were uploaded to SourceForge 12 hour
On 17 June 2012 09:29, Ruben Van Boxem wrote:
> I have uploaded the newest GCC release 4.7.1 to the MinGW-w64 SF.net
> website.
Anybody else have them as showing non-downloadable even though they
were uploaded to SourceForge 12 hours ago?
Cheers,
Chris
--
Chris Sutcliffe
http://emergedesktop.o
On Sun, Jun 17, 2012 at 9:29 PM, Ruben Van Boxem
wrote:
> Hi all,
>
> I have uploaded the newest GCC release 4.7.1 to the MinGW-w64 SF.net
> website.
>
> Updated since the last round of builds:
> - binutils/gdb to latest master state
> - GMP to 5.0.5
> - libexpat to v2.1
>
> MinGW-w64 crt and h
On 6/18/2012 02:46, Derek Buitenhuis wrote:
>
>> That we change on gcc-side the link-time order for our private
>> venture libraries for allowing to build some of them by VC, for which
>> they aren't even designed, you can't believe really.
>> So we are willing to provide a special library versi
Hello Ruben!
On Sun, Jun 17, 2012 at 5:46 PM, Ruben Van Boxem
wrote:
>
> Op 17 jun. 2012 23:39 schreef "niXman" het volgende:
> ...
>> ...
>> > I see that your compressed files are labelled "sjlj." Maybe I have it
>> > backwards, but do I remember correctly that Ruben's builds are dwarf2,
>> >
Hi niXman!
On Sun, Jun 17, 2012 at 5:38 PM, niXman wrote:
> 2012/6/18 K. Frank:
>> Hi niXman!
>
> HI K. Frank!
>
>> From your exchange with Jon, do I take it correctly ...
>
> Yes.
[etc.]
Thank you for the clarifications.
And thank you again, of course, for your builds.
> ...
> Regards,
> niX
Op 17 jun. 2012 23:39 schreef "niXman" het volgende:
>
> 2012/6/18 K. Frank:
> > Hi niXman!
>
> HI K. Frank!
>
>
> > From your exchange with Jon, do I take it correctly that your build uses
> > upstream gcc's pthreads-based std::thread implementation supported
> > by mingw-w64's winpthreads?
>
> Y
2012/6/18 K. Frank:
> Hi niXman!
HI K. Frank!
> From your exchange with Jon, do I take it correctly that your build uses
> upstream gcc's pthreads-based std::thread implementation supported
> by mingw-w64's winpthreads?
Yes.
At present, I work on a patch allowing to use dynamic linking
libstdc+
Hi niXman!
On Sun, Jun 17, 2012 at 12:58 PM, niXman wrote:
> 2012/6/17 K. Frank:
>> Okay, thanks for the info. I'll probably wait for a std::thread-enabled
>> 4.7.1 release before I consider upgrading. (As I mentioned, I'm not
>> facing any particular issue.)
>
> In my builds std_concurrency is
On 17/06/2012 4:35 AM, Kai Tietz wrote:
> Hi everybody,
>
> here come my 5-cent on that. First libmingw32.a and libmingwex.a are
> two pretty different things.
I agree. This is also why I think libmingwex should NOT have a dependency on
libmingw32.
> First, main-difference is the place in lin
2012/6/17 Jon:
> This also means one must have libwinpthreads-1.dll on PATH when using
> mingwbuilds for C or C++ apps, correct?
Yes.
--
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
http://sourceforge.net
On Sun, Jun 17, 2012 at 12:58 PM, niXman wrote:
> 2012/6/17 K. Frank:
>> Okay, thanks for the info. I'll probably wait for a std::thread-enabled
>> 4.7.1 release before I consider upgrading. (As I mentioned, I'm not
>> facing any particular issue.)
>
> In my builds std_concurrency is enabled:
>
2012/6/17 K. Frank:
> Okay, thanks for the info. I'll probably wait for a std::thread-enabled
> 4.7.1 release before I consider upgrading. (As I mentioned, I'm not
> facing any particular issue.)
In my builds std_concurrency is enabled:
https://sourceforge.net/projects/mingwbuilds/files/windows-
Hello Ruben!
On Sun, Jun 17, 2012 at 11:39 AM, Ruben Van Boxem
wrote:
> 2012/6/17 K. Frank
>
>> Hi Ruben!
>>
>> On Sun, Jun 17, 2012 at 9:29 AM, Ruben Van Boxem
>> wrote:
>> > Hi all,
>> >
>> > I have uploaded the newest GCC release 4.7.1 to the MinGW-w64 SF.net
>> > website.
>> ...
>> So I'd l
2012/6/17 K. Frank
> Hi Ruben!
>
> On Sun, Jun 17, 2012 at 9:29 AM, Ruben Van Boxem
> wrote:
> > Hi all,
> >
> > I have uploaded the newest GCC release 4.7.1 to the MinGW-w64 SF.net
> > website.
>
> Thanks for that. Yours (and everyone's) efforts are greatly appreciated.
>
> I don't know yet wh
Hi Ruben!
On Sun, Jun 17, 2012 at 9:29 AM, Ruben Van Boxem
wrote:
> Hi all,
>
> I have uploaded the newest GCC release 4.7.1 to the MinGW-w64 SF.net
> website.
Thanks for that. Yours (and everyone's) efforts are greatly appreciated.
I don't know yet whether I will upgrade at this time, but I m
2012/6/17 xunxun
> 于 2012/6/17 21:29, Ruben Van Boxem 写道:
>
> Hi all,
>
> I have uploaded the newest GCC release 4.7.1 to the MinGW-w64 SF.net
> website.
>
> Updated since the last round of builds:
> - binutils/gdb to latest master state
> - GMP to 5.0.5
> - libexpat to v2.1
>
> MinGW-w64 crt
于 2012/6/17 21:29, Ruben Van Boxem 写道:
Hi all,
I have uploaded the newest GCC release 4.7.1 to the MinGW-w64 SF.net
website.
Updated since the last round of builds:
- binutils/gdb to latest master state
- GMP to 5.0.5
- libexpat to v2.1
MinGW-w64 crt and headers are still at v2.0.3.
I be
Hi all,
I have uploaded the newest GCC release 4.7.1 to the MinGW-w64 SF.net
website.
Updated since the last round of builds:
- binutils/gdb to latest master state
- GMP to 5.0.5
- libexpat to v2.1
MinGW-w64 crt and headers are still at v2.0.3.
I believe I remembered to fix the following iss
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 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
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
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.
> >
Hi everybody,
here come my 5-cent on that. First libmingw32.a and libmingwex.a are
two pretty different things.
First, main-difference is the place in link-order. Second is their
purpose. The libmingw32.a contains startup-related objects only and it
would be a major flaw to put into it any C-r
27 matches
Mail list logo
