x264 Windows x64 support

[MasterNobody]

Sorry for 2 days delay. I have a lot of work on my real job.
Here is update version of patch compatible with revision 1101:
x264_win64_support.08.r1101.diff (http://stashbox.org/392450/x264_win64_support.08.r1101.diff)
and binaries of checkasm for testing:
checkasm_1101.zip (http://stashbox.org/392451/checkasm_1101.zip)
also this time I compile binaries of x264 as reference variant for testing (they are not profiled so NOT the quickest one):
x264_1101.zip (http://stashbox.org/392453/x264_1101.zip)

P.S. As always I am waiting for testing on Core2 / Core i7 / Phenom CPUs.

[LoRd_MuldeR]

P.S. As always I am waiting for testing on Core2 / Core i7 / Phenom CPUs.

Thanks. Everything is fine (32-Bit and 64-Bit) on my Core 2 :D

[vucloutr]

checkasm all test ok for 32bit and 64bit with Q6600 & Server2008x64

[RickA]

All 32 & 64bit tests passed here as well. Q6600 w/ Server 2008 x64. :-)

[DarkZell666]

Checkasm 1101 ok on Q9300 + Vista x64.

[kemuri-_9]

All ok on my phenom.

[paulvdb]

Checkasm 1101 all ok on i7 + XP x64.

[lexor]

Checkasm is all good on i7+win7... yes I'm late for the party, but I just got the new toy and are currently in the process of testing it :)

[Dark Shikari]

My latest massive addition of assembly functions (http://git.videolan.org/?p=x264.git;a=commit;h=32615747d3ab5648b666b4f55531f47b3c075521) has broken the patch; MasterNobody says a fix will be up soon.

[darkip]

x264_win64_support.09.r1106.diff seems to be up, has anyone got a checkasm built yet?

[komisar]

x264_win64_support.09.r1106.diff seems to be up, has anyone got a checkasm built yet?
http://stashbox.org/396151/checkasm64.zip

[LoRd_MuldeR]

x264: All tests passed Yeah :)

[darkip]

All ok on my X7900 Core2Duo Extreme

[paulvdb]

checkasm ok on i7 / XP x64.

[MasterNobody]

And here is my official announce of new patch (too late ;) ).
patch: x264_win64_support.09.r1106.diff (http://stashbox.org/396156/x264_win64_support.09.r1106.diff)
checkasm: checkasm_r1107.zip (http://stashbox.org/396406/checkasm_r1107.zip)
x264: x264_r1107.zip (http://stashbox.org/396412/x264_r1107.zip)
As always need testing on Core 2 / Core i7 / Phenom CPUs both 32-bit and 64-bit checkasm

[tph]

All passed on C2D E6400, Vista64.

[paulvdb]

32 bit and 64 bit checkasm both ok i7 / XP x64

[kemuri-_9]

All ok on the phenom here....

[LoRd_MuldeR]

As always need testing on Core 2 / Core i7 / Phenom CPUs both 32-bit and 64-bit checkasm

Both are good http://forum.gleitz.info/images/smilies/thumb.gif

[lexor]

win7+i7, all clear for both checks.

[Esurnir]

all clear on 32 + 64 bit on vista 64 bit memrom core 2 duo.

[bob0r]

Simple question: Can i compile x264-64bit on a Windows XP 32bit, 32bit CPU system?

[MasterNobody]

Simple question: Can i compile x264-64bit on a Windows XP 32bit, 32bit CPU system?
Yes, you can (this is how I compile my builds). You can use cross-compiler from MinGW-W64 project (http://sourceforge.net/projects/mingw-w64/) but it is better to get komisar's build (http://komisar.gin.by/tools/mingw.generic.gcc433.7z) which use GCC 4.3.3 (not GCC 4.4.0 experimental) or compile it yourself. The only thing you can't do is to profile 64-bit builds on 32-bit system.

P.S. Command line for cross-compilation will look like this:
sh ./configure --host=x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32-
make

[bob0r]

Grab mingw-w64-bin_i686-mingw_20090210.zip ?
Stuff like yasm is included? Assuming you need 64bit of that too.

[kemuri-_9]

Grab mingw-w64-bin_i686-mingw_20090210.zip ?
Stuff like yasm is included? Assuming you need 64bit of that too.

you can use the x86 yasm you already have, since yasm natively handles all the formats itself independent of the compiler used for it.

[bob0r]

Ok, that means i can also use the 32bit stuff like ncftpput.exe in the 64bit environment?

[MasterNobody]

Grab mingw-w64-bin_i686-mingw_20090210.zip ?
It is better to get some of the alternative builds. Because GCC 4.4.0 used there is unstable now and miscompiles x264 code.

[bob0r]

It is better to get some of the alternative builds. Because GCC 4.4.0 used there is unstable now and miscompiles x264 code.

Which do you recommend for now?
Direct url surfnet.nl would be nice :)

[MasterNobody]

Which do you recommend for now?
Direct url surfnet.nl would be nice :)
I use already posted above: http://komisar.gin.by/tools/mingw.generic.gcc433.7z

[bob0r]

Ah thanks, i thought x264 build :)

[techouse]

I get this error when compiling it: http://pastebin.ca/1335317

[kemuri-_9]

I get this error when compiling it: http://pastebin.ca/1335317


x86_64-pc-mingw32-gcc -o x264.exe x264.o matroska.o muxers.o libx264.a -lvfw32 -s -fprofile-generate


it's using libvfw32, it needs to be using libavifil32.
so add in --extra-ldflags=-lavifil32 on the ./configure
as a simple fix.

the ./configure needs to be altered slightly to not check for libvfw32 if the arch is x86_64, since it doesn't hold all the necessary functionality on x86_64

[MasterNobody]

I get this error when compiling it: http://pastebin.ca/1335317
x86_64-pc-mingw32-gcc -o x264.exe x264.o matroska.o muxers.o libx264.a -lvfw32 -s -fprofile-generateThere is no 64-bit version libvfw.a of this library instead must be used libavifil32.a. For some reason configure choose wronge library (probably because directory with 32-bit libs is in search library path).
If you use komisar's mingw build then you probably need to make this changes:
1) move "<mingw_root>\include"=>"<mingw_root>\i686-pc-mingw32\include";
2) move all from "<mingw_root>\lib"=>"<mingw_root>\i686-pc-mingw32\lib" except "<mingw_root>\lib\gcc" directory;
3) reconfigure junction of "<mingw_root>\mingw\include" and "<mingw_root>\mingw\lib" to new locations.
Then both i686 and x86_64 would work correctly.

