Building Avidemux 2.6x with MINGW

[AQUAR]

Hi Mean,

For sure something is wrong (mostly me learning everything about issues I encounter on the fly).
Eg, I just learned that the extern "C" (wrapped in "#ifdef __cplusplus") is intended to prevent name mangling, when including headers that link to libraries compiled with C.

I still tried it in on a C++ hello world program - neither gcc or c++ cares if I wrap it with extern "C" - still compiles fine.
Its not the extern "C" directive per se but something that is preventing its use.

There was a similar kind of thing described here  http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/355154.aspx
I need to understand what the techno babble is about so I can see if it applies here.

I did write to Gruntster and Lord Mulder for help in setting up a windows build-environmemt, but they haven't replied.
I think avifmt.h maybe a winapi item concerning video for windows (as it includes winapifamily.h)!.

Also, I read in the forum that Gruntster was using codeblocks, so  maybe using that IDE is a better approach.
Without them I'll stick to running the bootstrap.bash script using the shell CLI provided by MSYS (that should be do-able!).

[AQUAR]

Try 2 continued.

. I could not work out the issue with the extern "C" directive in avifmt.h, so I removed it.
-- hopefully g++ will compile the code wrapped inside the extern "C" without causing name mangling.
-- only thing I can postulate is that extern "C" is already being applied and so the second directive is not recognised a C stanza.

. The compile process now goes a lot further and creates a lot of binaries in a newly created install folder.

. Eventually it snags with a cmake error.
-- CMake Error at C:/AvidBuild/msys/home/John/trunk/cmake/admFFmpegUtil.cmake:2 (FILE):
  file failed to open for reading (Invalid argument):
-- admFFmpegUtil.cmake:2 is
    FILE(READ "${headerFile}" FFMPEG_H)
-- That line is part of a macro that I think parses a file for information.
-- No idea how to interpret that cmake line, but maybe its not looking at the right file.

[mean]

make sure you have "patch", tar, gzip and gunzip installed

[AQUAR]

During bootstrap.bash the script checks for patch and tar passed.
gzip.exe exists in the MSYS bin folder along with a gunzip file with no extension.
gunzip also responds in the MSYS shell (probably invokes gzip -d).

Not sure if separate gunzip.exe still exists after consulting dr Google.

[AQUAR]

Still trying to get past this Cmake error.

Problem is presented as:
CMake Error at C:/AvidBuild/msys/home/John/trunk/cmake/admFFmpegUtil.cmake:2 (FILE):
  file failed to open for reading (Invalid argument):

admFFmpegUtil.cmake:2 is a line in a macro:
MACRO (getFfmpegVersionFromHeader description headerFile definition ffmpegVersion)
   FILE(READ "${headerFile}" FFMPEG_H)
   STRING(REGEX MATCH "#define[ ]+${definition}[ ]+([0-9]+)" FFMPEG_H "${FFMPEG_H}")
   STRING(REGEX REPLACE ".*[ ]([0-9]+).*" "\\1" ${ffmpegVersion} "${FFMPEG_H}")
ENDMACRO (getFfmpegVersionFromHeader)

