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

[Roger Pack]

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
> Windows SDK.
>
> The main concern about this is compatibility. This value is commonly
> mistaken with 'minimum version supported in runtime', which is simply
> not the case. It's only a version that headers will provide declarations
> for. As long as the application does not use new APIs, its compatibility
> with older Windows will not change.
>
> I think that the change reflects expectations of majority of users. If
> users still want headers to not provide Win10-only declarations, they
> may just set _WIN32_WINNT explicitly in build system to the exact
> version they want. If packagers prefer it the old way, they can use the
> configure stitch for that.

Ran into this.
According to 
https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170
"The preprocessor macros WINVER and _WIN32_WINNT specify the minimum
operating system version your code supports."

Anyway, setting this value to default to windows 10 caught me
recently, suddenly compiling gnutls doesn't work for windows 7 anymore
It uses Gnulib's gettimeofday.c internally, which links against the
windows 8' GetSystemTimePreciseAsFileTime if _WIN32_WINNT is set high
enough.

You can manually set CFLAGS=_WIN32_WINNT... but some libraries don't
realize that and now everywhere that wants to support 7 is forced to
set it.
Just a thought.  If you're comfortable basically having every package
everywhere that supports windows < 10 to specify it I guess that's an
option.
Cheers!


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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?
>> Probably you could comment this PR
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506.
>>
>
> >From the amount of dev response to Roger's comment I figure any further
> response to be pointless.
> I can't even explain why my patch fixes it, that's why I didn't bother
> making an issue. I literally
> just copied gcc's fix to cygwin and added a 64-bit check because only
> 64-bit had an issue.

Oddly, seems it is actually caused (aggravated by? related to?) this ld flag:
--image-base,0x14000
https://trac.ffmpeg.org/ticket/5895
FWIW...so possibly not actually a bug [?]

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

> 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 complying with the GPL (actually the whole
> thing will be GPL so the LGPL doesn't matter anymore but it's a better
> start).

Yes I'm familiar with the licensing and its implications.

[1]
full link line:
/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/bin/x86_64-w64-mingw32-gcc
-Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed
-Wl,--image-base,0x14000
-I/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/include
-L/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib
-o /var/folders/_s/c0kwjqxn2txglx5kdpcvmj0jb5h2bk/T//ffconf.hhgbC994.exe
/var/folders/_s/c0kwjqxn2txglx5kdpcvmj0jb5h2bk/T//ffconf.H6bQMqcm.o
-lrubberband -lfftw3 -lsamplerate -lstdc++
-L/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib
-lrtmp -lwinmm -lz -lgmp -lgnutls -lnettle -lhogweed -lgmp -lcrypt32
-lws2_32 -liconv -lhogweed -lgmp -lnettle
-L/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib
-lopus -lopenjpeg -DOPJ_STATIC
-L/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib
-lopenh264 -lstdc++ -lopencore-amrwb -lopencore-amrnb -lmp3lame
-L/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib
-lmodplug -lstdc++
-L/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib
-lmfx -lstdc++ -lilbc -lgsm -lgme -lstdc++
-L/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib
-lfreetype -lexpat -lz -lbz2
-L/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib
-lfontconfig -lfreetype -lexpat -lfreetype -lexpat -lz -lbz2
-lflite_cmu_time_awb -lflite_cmu_us_awb -lflite_cmu_us_kal
-lflite_cmu_us_kal16 -lflite_cmu_us_rms -lflite_cmu_us_slt
-lflite_usenglish -lflite_cmulex -lflite
-L/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib
-lfdk-aac 
-L/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib
-lcaca 
-L/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib
-lbluray -lfreetype -lexpat -lz -lbz2 -lxml2 -lws2_32 -liconv
-L/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib
-lass -lfribidi -lfontconfig -lfreetype -lexpat -lm -liconv
-lfontconfig -lfreetype -lexpat -lfribidi -lfreetype -lexpat -lz -lbz2
-L/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib
-lgnutls -lnettle -lhogweed -lgmp -lcrypt32 -lws2_32 -liconv -lm
-llzma -lbz2 -lz -pthread -lpsapi -ladvapi32 -lshell32 -lspeexdsp
-lpsapi -loleaut32 -lpng -lstdc++
/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib/libstdc++.a(cow-stdexcept.o):(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x2c):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`_ITM_RU1'
/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib/libstdc++.a(cow-stdexcept.o):(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x39):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`transaction clone for operator new[](unsigned long long)'
/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib/libstdc++.a(cow-stdexcept.o):(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x5d):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`_ITM_memcpyRtWn'
/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib/libstdc++.a(cow-stdexcept.o):(.text$_Z23_txnal_cow_string_c_strPKv+0x1):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`_ITM_RU8'
/Users/packrd/dev/ruby/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32/lib/libstdc++.a(cow-stdexcept.o):(.text$_Z23_txnal_sso_string_c_strPKv+0x1):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`_ITM_RU8'

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

[Roger Pack]

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
>>
>>git clone https://github.com/lachs0r/rubberband.git
>>cd rubberband
>>make -j4 PREFIX="$MINGW_PREFIX" install-static
>>
>>git clone https://git.ffmpeg.org/ffmpeg.git
>>cd ffmpeg
>>./configure --enable-librubberband --pkg-config-flags=--static
>>--arch=x86_64 \
>>--disable-everything --enable-filter=rubberband --enable-gpl
>>make -j4
>>```
>>Should error out in the end, linking ffmpeg.exe.
>
> I couldn't reproduce with my toolchain I built by myself, so I think this is
> your toolchain bug and not MinGW-w64/GCC bug.
> I would recommend that you contact msys2 developpers.