[MasterNobody]

the ./configure needs to be altered slightly to not check for libvfw32 if the arch is x86_64, since it doesn't hold all the necessary functionality on x86_64
There was ideas to change the order of library checks in configure:
-lvfw32 <=> -lavifil32
-lwsock32 <=> -lws2_32
This probably would work because libavifil32.a and libws2_32.a exists in both 32-bit and 64-bit. But I think the most correct way is fixing the reason of problem (removing 32-bit libs from 64-bit gcc lib search) and not making workarounds.

[techouse]

There is no 64-bit version libvfw.a of this library instead must be used libavifil32.a. For some reason configure choose wronge library (probably because directory with 32-bit libs is in search library path).
If you use komisar's mingw build then you probably need to make this changes:
1) move "<mingw_root>\include"=>"<mingw_root>\i686-pc-mingw32\include";
2) move all from "<mingw_root>\lib"=>"<mingw_root>\i686-pc-mingw32\lib" except "<mingw_root>\lib\gcc" directory;
3) reconfigure junction of "<mingw_root>\mingw\include" and "<mingw_root>\mingw\lib" to new locations.
Then both i686 and x86_64 would work correctly.

Even moar errors?!!?!?! http://pastebin.com/m44be6e92

[MasterNobody]

Even moar errors?!!?!?! http://pastebin.com/m44be6e92
You forgot the "--cross-prefix=x86_64-pc-mingw32-" option.

[techouse]

I get the same result with and without it. Just tell me how I can properly reconfigure junction, cause I think I f****d it up and that that's causing all the problems.... :/