The variable called "headerfile" holds the following path name:
C:/AvidBuild/msys/home/John/trunk/install/C:/AvidBuild/msys/include/avidemux/2.6/libavcodec/version.h
(don't know how to interpret this unix path, but it appears to be short hand for 2 actual windows paths)

The header file "version.h" exists in these two windows folder:
C:\AvidBuild\msys\home\John\trunk\install\AvidBuild\msys\include\avidemux\2.6\libavcodec
C:\AvidBuild\msys\include\avidemux\2.6\libavcodec

It seems to me that:
Either syntax in the macro is not understood by Cmake (unlikely) or
That unix path name is problematical in a unix shell simulation under windows or
Who knows?

Also replacing ${headerFile} with an absolute path to either version.h header file ,breaks the build process.
Kind of expected that but worth a try. 

[Jan Gruuthuse]

Possible cmake version issue? Can't tell my used version. Probably 2.8.10? I'll be back next week.
See reply by ajschult in CPack Error earlier.

[AQUAR]

I am using Cmake-3.1.0-rc1-win32-x86.
If the code requires the earlier/stable release of Cmake, then hopefully that is the root of the problems I am getting.

Easy enough to test it out.

[Jan Gruuthuse]

Hope lower version solves issues. rc (release candidate) is always a warming for me.

[AQUAR]

I am Dling V2.8.10.2 and V2.8.9 and will see how these versions behave.

Update:
Same result with cmake V2.8.9.
I wonder if its some windows access issue.
Interestingly, with cmake V2.8.9 the extern "C" problem (mentioned earlier) is gone.
(surely cmake has no impact on how g++ interprets cpp code!).

Also running bootstrap.bash --without-qt --without-plugins will complete the core build.
But, just --without-qt or just --without-plugins and Cmake gives the same error.
So I am half way there (just need qt and plugins to get past this read error!). 

[AQUAR]

Just a question:
Is the normal build environment on 32 bit Linux or 64 bit Linux?
I am obviously doing this on 64 bit windows, but could try 32 bit (simplify locations of executables).

[mean]

all are supported

[AQUAR]

Thanks mean.

There is a thread here that presents the same read error,
viz http://avidemux.org/smuf/index.php/topic,10702.0.html - reply 13.
From what I can glean - the issue seems to have been resolved by going to Cmake 2.8.
But, Ive tried 2.8.7 and up to the latest RC but that hasn't resolved the read error.
So something else must also be at play here - maybe the version of GCC?.
Again I've tried some versions of GCC - currently using 4.9.2 - all giving the same read error result.

If some members can give me some combinations of GCC/Cmake that works for them, I'll try it out.

Another observation:
admFFmpegUtil.cmake has this read statement FILE(READ "${headerFile}" FFMPEG_H)
When the variable "headerfile" holds a normal (proper!) absolute path to some version.h header file, everything proceeds fine.
But when it gets to the libavcodec version.h file this variable has a (to me!) strange path name viz,
there are actually two C:\ entries in the one path (on windows that isn't proper as C:\ is a device root directory!).
Almost seems like that this variable isn't wiped/cleared properly?
I presumed it was a unix shorthand for 2 path names but haven't been able to verify that.

[AQUAR]

I've verified that the read error is due to the strange path name (ie with rogue extra C:) .

By trapping that strange path name and replacing it with the proper path name and running bootstrap.bash --without-core --without-plugins the build process reads the version.h file and the process moves on.
It fails at the next issue viz Cmake_Install_Prefix does not including some folder/file (probably another misnamed directory path!).

Starting to think Cmake is borked with the MSYS generator.

[AQUAR]

Try 2 continued.

Well, the good news is that I can "sort of" build an avidemux with Mingw W64 and MSYS on windows 7 - 64 bit.
The bad new is that it fails to playback the video files (but renders the individual frames) and I've broken the process.
The install directory has become fragmented and missing various run time libraries (from the package depenencies).
Not tried anything else with frankenADM!

Please note: I am way out of my depth with going through the code and attempting to bypass issues, any help would be most welcome.

The strange path name issue:
The MSYS shell echo's these 2 lines
AVIDEMUX_SEARCH_INCLUDE_DIR: C:/AvidBuild/msys/home/John/trunk/install/C:/AvidBuild/msys/include
AVIDEMUX_SEARCH_LIB_DIR    : C:/AvidBuild/msys/home/John/trunk/install/C:/AvidBuild/msys
Note the extra C:/ in the path name that causes trouble during the building of QT and Plugins.
These Cmake variables are set in the adminstallDir.cmake cmake file and are to do with the fake root install folder.
This is the code:

Code Select Expand

IF(NOT FAKEROOT)
SET(AVIDEMUX_FAKEROOT "")
else(NOT FAKEROOT)
SET(AVIDEMUX_FAKEROOT "${FAKEROOT}/")
endif(NOT FAKEROOT)
SET(AVIDEMUX_SEARCH_INCLUDE_DIR ${AVIDEMUX_FAKEROOT}${AVIDEMUX_INCLUDE_DIR})
SET(AVIDEMUX_SEARCH_LIB_DIR     ${AVIDEMUX_FAKEROOT}${AVIDEMUX_LIB_DIR})

These paths variables are responsible for the read error later on in the building (at least under windows!) simply because they append 2 path names together starting with the same root directory "C:/", and that doesn't resolve under windows (probably okay with the linux virtual directory approach). I presumed that MSYS would take care of these pathing differences but it seems not.

After a quick study of Cmake, there is this REGEX REPLACE command that lets me get rid of the extra C:/ viz;

Code Select Expand

IF(NOT FAKEROOT)
SET(AVIDEMUX_FAKEROOT "")
else(NOT FAKEROOT)
SET(AVIDEMUX_FAKEROOT "${FAKEROOT}/")
endif(NOT FAKEROOT)
STRING(REGEX REPLACE "C:/" "" AVIDEMUX_INCLUDE_DIR ${AVIDEMUX_INCLUDE_DIR})
STRING(REGEX REPLACE "C:/" "" AVIDEMUX_LIB_DIR ${AVIDEMUX_LIB_DIR})
SET(AVIDEMUX_SEARCH_INCLUDE_DIR ${AVIDEMUX_FAKEROOT}${AVIDEMUX_INCLUDE_DIR})
SET(AVIDEMUX_SEARCH_LIB_DIR     ${AVIDEMUX_FAKEROOT}${AVIDEMUX_LIB_DIR})


Doing this the build still fails by pointing to the wrong "AVIDEMUX_INCLUDE_DIR" in the fake root directory.
So I have to build core first, relocate that folder to where it is pointed to, then proceed with building QT/Plugins.
Even then its inconsistent in what it will build?
Removing the "C:/" is probably akin to deleting a path layer and causes these issues.

[AQUAR]

Try 2 continued  .

. Since the build process complained about using an older version of C, I've updated the Mingw package.
  It now uses gcc version 4.9.2

. Whilst doing build trials, I regressed to Cmake version 2.8.0 (made no difference except something about fakeroot!).
  I've now reverted back to Cmake 2.8.10v2.

Thankfully the build process now actually generates a working avidemux (of course still with the fiddles mentioned).

Next, how to compile in the optional audio and video encoders.
The wiki does have some older stuff on this, but no idea if that is still appropriate.