Building Avidemux 2.6x with MINGW

[Jan Gruuthuse]

most likely (pure guessing): you need to edit and adapt to your environment:
- bootStrapCrossMingw
- bootStrapCrossMingw_w64
- bootStrapCrossMingw_w32
probably use only one of these w32 or w64.
see response below

[mean]

dont use the cross ones

[AQUAR]

@ Jan - Pure quesses are most welcome (at the very least they are usefull food for thought!). 

Thanks for the hints.
There are 25 shell scripts in trunk and of these it seems the bootStrap.bash script is the one I should play with.
I tried it just to see what would happens - of course the build process failed very quickly (no cmake!).
After cmake the check for pthreads fails (just another item needed as listed in the wiki dependency list!).

[AQUAR]

Try 2 continued:

- The bootstrap.bash seems to be for building as well as creating installable linux packages.
----Only interested in the building element for now (ie ignoring the rest of the script).
----By running this script it will give some insight and it will also throw up the next missing dependency to be fixed. 
----Will worry later about building these dependencies from source (for proper compiling of avidemux).
- First missing dependency Cmake - got it from Cmake.org.
- Next missing dependency is Pthreads - DL the latest pthreads-w32-2-9-1-release.zip (as it has 64 bit binaries!).
----Cmake wouldn't find pthreads (tried various other releases but no go!).
----Tried to compile a popular pthreads "helloworld" program to see if G++ sees pthreads (at first it failed, needed long long integer values!).
----G++ sees Pthreads but Cmake does not (prefex issue that I don't quite understand yet).
----Quick fix for Cmake is to add some more environment variables (LIB, LIBPATH and INCLUDE) in "system settings"
----It now sees Pthreads (probably these environment variables can be placed in code somewhere!).

A lot of googling to fix each tangent problem that pops up (the steep learning curve!).   

[AQUAR]

Try 2 continued:

The last few items that CMake wants are:
- Gettext.exe plus associated libintl.dll (from GTK+ bundle)
- SDL from libsdl.org
- SQLite (from sourceforce winbuilds64 packages)
---- winbuilds64 packages downloadable using a package manager yypkg.exe!)
- last one is YASM (bundled in with mingw-w64-bin-x86_64-20140529) 
- Missing still is execinfo.dll
---- execinfo.dll seems to not be available.
---- best I can establish its a backtrace debugging item

Now Cmake creates makefiles with all these frankenstein sourced dependencies.
Of course make fails with error2 - but at least its a bit of a start to see the bootstrap.bash script process in action.
Pushing the envelope with "make install" does create some object files! 

Not sure about the next step.
- try make -i and see what happens (just learned about the -i parameter!)?
- maybe try compiling some of these frankensteins?
- maybe simpler to try the build environment on 32 bit windows (better support!)?
---- noticed void cast warnings as in the Pthreads helloworld test program (integer range problem?)

[mean]

2 options
1- Make sure you used the MSYS generator
2- Generate a codeblocks project and use codeblocks

[AQUAR]

Thanks mean.

After a quick google on these two options.
- these are build generator options you specify to Cmake with the -G parameter.
- tested these two options via the CMake GUI on the cmakelist.txt (in avidemux_core!)
--- with msys generator and G++  options it generated a bunch of makefiles into a test folder.
--- with codeblocks it finds sh shell and stops.
--------- renamed the sh.exe and it still fails with invalid project files (need to dig more about codeblocks projects!).
- the bootstrap.bash file has a BUILDER string variable set to "Unix Makefiles".
---- guess that would need to change to "MSYS Makefiles" (first mod for the windows environment!).

[AQUAR]

Try 2 continued:

- Changed the Bootstrap.bash script to set the CMake build generator to "MSYS Makefiles".
--- Make files get build as before and is followed by 'make fails'.
--- A quick look at the log file for the make process shows "does not name a type" kind of error on header files.
------- eg on avifmt.h, ADM_colourspace.   

[AQUAR]

An interesting newbie trap for those using SVN to make a local clone of the avidemux code branch.

Yesterday the bootstrap.bash script created make files.
Today it failed at CmakeZ (not sure what the Z is for!).
Eventually I worked out that the problem was due to a failed check for SCM (because it could not resolve github.com).
Now I used svn to DL the avidemux source from github.com and it un beknown to me it comes with this SCM (System Control Management) item.
So it seems that SCM requires a live internet connection - but I disabled my network card - and hence the bootstrap.bash script failed.

I deleted all hidden .SVN folders from my test copy of the source code branch (trunk).
It now works again without being connected to the net.
There is probably a proper way to configure this SCM feature so it doesn't want to check for changes to the code.

[AQUAR]

Try 2 continued:

- Very slow progress as I have to learn how to interpret the error messages in the logbuildCore text file.
----- That in turn leads me onto all sorts of tangents about C++ and header files.

- Currently looking into issues with avifmt.h from the mingw-w64 runtime package.

- The first message about avifmt.h is:   
c:/AvidBuild/mingw64/x86_64-w64-mingw32/include/avifmt.h:2:8: error: expected constructor, destructor, or type conversion before 'file'
* This file is part of the mingw-w64 runtime package.
          ^
c:/AvidBuild/mingw64/x86_64-w64-mingw32/include/avifmt.h:3:25: error: 'refer' does not name a type
* No warranty is given; refer to the file DISCLAIMER within this package.
                                      ^
----- Turns out this is due to a missing / at the beginning (needed to block comment out the first 4 lines!).
----- Did not expect that from a MinGW package.

- In turn a new "second" message about avifmt.h appears:
C:/AvidBuild/mingw64/x86_64-w64-mingw32/include/avifmt.h:13:1: error: expected unqualified-id before 'extern'
extern "C" {
^
----- No idea about that so far (looks fine with my limited ability!)
----- Might delete extern "C" and see if C++ will cope?

[mean]

Looks like a comment has been damaged, it's trying to compile a comment

[AQUAR]

There seem to be are a few issues with avifmt.h.
After fixing the damaged comment the MinGW compiler then found the next issue in avifmt.h.
This being, it won't recognise the extern "C"  directive .

It seems that this extern "C" issue has cropped up before with MinGW but I am not understanding the techno babble around it.
One suggestion was to remove it (that I understand!) and I will try that.

If I have a corrupt avifmt.h then it might be indicative of other corrupted files in the package.
So I will try another MinGW source without the precompiled QT package.
Assuming I can run the bootstrap.bash with the --without QT option and in the absense of QT binaries (I'll soon learn!). 

[mean]

is it using g++/c++ ?
Extern "C" is a valid c++ stanza but not a C one

[AQUAR]

One of the definition files that includes avifmt.h is ADM_coreUtils/src/avidemutils.cpp
Looking at the logfile MinGW uses the g++ compiler for that definition file.

The compile process switches between gcc and g++ (I guess based on the file extentsion!).
FFMPEG code seems to be done with gcc.

I checked other releases of MinGW W64, and they are all propagating the same avifmt.h file (with the corrupted block comment).

I'll try to modify the helloworld program with an extern "C" directive and see how MinGW reacts with gcc and g++ (to see if it is recognized).

[mean]

you shouldnt have to do all this
Something is wrong