P.S.: I need the cross option even if I'm on Windoze64?!

[komisar]

techouse
#!/bin/sh

PREF=/mingw

junction -d $PREF/mingw/lib
junction $PREF/mingw/lib $PREF/i686-pc-mingw32/lib

junction -d $PREF/mingw/include
junction $PREF/mingw/include $PREF/i686-pc-mingw32/include

junction -d $PREF/mingw/lib64
junction $PREF/mingw/lib64 $PREF/x86_64-pc-mingw32/lib

junction -d $PREF/mingw/include64
junction $PREF/mingw/include64 $PREF/x86_64-pc-mingw32/include


If you compile to i686-pc-mingw32 -- no use prefix
For compile to x86_64-pc-mingw32 -- use --cross-prefix=x86_64-pc-mingw32-

P.S. Soon I post new version of my mingw without this tricks...

[komisar]

Please, test updated mingw toolchain:Update mingw-w64 to rev.609;
Fix bug in gcc with crtfastmath;
No need "junction" for cross-compile;
All x32 compile with CFLAGS="-O2 -pipe -fomit-frame-pointer -march=pentium2 -mtune=generic -mno-cygwin";
All x64 compile with CFLAGS="-O2 -pipe -fomit-frame-pointer -mtune=generic -mno-cygwin"
Correct detect library e.g. libvfw32, libavifil32


http://komisar.gin.by/tools/20090214_gcc433.mingw.generic.7z

P.S. Who build x264 for x86_64-pc-mingw32 check processing for files > 2 GB. (may incorrect detect usage fseeko64/ftello64)

[bob0r]

Hmm it worked.
With skystrife's help u managed to compile x264bit.
(skystrife also tested the build, thanks!)

However, i still can't fprofile, so i'll just be hosting skystrife's generic builds instead!

@Komisar:
In your package you may also want to include yasm.exe and a 64bit compiled gpac library + include files. Also pthreads if needed.
This way your package only requires a fstab addition and it workks.


f:/MinGW /mingw
f:/mingw.generic /mingw


That seems to work here + i could still use all old gcc and other stuff. (Only yasm.exe had to be copied and possible some more files for other projects, but for x264 it worked nice.)

[Buggle]

Recently I see there are x64 builds appearing on x264.nl (plus the addition of win64 support in the main branch or svn or what you call it) and here on Doom9. Is this because of the great effort by MasterNobody (meaning all stuff written will have to be adjusted by him everytime), or has something fundamentally changed due to those changes in the source code?
It would appear that 64bit is finally really getting off the ground, hopefully MeGUI will follow soon...

[LoRd_MuldeR]

Recently I see there are x64 builds appearing on x264.nl (plus the addition of win64 support in the main branch or svn or what you call it) and here on Doom9. Is this because of the great effort by MasterNobody (meaning all stuff written will have to be adjusted by him everytime), or has something fundamentally changed due to those changes in the source code?
It would appear that 64bit is finally really getting off the ground, hopefully MeGUI will follow soon...

See here:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=f43e22a7873ea3811bbc15e30d67681f23249087

It seems the Win64 patch, that had been maintained separately before, was merged into the x264 Git repository...

[komisar]

bob0r, x64 build from x264.nl dont process files > 2G... Need update cross-compile toolchain.

[LoRd_MuldeR]

bob0r, x64 build from x264.nl dont process files > 2G... Need update cross-compile toolchain.

Bobor just mirrors Skystrife's x64 builds, so Skystrife needs to update then...

[kemuri-_9]

bob0r, x64 build from x264.nl dont process files > 2G... Need update cross-compile toolchain.

skystrife uses his own cross-compiled build iirc.

which is it: you can't read >2 GB files or write >2 GB files or both?

[MasterNobody]

skystrife uses his own cross-compiled build iirc.

which is it: you can't read >2 GB files or write >2 GB files or both?
Mostly read (except AVI/AVS input) but may be also write (if it use fseek/ftell). This may happen if 'configure' doesn't define
#define fseek fseeko64
#define ftell ftello64
which may happen if something wrong in compilation chain (for example, if there is no crtfastmath.o in GCC as was in first cross-compilation GCC build by komisar)

