Compile Handbrake GUI on Windows

[s55]

http://handbrake.m0k.org/trac/wiki/CompileOnWindows

The bit your looking for is

### Building the Windows GUI

Those of you with some Linux/Unix knowledge can feel free to build new CLI's as well but for most it is probably not worth it. Those without experience will find this very difficult.

Feedback/Bugs on the SVN WinGUI builds is via IRC ONLY.
Please be aware that SVN builds are Not feature complete or stable builds. Use at your own risk.

Hopefully this will encourage some of you to build your own copies and contribute with useful bug reports or contribute patches.

Please don't post your own builds. Doing so will only cause support issues and confusion. (e.g why is feature x not complete or why does y not work etc)

[Lant]

I've been playing around with the GUI for a bit (don't know any c# so it has been interesting) - but it compiled easily for x64 with only 3 warnings;

Warning 1 Assembly generation -- Referenced assembly 'System.Data.dll' targets a different processor HandBrakeCS
Warning 2 Assembly generation -- Referenced assembly 'mscorlib.dll' targets a different processor HandBrakeCS
Warning 3 The field 'Handbrake.frmReadDVD.hbProc' is never used C:\cygwin\bin\hb2\win\C#\frmReadDVD.cs 21 25 HandBrakeCS

Haven't really tested it but the gui seems to work when compiled under x64 - could this be released at some point for the x64 purists (like me) even though compiling the gui in x64 won't improve any performance?

One thing I have noticed is that the background for the Presents menu is a different color to everything else. For me I prefer to have it all the same (so I set it to ControlLight) but is this by design?

[s55]

Yeh, It should be Control Light. My bad. I generally won't notice this because un-themed windows has Control and Control Light as the same colour.

Those warnings don't seem to be anything to worry about.
#3 Is perfectly normal. It's just currently unused code causing it.


I don't see why we can't offer drop-in replacements for the gui exe. Someone would have to provide me with an x64 exe for packaging though since I'm still running 32bit XP.

The CLI unfortunately is 32bit only since CYGWIN doesn't support 64bit compiles. I believe they may support this in the future though. This may well enhance performance.

[Lant]

