Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.

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

Re: [Mingw-w64-public] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

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

Re: [Mingw-w64-public] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

> 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

Re: [Mingw-w64-public] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

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-w64-public] problem including semaphore.h

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:

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

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]

[Mingw-w64-public] thanks!

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 Tech Expo

[Mingw-w64-public] march=native empty/blank cross compiing?

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

Re: [Mingw-w64-public] Mass rebuild report for May 11 2016

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 $

Re: [Mingw-w64-public] website out of date

On 2/23/16, Roger Pack <rogerdpa...@gmail.com> 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 outda

[Mingw-w64-public] website out of date

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!

[Mingw-w64-public] release possible

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-

Re: [Mingw-w64-public] vsnprintf_s found by default though not present in XP, expected?

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

[Mingw-w64-public] vsnprintf_s found by default though not present in XP, expected?

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. $

Re: [Mingw-w64-public] tuner.h updates

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

[Mingw-w64-public] tuner.h updates

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

Re: [Mingw-w64-public] gdb after cross compiling doesn't seem to work

On 8/26/15, Roger Pack rogerdpa...@gmail.com 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 answer inline here

Re: [Mingw-w64-public] feature request for mkstemp

On 1/5/15, LRN lrn1...@gmail.com 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 other comments in various projects

[Mingw-w64-public] feature request for mkstemp

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

[Mingw-w64-public] failure when building multi process in OS X

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

[Mingw-w64-public] download link may need to be updated

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-

[Mingw-w64-public] 2.0.8 doesn't build gcc 4.8.0?

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?

[Mingw-w64-public] recent failure

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

Re: [Mingw-w64-public] conflicting types?

On Sat, Oct 20, 2012 at 11:05 AM, Earnie Boyd ear...@users.sourceforge.netwrote: 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 are fuzzy at best (seems that it's

Re: [Mingw-w64-public] conflicting types?

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):

[Mingw-w64-public] conflicting types?

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

Re: [Mingw-w64-public] conflicting types?

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

Re: [Mingw-w64-public] apparent hang using the experimental pthread library

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 if

[Mingw-w64-public] IsEqualGUID

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

Re: [Mingw-w64-public] apparent hang using the experimental pthread library

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 --

[Mingw-w64-public] gcc-ranlib returns error code 53?

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:

Re: [Mingw-w64-public] gcc-ranlib returns error code 53?

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

Re: [Mingw-w64-public] apparent hang using the experimental pthread library

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 a

Re: [Mingw-w64-public] apparent hang using the experimental pthread library

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

Re: [Mingw-w64-public] apparent hang using the experimental pthread library

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 already a chance

Re: [Mingw-w64-public] apparent hang using the experimental pthread library

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 GCC

[Mingw-w64-public] apparent hang using the experimental pthread library

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 told