[kemuri-_9]

Mostly read (except AVI/AVS input) but may be also write (if it use fseek/ftell). This may happen if 'configure' doesn't define
#define fseek fseeko64
#define ftell ftello64
which may happen if something wrong in compilation chain (for example, if there is no crtfastmath.o in GCC as was in first cross-compilation GCC build by komisar)

if -ffast-math fails from lack of crtfastmath.o,
./configure fails pretty much all the custom configures, so it doesn't configure the ftello64/seeko64 properly.

Edit:
hmm... seemingly the cross-compile is missing crtfastmath.o by default...
oh, i see, found the file, but there's compilation issues:
crtfastmath.c:

#define FE_NONIEEE_ENV 0x0009a04d0270037f
...
__asm__ __volatile__ ("mov.m ar.fpsr=%0" : : "r"(FE_NONIEEE_ENV));



$ gcc crtfastmath.c
Assembler messages:
Error: no such instruction: `mov.m ar.fpsr=%rax'


so how did komisar go about fixing this issue?

[akupenguin]

#define FE_NONIEEE_ENV 0x0009a04d0270037f
...
__asm__ __volatile__ ("mov.m ar.fpsr=%0" : : "r"(FE_NONIEEE_ENV));

You're looking at __ia64_set_fast_math(). That's Itanium, not x86_64.

[kemuri-_9]

ah it seems i was...


$ gcc -D__x86_64__ gcc-snapshot/gcc/config/i386/crtfastmath.c -c -o crtfastmath.o
$ mv crtfastmath.o /prefix/x86_64-pc-mingw32/lib

works fine...
strange at how it doesn't compile and install it automatically with gcc's makefile though...

but that fixes the issue nevertheless...

[komisar]

issue to fix configuration of gcc when his build:
in gcc/config.gcc add in section (for 4.3.3 version)i[34567]86-*-mingw32* | x86_64-*-mingw32*)
tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h dbxcoff.h i386/cygming.h i386/mingw32.h"
xm_file=i386/xm-mingw32.h
tmake_file="${tmake_file} i386/t-cygming i386/t-mingw32"
target_gtfiles="\$(srcdir)/config/i386/winnt.c"
extra_options="${extra_options} i386/cygming.opt"
extra_objs="winnt.o winnt-stubs.o"
cxx_target_objs=winnt-cxx.o
default_use_cxa_atexit=yes
case ${enable_threads} in
"" | yes | win32)
thread_file='win32'
tmake_file="${tmake_file} i386/t-gthr-win32"
;;
esac
case ${target} in
x86_64-*-mingw*)
tmake_file="${tmake_file} i386/t-crtfm"
;;
*)
;;
esac
case ${target} in
*mingw32crt*)
tm_file="${tm_file} i386/crtdll.h"
;;
*mingw32msv* | *mingw32*)
;;
esac
;;
in gcc/config.gcc add in section (for 4.3.4 version)i[34567]86-*-mingw32* | x86_64-*-mingw32*)
tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h dbxcoff.h i386/cygming.h i386/mingw32.h"
xm_file=i386/xm-mingw32.h
tmake_file="i386/t-cygming i386/t-mingw32"
target_gtfiles="\$(srcdir)/config/i386/winnt.c"
extra_options="${extra_options} i386/cygming.opt"
extra_objs="winnt.o winnt-stubs.o"
cxx_target_objs=winnt-cxx.o
default_use_cxa_atexit=yes
case ${enable_threads} in
"" | yes | win32)
thread_file='win32'
tmake_file="${tmake_file} i386/t-gthr-win32"
;;
esac
case ${target} in
x86_64-*-mingw*)
tmake_file="${tmake_file} i386/t-crtfm"
;;
*)
;;
esac
case ${target} in
*mingw32crt*)
tm_file="${tm_file} i386/crtdll.h"
;;
*mingw32msv* | *mingw32*)
;;
esac
;;

P.S. Change full section of configuration.