Well I could compile the x64 versions (currently doing them on VS2008 beta2 - which I probably shouldn't if you want release stuff).

And I've also looked into x64 cygwin (after someone mentioned compling on x64 linux) and ended up with the same result as you...

[louden]

...using tortoisesvn -

When I try to import the project, I'm prompted for a Username and Password - Do I need to register somewhere?

Thanks in advance...
Dan

[s55]

Use SVN Checkout, not import.

[louden]

Sorry - Rookie with Tortoise SVN

Yep, did that - now I'm running and can build/debug the GUI under Vista 64 - but when I run my built version of Handbrake (using VS2008) - I still get an erorr noting there are no files on the DVD. I know they're there as I used this DVD on a mac running Handbrake.

Something's not working as expected during the reading of the DVD (in the CLI?) - Is the source code for that available for Windows? or in the SVN?

If you're building a windows version of the CLI and GUI, you can just compile the CLE as a dll and reference it in the GUI. That would be much easier to debug.

VS can have multiple projects as part of a solution, one for the GUI and for the dll that contains the guts of the CLI.


Dan

[louden]

Windows Version...

Or you could write a common library for what looks like CLI functions (Not sure what CLI stands for) and then have two front ends - one a GUI and one a command line - for a total of three projects in your solution. Both the GUI and Command Line tool would reference the underlying library...

[s55]

The libhb.dll file produced is not usable in a VS project. CYGWIN is mincing it.

the CLI (Command Line Interface) exe has to be built under cygwin.

The GUI won't work unless you have both a HandbrakeCLI.exe and cygwin1.dll file in the same directory as the exe.

[mjolner]

Thank you for the recently updated CompileOnWindows guide. Following it I got HandBrake to compile successfully, but I came away with two questions about the building process.

Following the guide I found I had to add bison as well to make jam compile (it needs (a) yacc), and that the jam executable is called "jam0.exe" rather than "jam1.exe". Am I doing something wrong?

HandBrake doesn't build with gcc 4.2.4 on my machine (changing types.h makes libmp4v2 complain and not compile), but using cygwin's included 3.4.1(?) it compiles without issue. I am testing it now, but it made me curious - Is 4.x strictly necessary or does 3.x work equally well?

[s55]

if jam's working fine, don't worry about it. I'll double check the issue with building it. The name of the exe is just what's defined in the makefile.

The reason I was using GCC 4 instead of 3, is because 3 was causing stack mis-alignments.


can you post a log of the compile so I can have a look at why libmp4v2 failed. you can pipe the compile out to a file using
jam -j 4 2>&1 log.txt

[s55]

Yup, your correct, jam needs byacc and bison. I'll add that to the guide.

Seems to compile without it, although it does throw errors so, no harm in adding them.

[mjolner]

I reinstalled gcc 4.2.4, edited types.h and checked out the latest from SVN (1576).

When I "jam -j 4 2>&1 log.txt" jam complained it could not create log.txt, so I changed the to jam 2>&1 > log.txt (send errors to stdin and pipe the rest to log.txt, right?). The log seems like it will become quite large, what would be the best way to send it to you?

I am getting alot of errors and complaining. Right off the bat a52.dec throws this out, and faad continues with similar messages. Is something wrong?

Code: Select all

configure: WARNING: dlfcn.h: present but cannot be compiled
configure: WARNING: dlfcn.h: check for missing prerequisite headers?
configure: WARNING: dlfcn.h: proceeding with the preprocessor's result
configure: WARNING: sys/time.h: present but cannot be compiled
configure: WARNING: sys/time.h: check for missing prerequisite headers?
configure: WARNING: sys/time.h: proceeding with the preprocessor's result
configure: WARNING: sys/timeb.h: present but cannot be compiled
configure: WARNING: sys/timeb.h: check for missing prerequisite headers?
configure: WARNING: sys/timeb.h: proceeding with the preprocessor's result
configure: WARNING: io.h: present but cannot be compiled
configure: WARNING: io.h: check for missing prerequisite headers?
configure: WARNING: io.h: proceeding with the preprocessor's result
configure: error: can not build a default inttypes.h

[s55]

When I "jam -j 4 2>&1 log.txt" jam complained it could not create log.txt, so I changed the to jam 2>&1 > log.txt (send errors to stdin and pipe the rest to log.txt, right?).

Yeh, thats correct. My bad, sorry.
You could copy it onto pastebin.com or pastebin.ca if you like.

can you run
gcc -v and copy the output here please.

It should say:

Code: Select all

$ gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ./configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir
=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,c++ --enable-nls --without-included-get
text --enable-version-specific-runtime-libs --without-x --disable-java-awt --with-system-zlib --disable-libgcj-debug --e
nable-threads=posix --disable-win32-registry --enable-sjlj-exceptions
Thread model: posix
gcc version 4.2.4

If your on Vista, might try running cygw in Admin mode, could be a file permission problem. Just a thought.

[mjolner]

I am out of town right and will send the logs and gcc version info tomorrow. I am on XP, but I will check permissions to make sure nothing is screwy.

[mjolner]

Here's what gcc -v says:

Code: Select all

$ gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ./configure --verbose --prefix=/usr --exec-prefix=/usr --syscon
fdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --info
dir=/usr/share/info --enable-languages=c,c++ --enable-nls --without-included-get
text --enable-version-specific-runtime-libs --without-x --disable-java-awt --wit
h-system-zlib --disable-libgcj-debug --enable-threads=posix --disable-win32-regi
stry --enable-sjlj-exceptions
Thread model: posix
gcc version 4.2.4

Looking at disk permissions it seems there are read-only files in the cygwin directory. Do you have the same thing on your end? I recursively unset the (Windows/NTFS) read-only attribute on all files under cygwin and am recompiling gcc to make sure the problem is not there. Once done with that I will send you the new HandBrake compile logs.

I hope this works out - I can't wait to see the SVN Windows GUI.

[mjolner]

Still no cigar. I have pasted the log here:
http://pastebin.ca/1085132

[s55]

I wonder, do you have zlib from libs installed?

I'm no expert on cygwin, just know enough to get by, so i'm curious if that could be the problem. If not, then I don't know.

[mjolner]

I have all the libraries. I am completely out of my element as well, so I think I will return to using SVN-checkouts on my Mac and waiting expectantly for the next release/snapshot of WinGUI.

Thank you for your help.

[NaVVy]

If it's any consolation, I'm having the same compile issues on a clean install of Cygwin on Vista x64.

I'm not very good at this stuff, but I'm still looking through the compile logs to see if there's any other info or errors that look significant. If there's any way I could help, please let me know.

[NaVVy]

Ok. Here's where I'm at...

I FINALLY got Handbrake to compile on my clean install of Cygwin on Vista x64.

It is a VERY messy solution that involves changing headers backwards and forwards so that libdvdread will compile. I'm just running through it again with a clean install and I'll see if I can refine my instructions a bit for anyone who wants them.

WARNING: I am WAY out of my element here and I have no idea whether my technique is sound or not. (If someone wiser wants to comment when I post it, I'd gladly accept any criticisms/ideas/slaps-upside-the-head)

[NaVVy]

Ok, Ladies and Gentlemen. Boys and Girls. Miscellaneous others....

Here are my instructions to compile Handbrake on Cygwin. Ive only tested it on the latest Cygwin as of today on Vista x64.
These work for me and I've repeated them a few times to test the procedure and it works but be warned YMMV.

If anyone more experienced with these things has any suggestions/improvements/comments, I'd be very happy to listen, I'm still very new to this stuff.

1. Setup Cygwin environment as per wiki instructions, except install ALL in each catagory requested plus vim in editors.

2. Download HandBrake as per normal: svn co .....

3. Run ./configure

4. Run jam -j 2 or jam -j 4 depending on how many cores you have.

5. Run jam (no multiple jobs) to make sure all possible modules are compiled.

6. Modify:
Change Line 184 from: typedef _ssize_t ssize_t; TO typedef long size_t;
and
/usr/lib/gcc/i686-pc-cygwin/4.2.4/include/stddef.h
Change Line 214 from: typedef __SIZE_TYPE__ size_t; to typedef long size_t;

7. Run jam
This will compile libdvdread and will still error when trying to compile libhb


8. Modify:
/usr/include/sys/types.h or c:\Cygwin\usr\include\sys\types.h
Change Line 184 from: typedef long size_t; TO typedef _ssize_t ssize_t;

9. Run jam
This will compile the last few modules and HandbrakeCLI

If this works for you, please support the development of Handbrake. I'm a beginner to this stuff and can't thank the Devs enough for a fantastic program.

[s55]

1. Setup Cygwin environment as per wiki instructions, except install ALL in each catagory requested plus vim in editors.

This is just a waste of disk space. You really don't need to do this.

6. Modify:
Change Line 184 from: typedef _ssize_t ssize_t; TO typedef long size_t;
and
/usr/lib/gcc/i686-pc-cygwin/4.2.4/include/stddef.h
Change Line 214 from: typedef __SIZE_TYPE__ size_t; to typedef long size_t;

This is interesting. You should not need to edit stddef.h. I certainly havn't and it compiles nicely.
/usr/lib/gcc/i686-pc-cygwin/4.2.4/include/stddef.h < doesn't even exist on my own install. The file is located elsewhere.

Can I ask for you to copy the output of gcc -v onto the forums here please. I'm interested to see if it's configured differently to the string I used in trac guide.


It's funny, the process your following, is what used to be required 6 months ago.

[NaVVy]

Here is the output from gcc -v on my system. I used the configure command from the trac guide, cut and paste from within Firefox. But if i pasted it incorrectly, I might cry for the time I've spent chasing this down. :(
But I did learn a fair bit so I shouldn't complain. :wink:

Code: Select all

$ gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ./configure --verbose --prefix=/usr --exec-prefix=/usr --syscon
fdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --info
dir=/usr/share/info --enable-languages=c,c++ --enable-nls --without-included-get
text --enable-version-specific-runtime-libs --without-x --disable-java-awt --wit
h-system-zlib --disable-libgcj-debug --enable-threads=posix --disable-win32-regi
stry --enable-sjlj-exceptions
Thread model: posix
gcc version 4.2.4

This is just a waste of disk space. You really don't need to do this.

I didn't try recompiling without the extra packages but while troubleshooting, I added everything just to make sure it wasn't a missing dependancy. I'm sure that a lot of the packages I installed aren't necesary and I should try again with only the trac guides' listed ones.

This is interesting. You should not need to edit stddef.h. I certainly havn't and it compiles nicely.
/usr/lib/gcc/i686-pc-cygwin/4.2.4/include/stddef.h < doesn't even exist on my own install. The file is located elsewhere.

Could this be due to the fact I'm on Vista x64? Or because I'm on a core 2 quad?

PS. Thanks for the feedback sr55.

[s55]

I suppose it could be 64bit vista related. then again, cygwin is a 32bit environment, so I wouldn't have thought so :/
The configure looks fine. so your defiantly using gcc4.2.4. All i can think of, is another package you installed, added that additional header file which is causing an additional conflict over the one I listed in trac.

I run a core 2 quad myself, so thats not the issue