2011/9/8 Kyle Schwarz :
> I'm having issues compiling FFmpeg for Windows with MinGW-w64. I'm
> using the latest MinGW-w64 and the latest FFmpeg.
>
> A bug report can be found here: https://ffmpeg.org/trac/ffmpeg/ticket/282
>
> A mailing list post can be found here:
> https://lists.ffmpeg.org/piperm
I'm having issues compiling FFmpeg for Windows with MinGW-w64. I'm
using the latest MinGW-w64 and the latest FFmpeg.
A bug report can be found here: https://ffmpeg.org/trac/ffmpeg/ticket/282
A mailing list post can be found here:
https://lists.ffmpeg.org/pipermail/ffmpeg-user/2011-September/00224
Forgot to include "preferred base:virtual size" info from
http://www.dependencywalker.com/ for the built python extension DLL's:
ruben-4.7.0 tdm-4.5.2
==
bdiff.pyd0x62A8:0xC0000x62
On 9/8/2011 22:10, Kai Tietz wrote:
> 2011/9/8 Dongsheng Song :
>> For your such plan, I recommend you rename winpthread to libposix,
>> or other suitable names.
>
> Well, libpthread.a is one library of such a pool. We might want to add
> here librt.a and libmqueue.a (etc). But all are linked by
I still see the same failure with both
i686-w64-mingw32-gcc-4.6.2-2_rubenvb.7z
i686-w64-mingw32-gcc-4.7.0-stdthread_rubenvb.7z
Crushing work is keeping me from helping out with more debugging info...sorry :(
If you've got a specific test (like Ruben's python27.dll/PATH idea, or a DLL
rebase
If you have boost library installed, you could also check the example
"libs/filesystem/v3/example/file_status.cpp".
Suppose the resulted executable is fs.exe, given a non exist filename
"foo" as input.
For pthread build,
$ ./fs.exe foo
2011/9/8 Dongsheng Song :
> For your such plan, I recommend you rename winpthread to libposix,
> or other suitable names.
Well, libpthread.a is one library of such a pool. We might want to add
here librt.a and libmqueue.a (etc). But all are linked by the
posix-standard and should be bundled toget
For your such plan, I recommend you rename winpthread to libposix,
or other suitable names.
--
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market busin
Op 8 sep. 2011 15:34 schreef "C++0X" het volgende:
>
> For static build, i use the following
>
> $ /opt/gcc/4.7.0-32.pthread/bin/g++ -pipe -o a.exe a.cpp
/opt/gcc/4.7.0-32.p
For static build, i use the following
$ /opt/gcc/4.7.0-32.pthread/bin/g++ -pipe -o a.exe a.cpp
/opt/gcc/4.7.0-32.pthread/li
b/libstdc++.a
/opt/gcc
2011/9/8 Dongsheng Song :
> On Thu, Sep 8, 2011 at 17:44, Kai Tietz wrote:
>> 2011/9/6 JonY :
>>> On 9/4/2011 14:56, Dongsheng Song wrote:
---
mingw-w64-crt/misc/clock.c | 234
+++
mingw-w64-crt/testcases/t_clock_getres.c | 62 ++
On Thu, Sep 8, 2011 at 17:44, Kai Tietz wrote:
> 2011/9/6 JonY :
>> On 9/4/2011 14:56, Dongsheng Song wrote:
>>> ---
>>> mingw-w64-crt/misc/clock.c | 234
>>> +++
>>> mingw-w64-crt/testcases/t_clock_getres.c | 62 +++
>>> mingw-w64-crt/testcases
C++0X wrote:
> For example, executable produced by
> "i686-w64-mingw32-gcc-4.7.0-stdthread_rubenvb.7z" crashes, however,
> others are fine.
>
> ---
>
>
> #include
> #include
> #include
>
> int mai
于 2011/9/8 18:28, Kai Tietz 写道:
Does this testcase also by using '-shared-libgcc' switch on linking?
As execptions normally are requiring shared libgcc and shared
libstdc++ to work proper?
My static mingw64 gcc edition has no crash.
Try to add "-static" to linker option?
--
Best Regards,
PcX
-
2011/9/8 C++0X :
> For example, executable of the following produced by
> "i686-w64-mingw32-gcc-4.7.0-stdthread_rubenvb.7z" crashes, however,
> others are fine.
> Moreover, some strange behaviors are observed when using Boost.Filesystem.
> --This is a
> testcase-
On 9/8/2011 18:25, C++0X wrote:
> For example, executable of the following produced by
> "i686-w64-mingw32-gcc-4.7.0-stdthread_rubenvb.7z" crashes, however,
> others are fine.
> Moreover, some strange behaviors are observed when using Boost.Filesystem.
> --This is
For example, executable of the following produced by
"i686-w64-mingw32-gcc-4.7.0-stdthread_rubenvb.7z" crashes, however,
others are fine.
Moreover, some strange behaviors are observed when using Boost.Filesystem.
--This is a
testcase---
2011/9/6 JonY :
> On 9/4/2011 14:56, Dongsheng Song wrote:
>> ---
>> mingw-w64-crt/misc/clock.c | 234
>> +++
>> mingw-w64-crt/testcases/t_clock_getres.c | 62 +++
>> mingw-w64-crt/testcases/t_clock_gettime.c | 60 +++
>> mingw-w64-crt/te
2011/9/4 Dongsheng Song :
> ---
> mingw-w64-crt/Makefile.am | 2 +
> mingw-w64-crt/misc/nanosleep.c | 67
> mingw-w64-crt/testcases/t_nanosleep.c | 92
> +
> mingw-w64-headers/crt/time.h | 58 +++
Thanks for this code. I would like to see the nanosleep within
winpthread library. This has two advantages IMHO. First, we have
those pure posix-routines within on library. Additionally we can use
pthread-compatible breakable wait for it.
Btw I was thinking about implementing the nanosleep (an
20 matches
Mail list logo
