On Sat, Dec 26, 2020 at 6:41 AM Jacek Caban wrote:
>
> Signed-off-by: Jacek Caban
> ---
>
> I think it's reasonable to assume that the current default value of
> Windows XP does not reflect reality. The new value deserves some
> considerations. I propose to go all the way to Windows 10 and match
On 2/8/17, Ricardo Constantino wrote:
> On 8 February 2017 at 02:55, Liu Hao wrote:
>
>> On 2017/2/8 1:45, Ricardo Constantino wrote:
>> > Should be fixed with
>> > https://github.com/Alexpux/MINGW-packages/commit/ba282a67e, but I
>> thought
>> > someone would've reported it to upstream by now?
>
> Full logs would be valuable.
OK see [1]
> Moreover as far as I understand, you want to build a static executable.
> Please confirm that you understand the consequences on complying with
> the LGPL. Since you also pass --enable-gpl, please also confirm that you
> understand the consequencs on co
On 7/24/16, Nakai Yuta wrote:
>>> Hi
>>>
>>> Any short test case to reproduce?
>>>
>>>
>>I've been told specifically that libs that don't use exceptions don't
>>suffer from this, like x265.
>>Rubberband does, though.
>>
>>```
>>(open mingw64-shell)
>>
>>export CC=gcc
>>#MINGW_PREFIX=/mingw64
>>
>>
Originally discovered here [1] I believe the following should "work":
$ cat go.c
#include
../../cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc go.c
In file included from go.c:1:0:
/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-i686/include/semaph
I get the same failure here [1], smallest reproducible test case so
far, unfortunately, seems to be cross compiling ffmpeg like
ffmpeg's configure
--arch=x86_64 --target-os=mingw32 --enable-librubberband --enable-gpl
then it fails (no msys2 at play at all in this case).
[1] https://gist.github.
I just noticed that my ffmpeg binaries feel about twice as fast
compiled with mingw-w64 "git master" than 4.0.6
so a big shout out thank you to whoever has put in the work there.
-roger-
--
Attend Shape: An AT&T Tech Expo
As a note, when I tried compiling gnutls today using "-march=native"
It failed, like
$ i686-w64-mingw32-gcc test.c -march=native
/var/folders/_s/c0kwjqxn2txglx5kdpcvmj0jb5h2bk/T//ccoQWGPg.o:test.c:(.text+0x1b):
undefined reference to `__sync_val_compare_and_swap_4'
collect2: error: ld returned
We've run into a similar issue cross-compiling fontconfig (mingw-w64 git)
demo:
$ cat test_mme.c
#define WIN32_LEAN_AND_MEAN
#include
//#include
int main(void) { MemoryBarrier(); return 1; }
$ ./sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc test_mme.c
$ ./sandbox/cross_compile
On 2/23/16, Roger Pack wrote:
> As a note, this page:
> http://mingw-w64.org/doku.php/download
> Says the latest version is 4.0.2
>
> sugestion: just change it to say "latest version can be found here" or
> what not, so it can't get outdated. Or keep it upda
As a note, this page:
http://mingw-w64.org/doku.php/download
Says the latest version is 4.0.2
sugestion: just change it to say "latest version can be found here" or
what not, so it can't get outdated. Or keep it updated of course.
Cheers!
-
Thanks for all the work on mingw-w64, awesome job.
Might be nice to cut a release as well, I know that FFmpeg dshow
module will soon be having to depend on git master, would be nice to
be able to depend on a release version :)
Cheers!
-roger-
--
On 12/29/15, lh_mouse wrote:
> That was because the 'libmsvcrt.a' library was created using a new version
> of MSVCRT.DLL which exported the function, but the MSVCRT.DLL shipped with
> Windows XP didn't.
Yes, I guess the question is (currently the default mechanism can
present executables that do
As a note, if configure scripts today look for
vsnprintf_s
they find it "present"
however, this causes
“the procedure entry point _vsnprintf_s could not be located in the
dynamic library msvcrt.dll”
on XP boxes. Just calling it out in case this is expected or not, as
it somewhat surprised me.
$ g
On 8/26/15, Kai Tietz wrote:
> Hello Roger,
>
> please Post patch to this ML, as this header isn't autogenerated by
> widl for us. Of course making out of it an .idl file and autogenerate
> it would be even more welcome.
Sorry it's a bit late and I see some work has been done. Here is a
patch o
On 8/26/15, Roger Pack wrote:
> Hello.
> I've been having a struggle getting something that was cross compiled
> to be "debuggable" using native gdb on windows.
>
> details: http://stackoverflow.com/a/32233750/32453
OK I was able to figure this out. I'll answ
Hello.
I've been having a struggle getting something that was cross compiled
to be "debuggable" using native gdb on windows.
details: http://stackoverflow.com/a/32233750/32453
Question 1: this is expected to "just work" is that right? Typically
I should be able to cross compile something with "-
I have some fixes and/or updates for tuner.h should I submit them here
or to wine, any thoughts there?
Thanks!
-roger-
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists
On 1/5/15, LRN wrote:
> On 06.01.2015 2:38, Roger Pack wrote:
>> Hello all.
>> As a note, it would be nice to have an mkstemp method defined [1]
>>
>> I know gnutls should probably work around it, but it would be a nice
>> convenience as well, I saw these o
Hello all.
As a note, it would be nice to have an mkstemp method defined [1]
I know gnutls should probably work around it, but it would be a nice
convenience as well, I saw these other comments in various projects:
win32/ffmpeg_git_shared.installed/include/libavutil/file.h
55: * Wrapper to work
As a note, on OS X
$ make -j 8
for mingw-w64 crt results in this:
/Library/Developer/CommandLineTools/usr/bin/make all-am
i686-w64-mingw32-gcc -E -x c
/Users/packrd/dev/temp/source/mingw-w64-3.3.0/mingw-w64-crt/lib32/
msvcrt.def.in -Wp,-w
-I/Users/packrd/dev/temp/source/mingw-w64-3.3.0/mingw-w64-
As a note, this page:
http://sourceforge.net/projects/mingw-w64/files/
still says "looking for the latest version? download 2.0.8" which
maybe isn't expected?
Cheers, and thank you for a great project, makes my cross compilers rock :)
-roger-
--
On 9/5/13, Adrien Nader wrote:
> On Wed, Sep 04, 2013, Roger Pack wrote:
>> Hello.
>> Despite my not understanding it, for some reason with 2.0.8 I'm unable
>> to build gcc 4.8.0, I get this output:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55706
Hello.
Despite my not understanding it, for some reason with 2.0.8 I'm unable
to build gcc 4.8.0, I get this output:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55706
however, that "should" have been fixed in r4357, which "should" have
been included in 2.0.8, so I'm at a bit of a loss. Any ideas
Hello.
I noticed some adjustment to the NAMELESSUNION tests in oaidl.h file.
Unfortunately, with its latest incantation, using it to build ffmpeg,
I am faced with this:
libavdevice/dshow.c: In function 'dshow_cycle_devices':
libavdevice/dshow.c:280:12: error: 'VARIANT' has no member named 'vt'
v
as a note, I got this recently trying to build gcc 4.8.0 for cross
compile (not sure if the culprit is in mingw-w64, but pasting it here
just in case it is :)
-roger-
/home/rogerdpack/dev/ffmpeg-windows-build-helpers/sandbox/source/mingw-w64-svn/trunk/mingw-w64-crt/intrincs/membarrier.c:
In functi
On Sat, Oct 20, 2012 at 11:05 AM, Earnie Boyd
wrote:
> On Fri, Oct 19, 2012 at 3:19 PM, Roger Pack wrote:
> >>> Who is defining const as an empty macro? That doesn't seem right.
> >>
> >>
> >> C++ only makes it undefined behavior, and the rules
>> Who is defining const as an empty macro? That doesn't seem right.
>
>
> C++ only makes it undefined behavior, and the rules are fuzzy at best (seems
> that it's only undefined behavior when the translation unit includes a
> standard header):
> http://stackoverflow.com/questions/2726204/c-preproc
> Something is messing with the defines in your code, it works fine when I
> tested.
>
> $ x86_64-w64-mingw32-gcc -E
> mingw-w64/trunk/mingw-w64-headers/crt/intrin.h | grep wcslen
> size_t __attribute__((__cdecl__)) wcslen(const wchar_t *);
>
> $ x86_64-w64-mingw32-gcc -E
> mingw-w64/trunk/ming
Hello all.
Using mingw-w64 "trunk" x86_64 and gcc (cross compiler) 4.7.1, I seem
to get the following when compiling libflite after configuring
flite-1.4-release [1] as $
PATH=/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-x86_64/bin:/...
./configure --host=x86_64-w64-mingw32
--pref
I don't know if this is a bug, or even the right forum, but this line:
IsEqualGUID(FORMAT_WaveFormatEx, FORMAT_WaveFormatEx);
using cross compiled mingw-w64, in a ".c" file, seems to yield this:
libavdevice/dshow.c:607:3: error: incompatible type for argument 1 of ‘memcmp’
In file included from
> Could it be that x264 or FFmpeg is improperly using the pthread
> library and that is what is actually causing this issue?
This is possible, as I saw this recently
http://ffmpeg-users.933282.n4.nabble.com/Performance-issue-question-maybe-my-misunderstanding-td4652757.html
which makes me wonder i
> This is often useful for profiling:
>
> http://www.codersnotes.com/sleepy/
I haven't gotten it to work with gcc 4.7.1 + dwarf stuff, but maybe
others will have better luck, or can point me in the right direction?
-r
--
> why you want to call gcc's LTO-stub for binutils' ranlib? You
> shouldn't call this application. Instead please use ranlib tool
> without gcc in name.
I suppose I accidentally used it since I was looking for a cross
compile friendly ranlib and saw it "available" for use.
At the least it should
> No, you don't need to recompile. Is the application really stucked,
> or is it just very slow? Have you tested that it response on '?' key
> stroke? As for me the encoding works - slowly - but it works.
Ok I tried the latest .dll, same thing here (still shows pauses):
Basically, you should s
Hello all.
I noticed today the following odd behavior (2.0.4):
mingw-w64-i686.dis/bin$ export PATH=.:$PATH
mingw-w64-i686.dis/bin$ ./i686-w64-mingw32-gcc-ranlib
mingw-w64-i686.dis/bin$ echo $?
53
I'm guessing this isn't expected?
To reproduce:
build compiler with this: http://ffmpeg.zeranoe.com/
> So, I made spinlocks "fair" by revision 5274. This means that no
> threads get *lost* on scheduling, if lock is requested.
>
> Please give this version a try.
I have tried it, thanks for the patch!
Unfortunately it appears that (ffmpeg + libx264 using it at least)
appears to deadlock (?) after
> Hmm, by looking at this I see that the issue might be a
> raise-condition about spin-locking. Means too much threads try to get
> spinlock-lock repeatively. So that one (or more) waiting threads
> simply don't get a chance to get the lock. I saw that pthread-win32
> uses here for spin-locking
>>> Well, the issue seems to be that a mutex, which is already up to be
>>> destroyed, is still waited to return. I allowed for this that a mutex
>>> can be destroyed even if another thread waits for lock for it. You
>>> may want to test revision 5250.
>>
>> Thank you I will try it.
>
> Had you
> Well, the issue seems to be that a mutex, which is already up to be
> destroyed, is still waited to return. I allowed for this that a mutex
> can be destroyed even if another thread waits for lock for it. You
> may want to test revision 5250.
Thank you I will try it.
>Which edition MinGW64 G
Greetings fellow program(mers).
A "situation" occurred the other day where, using (cross compiled)
ffmpeg+libx264 with mingw-w64, "--enable-pthreads" and the mingw-w64
pthread library, some oddness would result, like the app would "hang"
eating up 100% cpu, seemingly doing nothing useful. I was t
41 matches
Mail list logo