Which version of gcc?
FWIW I still get this using gcc 6.3.0 + mingw-w64 git master...
I am kind of assuming it's a gcc bug though, and will report it there
if no comment back here...

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] problem including semaphore.h

[Roger Pack]

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/semaphore.h:152:8:
error: unknown type name 'mode_t'
mode_t mode,
^

(work around is to include types.h before semaphore.h but just
wondering if this is a bug or not).
Cheers!

[1] https://github.com/rdp/ffmpeg-windows-build-helpers/issues/126

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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.com/rdp/9471ba7d4565587e241d253a9ec3bffe

On 7/26/16, lh mouse  wrote:
> LRN, the author of the libitm patch of MSYS2 gcc package, suggested
> disabling it:
>
> [22:57:27]  LRN, wasn't you the guy who wrote the enable-libitm
> patch for MSYS2 ?
> [22:57:36]  s/wasn't/weren't/
> [22:57:42]  that is quite possible
> [22:58:02]  possible ? :S
> [22:58:07]  I don't remember
> [22:58:13]  oh my god.
> [22:58:46]  If i did do that, i'm sure it was accompanied by a "I have
> no idea what libitm does, i can only assure you that it compiles" disclaimer
> :)
> [23:00:11]  fair enough. you have answered what I was going to
> ask. :>
> [23:00:59]  no there isn't such a disclaimer.
> [23:01:00] 
> https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gcc-git/0012-MinGW-w64-Enable-libitm.patch
> [23:01:02]  Title: MINGW-packages/0012-MinGW-w64-Enable-libitm.patch
> at master · Alexpux/MINGW-packages · GitHub (at github.com)
> [23:01:31]  Sweet! Somebody ate it!
> [23:02:57] * mikedld|w (~mikedld|w@128.140.241.11) has joined
> [23:02:59]  the disclaimer might have been verbal only
> [23:03:12]  i don't usually put stuff into .patch file headers
> [23:03:51] * AmineKhaldi has quit (Ping timeout: 480 seconds)
> [23:04:10]  Well you should. Otherwise people would turn to you if
> it is broken. And it seems broken now.
> [23:04:28]  yep, it was me
> [23:05:09]  on 2014-01-21 i've updated gcc-4.8.2 package to the 2nd
> revision. Changelog states, among other things: "Build libatomic, libitm"
> [23:05:30] * lh_mouse stretches himself.
> [23:07:13]  On 2015-01-07 i've made gcc-4.9.2 package. Changelog
> states, beside the obligatory "Updated from upstream": "Don't build
> sanitizer and libitm (both fail at runtime)"
> [23:07:53]  this was also the last gcc package i've made, i've been
> using that build since then
> [23:09:06]  Most likely, i've found some example code for libitm, tried
> it out, and it didn't work, which prompted me to not to build libitm anymore
> [23:09:15]  I thought you should submit a Pull Request to remove
> that patch, should libitm be broken at runtime.
> [23:10:07]  Well, i don't want to shift the blame here, but i'm not
> really involved into MSYS2 development directly
> [23:10:55]  I do my own stuff, and then alexey picks it up (usually
> after my notification, sometimes by himself)
> [23:11:07]  and i pick up his stuff whenever i update things
> [23:11:25]  i guess i never told him about libitm, and he never asked
> [23:11:38]  That was the problem, exactly.
> [23:12:09]  anyway: Now you know, and knowledge the battle!
> [23:12:26]  Would you mind my sending this conversion to MSYS2 ML?
> RiCON is waiting for a solution.
> [23:14:16]  feel free to do so
> [23:14:24]  Thanks.
>
> --
> Best regards,
> lh_mouse
> 2016-07-26
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] thanks!

[Roger Pack]

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 July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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 1 exit status
$
i686-w64-mingw32-gcc -march=native -Q --help=target | grep march
  -march=
$cat test.c
long cmpxchg( long* value, long comp_val, long new_val )
{
return __sync_val_compare_and_swap( value, comp_val, new_val );
}

int main()
{
return 0;
}

Though manually specifying seemingly "any" march works fine:

$./sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc
test.c  -march=ivybridge
$

