Mon 30 Jan 2017 04:41:28 PM UTC, comment #9:
Thanks, pushed as 49ad8249663616938ad34edf35825d93a31740ff
|
Mon 30 Jan 2017 03:42:02 PM UTC, comment #8:
From the inconsistencies mentioned in the previous post, I have attached a cosmetic patch `0002_improve-ming-configure-version-consistency.patch`, which rectify these inconsistencies in the configure script.
Note that this patch is not essential, and could be left out without any ill effect.
Gnash: 0.8.11dev (patched against git 37044f9 30-Jan-2017)
GCC: 4.7.2-5 (debian)
G++: 4.7.2-5 (debian)
Ming: 0.4.4-1.1 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
(file #39612)
|
Mon 30 Jan 2017 03:39:14 PM UTC, comment #7:
Current git version of Gnash testsuite is now compiling successfully and showing normaml result, thanks.
Configure, build, and test logs are attached for the record, as `gnashbuildlog.37044f9.zip`. (Note that 2 test failures are expected in my configuration, per bug #47906)
Regarding the sed pattern, I actually went with that simple one on my the first try (s/^0*//), but decided to change it to the submitted one (s/^0*\(.*.\)$/\1/g) after I realized that the simple one tried to strip "00000000" into a blank "" instead of single zero "0".
The simplified pattern:
Pattern from the submitted patch:
You would see that the simple pattern does not handle "00000000" correctly, while the submitted pattern does.
But after testing, this problem turned out not to matter as much as I originally thought; this is because the configure script actually contain a check for empty MING_VERSION_CODE and automatically re-assign it with `00000000`. (Notice that the reassignment and comparisons around there are still using leading zeroes)
Gnash: 0.8.11dev (git 37044f9 30-Jan-2017)
GCC: 4.7.2-5 (debian)
G++: 4.7.2-5 (debian)
Ming: 0.4.4-1.1 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
(file #39611)
|
Mon 30 Jan 2017 08:14:09 AM UTC, comment #6:
Your patch was committed as 04cbec56c6070bef7bafd0763a05921dca1e1d12
My simplification of sed as
37044f9ef5888401b2cfc83df8ae0ceeef6bd37c
|
Mon 30 Jan 2017 07:51:53 AM UTC, comment #5:
Great work, thanks !
I think the sed line could be simplified to 's/^0*//'. I can do that in a separate commit unless you see any reason why it should not work...
|
Sun 29 Jan 2017 01:59:47 PM UTC, comment #4:
From all said in previous posts, following changes need be introduced (on top of culprit commit) to prevent testsuite build error and other version detection anomalies:
- `macros/ming.m4` needs to be changed to trim leading zeroes from `MING_VERSION_CODE` (possibly by passing it through `sed`).
- Leading zeros need to be trimmed from `#if MING_VERSION_CODE` comparison in following files:
- testsuite/actionscript.all/enumerate.as
- testsuite/actionscript.all/Matrix.as
- testsuite/actionscript.all/delete.as
- testsuite/actionscript.all/Try.as
- testsuite/actionscript.all/targetPath.as
- testsuite/actionscript.all/check.as
- testsuite/misc-ming.all/matrix_test.c
- testsuite/misc-ming.all/attachMovieTest.c
- testsuite/misc-ming.all/duplicate_movie_clip_test.c
(One can use `grep -nR MING_VERSION_CODE * | grep -Pi '\.(as|h|cc|cpp|c):'` in Gnash source directory to find all of these, save for the M4 macro)
See the attached `0001_fix-ming-octal-version-inconsistency.patch` for a patch which do these changes. On my machine, this patch allows `make check` to complete with normal results; but not sure if my use of `sed` is portable though.
Alternatively, the ff92e0a commit could be reverted (which works, in spite of the octal number limitation).
Gnash: 0.8.11dev (git ff92e0a 28-Jan-2017)
GCC: 4.7.2-5 (debian)
G++: 4.7.2-5 (debian)
Ming: 0.4.4-1.1 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
(file #39605)
|
Sun 29 Jan 2017 11:32:53 AM UTC, comment #3:
Before commit ff92e0a, things are working fine as long as the value of each digit in Ming's major/minor/micro/prerelease version number does not exceed 7: the C preprocessor can just pretend they are all octal values and still do correct comparisons.
However, when ff92e0a is introduced...
- `./configure` and `Makefile`(s) still do `#define MING_VERSION_CODE 00040400` (equivalent to 16640 in decimal)...
- But some code are now changed to do comparision in decimal:
- ming_utils.h:26: `#if 00040400 >= 40004` now became false (it should have been true).
- ming_utils.h:43: Change has no effect (it's code comment).
- ming_utils.h:45: `#if 00040400 >= 40004` now became false (it should have been true).
- ming_utils.h:56: `#if 00040400 >= 40006` now became false (it should have been true).
From the link error:
A bit deeper inspection reveals that this is a direct result of version interpretation discrepancy between C-preprocessor and configure script:
If libming version is actually less than 0.4.4, `testsuite/misc-ming.all/register_class/Makefile.am` would just exclude the build of `registerClassTest2` test in the configure process, as these libming did not support init action insertion.
But what really happened here is:
Gnash: 0.8.11dev (git ff92e0a 28-Jan-2017)
GCC: 4.7.2-5 (debian)
G++: 4.7.2-5 (debian)
Ming: 0.4.4-1.1 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Sun 29 Jan 2017 10:58:35 AM UTC, comment #2:
From observation under my configuration, `MING_VERSION_CODE` is not defined by libming header, but is defined by `Makefile`(s) as a result of `./configure` process; which is done as follows:
In my configuration, `MING_VERSION_CODE` became `00040400` in Makefile(s); which they, in turn, do something like this:
Which is equivalent to doing this in C-preprocessor:
Then, they are used for things like this in CPP-processed ActionScript and C code:
Gnash: 0.8.11dev (git ff92e0a 28-Jan-2017)
GCC: 4.7.2-5 (debian)
G++: 4.7.2-5 (debian)
Ming: 0.4.4-1.1 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Sun 29 Jan 2017 10:06:12 AM UTC, comment #1:
Since the previous commit is compiled and tested fine. A use of git bisect (36028f4 good -> ff92e0a bad) is redundant, but I still use it anyway...
GCC: 4.7.2-5 (debian)
G++: 4.7.2-5 (debian)
Ming: 0.4.4-1.1 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Sun 29 Jan 2017 10:02:32 AM UTC, original submission:
Yesterday, while I was verifying in-tree correctness of patch #9234; I encountered a build error (link failure) during a `make check` run, which causes the whole testing process to abort. Note that only Gnash testsuite is affected, the Gnash build itself is still installable and functional.
The testsuite build error message is as follows:
My build procedure is as follows:
- `git clean -xdf`
- `git checkout -f`
- `./autogen.sh`
- `CC="ccache gcc" CXX="ccache g++" ./configure --enable-media=ffmpeg,gst --enable-renderer=agg,cairo,opengl --enable-gui=gtk,qt4,sdl,fb,dump --enable-docbook`
- `make`
- `make check`
Full configuration logs, build, and test output are attached as `mingcheckerror.ff92e0a.zip`.
Gnash: 0.8.11dev (git ff92e0a 28-Jan-2017)
GCC: 4.7.2-5 (debian)
G++: 4.7.2-5 (debian)
Ming: 0.4.4-1.1 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
|