$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Native gcc works OK:
$ gcc-6 -march=native -Q --help=target | grep march
  -march=   ivybridge


Anybody know if this is expected or not?
Cheers!

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
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 May 11 2016

[Roger Pack]

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_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc
test_mme.c -march=sandybridge
/var/folders/_s/c0kwjqxn2txglx5kdpcvmj0jb5h2bk/T//ccTXcYo6.o:test_mme.c:(.text+0xc):
undefined reference to `_mm_mfence'
collect2: error: ld returned 1 exit status


refs:
https://lists.libav.org/pipermail/libav-devel/2015-October/072425.html
https://github.com/rdp/ffmpeg-windows-build-helpers/issues/137

Thanks.
-roger-

On 5/11/16, Erik van Pienbroek  wrote:
> Erik van Pienbroek schreef op wo 11-05-2016 om 19:35 [+0200]:
>> The following packages FAILED to rebuild:
>>
>> mingw-clucene-2.3.3.4-14
>>  Package owner: greghellings
>>  Time to build: 1 minute, 16 seconds
>>  Build logs:
>> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20160511/mingw-clucene-2.3.3.4-14
>
> CMake Error at src/shared/cmake/MacroEnsureVersion.cmake:27 (MATH):
>   math cannot parse the expression: "x86_64-w64-mingw326*1 +
>   x86_64-w64-mingw321*100 + x86_64-w64-mingw320": syntax error, unexpected
>   exp_NUMBER, expecting $end (7)
> Call Stack (most recent call first):
>   src/shared/cmake/MacroCheckGccVisibility.cmake:35 (macro_ensure_version)
>   src/core/CMakeLists.txt:10 (MACRO_CHECK_GCC_VISIBILITY)
>
>
> This sounds an issue where the version of the GCC compiler (6.1.0) can't be
> detected properly by the CMake script.
>
>> mingw-cximage-600-14
>>  ** Package failed to build while it succeeded during the previous mass
>> rebuild **
>>  Package owner: elmarco
>>  Time to build: 45 seconds
>>  Build logs:
>> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20160511/mingw-cximage-600-14
>
> i686-w64-mingw32-g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> --param=ssp-buffer-size=4 -D_USRDLL -D_USRCxImageCrtDll
> -DCxImageCrtDll_EXPORTS -shared -o libcximage.dll -Wl,--out-
> implib,libcximage.dll.a ../CxImage/tif_xfile.cpp ../CxImage/ximabmp.cpp
> ../CxImage/ximadsp.cpp ../CxImage/ximaenc.cpp ../CxImage/ximaexif.cpp
> ../CxImage/ximage.cpp ../CxImage/ximagif.cpp
> ../CxImage/ximahist.cpp ../CxImage/ximaico.cpp ../CxImage/ximainfo.cpp
> ../CxImage/ximaint.cpp ../CxImage/ximajas.cpp ../CxImage/ximajbg.cpp
> ../CxImage/ximajpg.cpp ../CxImage/ximalpha.cpp
> ../CxImage/ximalyr.cpp ../CxImage/ximamng.cpp ../CxImage/ximapal.cpp
> ../CxImage/ximapcx.cpp ../CxImage/ximapng.cpp ../CxImage/ximaraw.cpp
> ../CxImage/ximasel.cpp ../CxImage/ximaska.cpp
> ../CxImage/ximatga.cpp ../CxImage/ximath.cpp ../CxImage/ximatif.cpp
> ../CxImage/ximatran.cpp ../CxImage/ximawbmp.cpp ../CxImage/ximawmf.cpp
> ../CxImage/ximawnd.cpp ../CxImage/xmemfile.cpp
> ../CxImage/CxImageDLL/CxImageCrtDll.cpp -lgdi32 -lws2_32 -ljpeg -ltiff
> -ljasper -I/usr/i686-w64-mingw32/sys-root/mingw/include/libpng16
> -I/usr/i686-w64-mingw32/sys-root/mingw/include -L/usr/i686-w64-
> mingw32/sys-root/mingw/lib -lpng16 -lz
> In file included from
> /usr/i686-w64-mingw32/sys-root/mingw/include/c++/deque:60:0,
>  from
> /usr/i686-w64-mingw32/sys-root/mingw/include/c++/queue:60,
>  from ../CxImage/ximadsp.cpp:3457:
> /usr/i686-w64-mingw32/sys-root/mingw/include/c++/bits/stl_algobase.h:243:56:
> error: macro "min" passed 3 arguments, but takes just 2
>  min(const _Tp& __a, const _Tp& __b, _Compare __comp)
>
>
> This failure is likely caused by a compatibility issue with GCC6
>
>> mingw-LibRaw-0.17.1-2
>>  ** Package failed to build while it succeeded during the previous mass
>> rebuild **
>>  Package owner: smani
>>  Time to build: 52 seconds
>>  Build logs:
>> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20160511/mingw-LibRaw-0.17.1-2
>
> ../internal/dcraw_common.cpp: In member function 'void
> LibRaw::vng_interpolate()':
> ../internal/dcraw_common.cpp:4539:3: error: narrowing conversion of '128'
> from 'int' to 'signed char' inside { } [-Wnarrowing]
>    }, chood[] = { -1,-1, -1,0, -1,+1, 0,+1, +1,+1, +1,0, +1,-1, 0,-1 };
>    ^
>
> This one is probably caused by more strict behavior of GCC6
>
>
>> mingw-llvm-3.0-11
>>  ** Package failed to build while it succeeded during the previous mass
>> rebuild **
>>  Package owner: brouhaha
>>  Time to build: 4 minutes, 31 seconds
>>  Build logs:
>> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20160511/mingw-llvm-3.0-11
>
> /builddir/build/BUILD/llvm-3.0.src/tools/bugpoint/ToolRunner.cpp: In
> function 'int RunProgramRemotelyWithTimeout(const llvm::sys::Path&, const
> char**, const llvm::sys::Path&, const llvm::sys::Path&,
> const llvm::sys::Path&, unsigned int, unsigned int)':
> /builddir/build/BUILD/llvm-3.0.src/tools/bugpoint/ToolRunner.cpp:131:12:
> error: no match for 'operator<<' (operand types are 'llvm::raw_ostream' and

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

[Roger Pack]

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 outdated.  Or keep it updated of course.

Whereas this page:
https://sourceforge.net/projects/mingw-w64/

Says the latest (and default download) is 3.1.0 :|
Just so you're aware...sure confuses users like me :)
-roger-

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] website out of date

[Roger Pack]

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!

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] release possible

[Roger Pack]

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-

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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 don't work on XP, because configure cannot
easily detect the absence of vsnprintf_s) is this desired? Or if that
ship has sailed, that's OK too.
-roger-

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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.

$ grep vsnprintf_s . -r
Binary file ./cross_compilers/build/crt/lib64/libmingwex.a matches
Binary file ./cross_compilers/build/crt/lib64/libmsvcrt.a matches

Thanks all.
-roger-

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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 off the "old way" anyway...
diff --git a/mingw-w64-headers/include/tuner.h 
b/mingw-w64-headers/include/tuner.h
index c6efe1d..fff0b53 100644
--- a/mingw-w64-headers/include/tuner.h
+++ b/mingw-w64-headers/include/tuner.h
@@ -122,9 +122,9 @@ DECLARE_INTERFACE_(IBDACreateTuneRequestEx,IUnknown)
 #undef  INTERFACE
 #define INTERFACE ITuneRequest
 #ifdef __GNUC__
-#warning COM interfaces layout in this header has not been verified.
-#warning COM interfaces with incorrect layout may not work at all.
-__MINGW_BROKEN_INTERFACE(INTERFACE)
+///#warning COM interfaces layout in this header has not been verified.
+///#warning COM interfaces with incorrect layout may not work at all.
+///__MINGW_BROKEN_INTERFACE(INTERFACE)
 #endif
 DECLARE_INTERFACE_(ITuneRequest,IDispatch)
 {
@@ -142,10 +142,10 @@ DECLARE_INTERFACE_(ITuneRequest,IDispatch)
 STDMETHOD_(HRESULT,Invoke)(THIS_ DISPID dispIdMember,REFIID riid,LCID 
lcid,WORD wFlags,DISPPARAMS *pDispParams,VARIANT *pVarResult,EXCEPINFO 
*pExcepInfo,UINT *puArgErr) PURE;
 
 /* ITuneRequest methods */
-STDMETHOD_(HRESULT,Clone)(THIS_ ITuneRequest **ppNewTuneRequest) PURE;
+STDMETHOD_(HRESULT,get_TuningSpace)(THIS_ ITuningSpace **ppTuningSpace) 
PURE;
 STDMETHOD_(HRESULT,get_Components)(THIS_ IComponents **ppComponents) PURE;
+STDMETHOD_(HRESULT,Clone)(THIS_ ITuneRequest **ppNewTuneRequest) PURE;
 STDMETHOD_(HRESULT,get_Locator)(THIS_ ILocator **ppLocator) PURE;
-STDMETHOD_(HRESULT,get_TuningSpace)(THIS_ ITuningSpace **ppTuningSpace) 
PURE;
 STDMETHOD_(HRESULT,put_Locator)(THIS_ ILocator *pLocator) PURE;
 
 END_INTERFACE
@@ -158,10 +158,10 @@ DECLARE_INTERFACE_(ITuneRequest,IDispatch)
 #define ITuneRequest_GetTypeInfo(This,iTInfo,lcid,ppTInfo) 
(This)->lpVtbl->GetTypeInfo(This,iTInfo,lcid,ppTInfo)
 #define ITuneRequest_GetIDsOfNames(This,riid,rgszNames,cNames,lcid,rgDispId) 
(This)->lpVtbl->GetIDsOfNames(This,riid,rgszNames,cNames,lcid,rgDispId)
 #define 
ITuneRequest_Invoke(This,dispIdMember,riid,lcid,wFlags,pDispParams,pVarResult,pExcepInfo,puArgErr)
 
(This)->lpVtbl->Invoke(This,dispIdMember,riid,lcid,wFlags,pDispParams,pVarResult,pExcepInfo,puArgErr)
-#define ITuneRequest_Clone(This,ppNewTuneRequest) 
(This)->lpVtbl->Clone(This,ppNewTuneRequest)
+#define ITuneRequest_get_TuningSpace(This,ppTuningSpace) 
(This)->lpVtbl->get_TuningSpace(This,ppTuningSpace)
 #define ITuneRequest_get_Components(This,ppComponents) 
(This)->lpVtbl->get_Components(This,ppComponents)
+#define ITuneRequest_Clone(This,ppNewTuneRequest) 
(This)->lpVtbl->Clone(This,ppNewTuneRequest)
 #define ITuneRequest_get_Locator(This,ppLocator) 
(This)->lpVtbl->get_Locator(This,ppLocator)
-#define ITuneRequest_get_TuningSpace(This,ppTuningSpace) 
(This)->lpVtbl->get_TuningSpace(This,ppTuningSpace)
 #define ITuneRequest_put_Locator(This,pLocator) 
(This)->lpVtbl->put_Locator(This,pLocator)
 #endif /*COBJMACROS*/
 
@@ -182,8 +182,8 @@ DECLARE_INTERFACE_(IChannelIDTuneRequest,ITuneRequest)
 STDMETHOD_(ULONG, Release)(THIS) PURE;
 
 /* IChannelIDTuneRequest methods */
-STDMETHOD_(HRESULT,put_ChannelID)(THIS_ BSTR ChannelID) PURE;
 STDMETHOD_(HRESULT,get_ChannelID)(THIS_ BSTR *ChannelID) PURE;
+STDMETHOD_(HRESULT,put_ChannelID)(THIS_ BSTR ChannelID) PURE;
 
 END_INTERFACE
 };
@@ -198,9 +198,9 @@ DECLARE_INTERFACE_(IChannelIDTuneRequest,ITuneRequest)
 #undef  INTERFACE
 #define INTERFACE ILocator
 #ifdef __GNUC__
-#warning COM interfaces layout in this header has not been verified.
-#warning COM interfaces with incorrect layout may not work at all.
-__MINGW_BROKEN_INTERFACE(INTERFACE)
+///#warning COM interfaces layout in this header has not been verified.
+///#warning COM interfaces with incorrect layout may not work at all.
+///__MINGW_BROKEN_INTERFACE(INTERFACE)
 #endif
 DECLARE_INTERFACE_(ILocator,IDispatch)
 {
@@ -218,21 +218,21 @@ DECLARE_INTERFACE_(ILocator,IDispatch)
 STDMETHOD_(HRESULT,Invoke)(THIS_ DISPID dispIdMember,REFIID riid,LCID 
lcid,WORD wFlags,DISPPARAMS *pDispParams,VARIANT *pVarResult,EXCEPINFO 
*pExcepInfo,UINT *puArgErr) PURE;
 
 /* ILocator methods */
-STDMETHOD_(HRESULT,Clone)(THIS_ ILocator **ppNewLocator) PURE;
 STDMETHOD_(HRESULT,get_CarrierFrequency)(THIS_ __LONG32 *pFrequency) PURE;
-STDMETHOD_(HRESULT,get_InnerFEC)(THIS_ FECMethod *FEC) PURE;
-STDMETHOD_(HRESULT,get_InnerFECRate)(THIS_ BinaryConvolutionCodeRate *FEC) 
PURE;
-STDMETHOD_(HRESULT,get_Modulation)(THIS_ ModulationType *pModulation) PURE;
-STDMETHOD_(HRESULT,get_OuterFEC)(THIS_ FECMethod *FEC) PURE;
-STDMETHOD_(HRESULT,get_OuterFECRate)(THIS_ BinaryConvolutionCodeRate *FEC) 
PURE;
-

[Mingw-w64-public] tuner.h updates

[Roger Pack]

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.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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:

 Question 1: this is expected to just work is that right?  Typically
 I should be able to cross compile something with -g and then copy it
 to a windows box and use gdb.exe on it and it should work?

Yes it should. :)

 Does anybody know why I might be getting:

 (gdb) break main
 ...
 (gdb) r
 ...
 Cannot insert breakpoint 1.
 Cannot access memory at address 0x42445c
 process basically hangs

 very consistently? Even with native gcc 4.9.x I was getting this behavior.

Turns out that (as far as I can tell) what was occuring is that I was
linking against a library that had some export symbols in it.  I was
creating a static executable.  Somehow this confused the heck out of
it.  Any thoughts as to whether the root cause of the problem is ld
or gdb? Hmm.
Cheers!
-roger-

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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:

 win32/ffmpeg_git_shared.installed/include/libavutil/file.h

 55: * Wrapper to work around the lack of mkstemp() on mingw.

 win32/fontconfig-2.11.1/ChangeLog

 621:Fix mkstemp absence for some platform


 giflib also requires a mkstemp implementation.

 That said, such implementation is really just 42 lines of C code. Is it
 worth
 including in libmingwex? What *are* the criteria for including functions in
 libmingwex?

The giflib people mention it's in some kind of (IEEE) spec so...maybe
that makes it somehow worth implementing more? :)
https://sourceforge.net/p/giflib/bugs/45/
Cheers!
-roger

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] feature request for mkstemp

[Roger Pack]

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 around the lack of mkstemp() on mingw.

win32/fontconfig-2.11.1/ChangeLog

621:Fix mkstemp absence for some platform

So sounds like lots of people today having to work around.
Cheers!
-roger-

[1] https://sourceforge.net/p/mingw-w64/support-requests/33/

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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-crt/def-include |
/usr/bin/sed ‘s/^#/;/’ lib32/msvcrt.def
/bin/sh: lib32/msvcrt.def: No such file or directory
i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
-I/Users/packrd/dev/temp/source/mingw-w64-3.3.0/mingw-w64-crt -m32
-I/Users/packrd/dev/temp/mingw-w64-i686/include -pipe -std=gnu99 -Wall
-Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline
-Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -g
-O2 -MT lib32_libm_a-_libm_dummy.o -MD -MP -MF
.deps/lib32_libm_a-_libm_dummy.Tpo -c -o lib32_libm_a-_libm_dummy.o `test
-f ‘_libm_dummy.c’ || echo
‘/Users/packrd/dev/temp/source/mingw-w64-3.3.0/mingw-w64-crt/’`_libm_dummy.c
make[1]: *** [lib32/msvcrt.def] Error 1
make[1]: *** Waiting for unfinished jobs….
mv -f .deps/lib32_libm_a-_libm_dummy.Tpo .deps/lib32_libm_a-_libm_dummy.Po
make: *** [all] Error 2

(seems to work ok in linux).

Anyway compiling with make -j 2 works ok and is a work around for now.
Let me know if you'd like this filed somewhere else or any feedback on it.
Cheers!
-roger-
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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-

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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?
(My first thought is...maybe once the VARIANT stuff stabilizes a new
release would be possible?)  It'd be nice to get off svn.
Thank you all.
-roger-

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] recent failure

[Roger Pack]

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 function 'MemoryBarrier':
/home/rogerdpack/dev/ffmpeg-windows-build-helpers/sandbox/source/mingw-w64-svn/trunk/mingw-w64-crt/intrincs/membarrier.c:5:5:
error: unknown type name '__LONG32'
 __LONG32 Barrier = 0;
 ^

https://gist.github.com/rdp/5327227

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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 only undefined behavior when the translation unit includes a
  standard header):
 
 http://stackoverflow.com/questions/2726204/c-preprocessor-define-ing-a-keyword-is-it-standards-conforming
 
  In C, it seems that it is allowed.
 
  All this doesn't change the fact that #define const is incredibly
 stupid and
  should be removed from user code.
 
  Agree.
  My confusion though is still why, with the same include (windows.h) in
  64 bit it also loads intrin.h, but not in 32 bit. odd...

 It is most likely because _WIN64 takes on different characteristics.
 I.E. The same path isn't followed in the header code when _WIN64 is
 defined.


Yes it is definitely following a different path.  It just seems odd to me
that...it would pull in entire include files in one path but not another
(intrin.h *only* on win64).
-r
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

 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-preprocessor-define-ing-a-keyword-is-it-standards-conforming

 In C, it seems that it is allowed.

 All this doesn't change the fact that #define const is incredibly stupid and
 should be removed from user code.

Agree.
My confusion though is still why, with the same include (windows.h) in
64 bit it also loads intrin.h, but not in 32 bit. odd...

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] conflicting types?

[Roger Pack]

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
--prefix=/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-x86_64/x86_64-w64-mingw32
--disable-shared --enable-static

[1] http://www.speech.cs.cmu.edu/flite/packed/flite-1.4/ has the source.

This same configure works with 32 bit cross compiler, but with 64 bit,
I seem to end up getting these:

https://gist.github.com/3914282

...
/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-x86_64/lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/include/intrin.h:1057:5:
error: conflicting types for 'wcslen'
In file included from find_sts_main.c:42:0:
/home/rdp/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-x86_64/lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/include/string.h:123:18:
note: previous declaration of 'wcslen' was here

definitions were:

string.h:

size_t __attribute((cdecl_)) wcslen(const wchar_t *_Str);

intrin.h:

size_t __attribute__((__cdecl__)) wcslen( wchar_t *);

Anybody seen anything like this or may know what I'm running into here?
Thanks!
-r

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

 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/mingw-w64-headers/crt/wchar.h | grep wcslen
   size_t __attribute__((__cdecl__)) wcslen(const wchar_t *_Str);

It appears that there is a
#define const
before a
#include windows.h

in this case.

Now why would this fail in x86 but not in w32?

Appears that in winnt.h, there is a #include intrin.h
that is hit in x86 mode but not w32 mode.

appears around line 1102'ish is a
#if defined(__x86_64)

that is making the difference.
Is this expected?
Thanks!
-roger-

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

 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 it's stuck in a spinlock or something (his
still progress fine, though, I'd imagine...)
:)
-r

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] IsEqualGUID

[Roger Pack]

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 ./libavutil/common.h:36:0,
 from ./libavutil/avutil.h:274,
 from ./libavutil/opt.h:31,
 from libavdevice/dshow.c:23:
/home/rogerdpack/dev/ffmpeg-windows-build-helpers/builds/mingw-w64-i686/lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/string.h:40:15:
note: expected ‘const void *’ but argument is of type ‘GUID’
libavdevice/dshow.c:607:3: error: incompatible type for argument 2 of ‘memcmp’
In file included from ./libavutil/common.h:36:0,
 from ./libavutil/avutil.h:274,
 from ./libavutil/opt.h:31,
 from libavdevice/dshow.c:23:
/home/rogerdpack/dev/ffmpeg-windows-build-helpers/builds/mingw-w64-i686/lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/string.h:40:15:
note: expected ‘const void *’ but argument is of type ‘GUID’

Can anybody else reproduce this?
It may be expected...
Thanks.
-r

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

 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

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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/blog/?p=106, then run it.
Feedback?
Thanks.
-roger-

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

 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 output don't use me or something :P
Thanks!
-roger-

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

 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 few seconds.

Here's an example trace:

Thanks for your help in this!
-roger-

[New Thread 5056.0xcc4]9.0 size=   0kB time=00:00:00.06 bitrate=
0.0kbits/s dup=3 drop=0

Program received signal SIGINT, Interrupt.
[Switching to Thread 5056.0xcc4]
0x767c6d67 in NlsUpdateSystemLocale () from C:\Windows\syswow64\kernel32.dll
(gdb) thread apply all bt

Thread 10 (Thread 5056.0xcc4):
#0  0x767c6d67 in NlsUpdateSystemLocale () from C:\Windows\syswow64\kernel32.dll
#1  0x7b21c13a in ?? ()
#2  0x in ?? ()

Thread 8 (Thread 5056.0xa6c):
#0  0x777d013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from C:\Windows\system32\ntdll.dll
#1  0x777d013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from C:\Windows\system32\ntdll.dll
#2  0x75640bdd in WaitForMultipleObjectsEx () from
C:\Windows\syswow64\KernelBase.dll
#3  0x0002 in ?? ()
#4  0x07dffd28 in ?? ()
#5  0x76721a2c in KERNEL32!GetVolumePathNamesForVolumeNameA () from
C:\Windows\syswow64\kernel32.dll
#6  0x07dffd28 in ?? ()
#7  0x76724208 in KERNEL32!CheckForReadOnlyResource () from
C:\Windows\syswow64\kernel32.dll
#8  0x0002 in ?? ()
#9  0x7efde000 in ?? ()
#10 0x00bb46c8 in do_sema_b_wait_intern (sema=0x1fc, nointerrupt=0,
timeout=4294967295) at src/cond.c:599
#11 0x00bb49dc in do_sema_b_wait (sema=0x1fc, nointerrupt=0,
timeout=4294967295, cs=0x6e267c4, val=0x6e267dc)
at src/cond.c:559
#12 do_sema_b_wait (sema=0x1fc, nointerrupt=0, timeout=4294967295,
cs=0x6e267c4, val=0x6e267dc)
at src/cond.c:549
#13 0x00bb4dfa in pthread_cond_wait (c=0x3cbdb64,
external_mutex=0x3cbdb68) at src/cond.c:448
#14 0x00827fa0 in worker (v=0x3cbf060) at libavcodec/pthread.c:216
#15 0x00bb62f8 in pthread_create_wrapper (args=0x6e26eb8) at src/thread.c:1378
#16 0x75571287 in msvcrt!_itow_s () from C:\Windows\syswow64\msvcrt.dll
#17 0x75571328 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#18 0x7672339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from
C:\Windows\syswow64\kernel32.dll
#19 0x06e26f90 in ?? ()
#20 0x777e9ef2 in ntdll!RtlpNtSetValueKey () from C:\Windows\system32\ntdll.dll
#21 0x06e26f90 in ?? ()
#22 0x777e9ec5 in ntdll!RtlpNtSetValueKey () from C:\Windows\system32\ntdll.dll
#23 0x755712e5 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#24 0x in ?? ()

Thread 7 (Thread 5056.0x1638):
#0  0x777d013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from C:\Windows\system32\ntdll.dll
#1  0x777d013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from C:\Windows\system32\ntdll.dll
#2  0x75640bdd in WaitForMultipleObjectsEx () from
C:\Windows\syswow64\KernelBase.dll
#3  0x0002 in ?? ()
#4  0x07bffd28 in ?? ()
#5  0x76721a2c in KERNEL32!GetVolumePathNamesForVolumeNameA () from
C:\Windows\syswow64\kernel32.dll
#6  0x07bffd28 in ?? ()
#7  0x76724208 in KERNEL32!CheckForReadOnlyResource () from
C:\Windows\syswow64\kernel32.dll
#8  0x0002 in ?? ()
#9  0x7efde000 in ?? ()
#10 0x00bb46c8 in do_sema_b_wait_intern (sema=0x1fc, nointerrupt=0,
timeout=4294967295) at src/cond.c:599
#11 0x00bb49dc in do_sema_b_wait (sema=0x1fc, nointerrupt=0,
timeout=4294967295, cs=0x6e267c4, val=0x6e267dc)
at src/cond.c:559
#12 do_sema_b_wait (sema=0x1fc, nointerrupt=0, timeout=4294967295,
cs=0x6e267c4, val=0x6e267dc)
at src/cond.c:549
#13 0x00bb4dfa in pthread_cond_wait (c=0x3cbdb64,
external_mutex=0x3cbdb68) at src/cond.c:448
#14 0x00827fa0 in worker (v=0x3cbf060) at libavcodec/pthread.c:216
#15 0x00bb62f8 in pthread_create_wrapper (args=0x6e26bb0) at src/thread.c:1378
#16 0x75571287 in msvcrt!_itow_s () from C:\Windows\syswow64\msvcrt.dll
#17 0x75571328 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#18 0x7672339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from
C:\Windows\syswow64\kernel32.dll
#19 0x06e26c88 in ?? ()
#20 0x777e9ef2 in ntdll!RtlpNtSetValueKey () from C:\Windows\system32\ntdll.dll
#21 0x06e26c88 in ?? ()
#22 0x777e9ec5 in ntdll!RtlpNtSetValueKey () from C:\Windows\system32\ntdll.dll
#23 0x755712e5 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#24 0x in ?? ()

Thread 6 (Thread 5056.0x16ac):
#0  0x777d013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from C:\Windows\system32\ntdll.dll
#1  0x777d013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from C:\Windows\system32\ntdll.dll
#2  0x75640bdd in WaitForMultipleObjectsEx () from
C:\Windows\syswow64\KernelBase.dll
#3  0x0002 in ?? ()
#4  0x079ffd28 in ?? ()
#5  0x76721a2c in KERNEL32!GetVolumePathNamesForVolumeNameA () from
C:\Windows\syswow64\kernel32.dll
#6  0x079ffd28 in ?? ()
#7  0x76724208 in KERNEL32!CheckForReadOnlyResource () from
C:\Windows\syswow64\kernel32.dll
#8 

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

[Roger Pack]

 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 system-mutexes instead.
 I will work on a patch to make spinlocks fair between its users.

Sounds good.  I can provide you binaries with debug symbols if it
would help.  I glanced at the thread and nothing obvious stood out to
me (didn't see too many threads trying to get a spinlock?) so thanks
for your help here.
Anybody know how to static cross compile w32-pthreads by chance? :)
-r

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

 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 to test it?

Ok I did try it with the latest SVN.  Unfortunately the hangs still
appear to be present.

Also there was a small definition conflict when enabling PTHREADS_DBG
and I was wondering if the default should be to print state always
(see attached patch for both items).
Even then it appears to not output anything by default to the console,
at least in this case (FWIW).
Let me know what other debugging I can add or any other information you'd like.

https://gist.github.com/3125847 trace6/trace7 shows recent stack
traces when the problem occurs.

I do tend to see spinlock.c:36 a lot in the backtraces when it occurs.

Thanks!
-roger-


default.diff
Description: Binary data
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

 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 Compiler did you use? Can you give us the link?

http://ffmpeg.zeranoe.com/blog/?p=96 IIRC.

 Is it win32 thread or posix thread?

posix in this case
Thanks!
-r

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Roger Pack]

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 to
bring it up here, as well.

I attempted to capture stack traces during the time that it was hung
(though who knows how accurate they are):
https://gist.github.com/3125847

Anybody have any clue/idea as to what is going on?

It is reproducible using ffmpeg.exe from here:
http://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-20120706-git-8293a21-win32-static.7z
then download this file:
http://rogerdpack.t28.net/incoming/sintel.mpg
then run like this:
$ ffmpeg  -y -i sintel.mpg -pass 1 -t 75 -c:v libx264 -an nul.mp4

Hangs/pauses on the console occur sporadically.  When compiled using
ffmpeg's win32threads option instead of pthreads, it never has
hangs.

Any help appreciated.

Original thread: http://ffmpeg.org/pipermail/ffmpeg-user/2012-July/007861.html
-roger-

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public