Gst-plugins-base isn't updating

Last night, gst-plugins-base was updated from 0.10.29 to 0.10.30 however, when I merged it on my system, it failed to merge. I was getting QA warnings that were breaking the merge:

 * QA Notice: Package has poor programming practices which may compile
 *            fine but exhibit random runtime failures.
 * libs/tag.c:1086: warning: implicit declaration of function
‘gst_tag_list_from_exif_buffer’
 * libs/tag.c:1111: warning: implicit declaration of function
‘gst_tag_list_to_exif_buffer’
 * libs/tag.c:1127: warning: implicit declaration of function
‘gst_tag_list_to_exif_buffer_with_tiff_header’
 * libs/tag.c:1128: warning: implicit declaration of function
‘gst_tag_list_from_exif_buffer_with_tiff_header’

 * 
 * QA Notice: Package has poor programming practices which may compile
 *            but will almost certainly crash on 64bit architectures.
 * 
 * Function `gst_tag_list_from_exif_buffer' implicitly converted to pointer at
libs/tag.c:1086
 * Function `gst_tag_list_to_exif_buffer' implicitly converted to pointer at
libs/tag.c:1111
 * Function `gst_tag_list_to_exif_buffer_with_tiff_header' implicitly converted
to pointer at libs/tag.c:1127
 * Function `gst_tag_list_from_exif_buffer_with_tiff_header' implicitly
converted to pointer at libs/tag.c:1128

I already knew from the "Why won't the package bypass the QA notice" investigation that this was because I was on a 64-bit machine where treating a pointer as an int is problematic because they are not the same size. However, I wanted to dig deeper and find the actual issue.

I had reports from others on IRC that it merged fine for them even though they were on 64-bit as well. I tend to run with FEATURES="test" for Portage. This causes Portage to run the test suite of the package being installed. This was why the others were not running into the issue. The problematic code was in the tests, not in the main application. Because this was exif, tag, and tiff related, I removed libexif, tiff, and gst-plugins-taglib, but those weren't the issue.

The prior night I had discovered in the gst-plugins-base-0.10.30 release notes that the functions mentioned were new additions. This smelled like it was grabbing the installed headers instead of the headers in the source. Because C defaults to declarations being int, having missing declarations in the 0.10.29 headers would result in the pointers and ints implicit casting. I tested this out by unmerging gst-plugins-0.10.29 so there were no headers on the system and then merged gst-plugins-0.10.30. This worked. So now I had a workaround but not an actual solution.

Eventually, I triggered a build of gst-plugins-base outside of Portage so that I could pass in V=1 and get the verbose build steps. Sure enough, the include order was messed up:

x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../..    -pthread
-I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/libxml2   -I../../gst-libs
-I../../gst-libs -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/libxml2    -DG_THREADS_MANDATORY
-DG_DISABLE_CAST_CHECKS -Wall -Wdeclaration-after-statement -Wvla
-Wpointer-arith -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls
-Wundef -Wwrite-strings -Wformat-nonliteral -Wformat-security -Winit-self
-Wmissing-include-dirs -Waddress -Waggregate-return -Wno-multichar
-Wnested-externs   -g    -pthread -I/usr/include/gstreamer-0.10
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2  
-DGST_TEST_FILES_PATH="\"../../tests/files\"" -march=native -pipe -g
-fstack-protector-all -O2 -MT libs_tag-tag.o -MD -MP -MF .deps/libs_tag-tag.Tpo
-c -o libs_tag-tag.o `test -f 'libs/tag.c' || echo './'`libs/tag.c

Sure enough, the include order was messed up. tests/check/libs/tag.c was including <gst/tag/tag.h>. Because it was in between < and >, it comes out of the system-specified path instead of being a relative path. The path sequence formed by the -I compiler argument consisted of . and ../.. to start, but there is no gst/tag/tag.h in those. However, there is a gst/tag/tag.h in /usr/include/gstreamer-0.10 when gst-plugins-base is already merged. That's where it includes form instead of ../../gst-libs which is the correct location further on.

I then pulled up the Makefile.am for that directory and found this:

libs_tag_CFLAGS = \
        $(GST_BASE_CFLAGS) \
        $(GST_PLUGINS_BASE_CFLAGS) \
        $(AM_CFLAGS)

This seemed to be the problem. Other tests had $(GST_BASE_CFLAGS) and $(GST_PLUGINS_BASE_CFLAGS) in opposite orders. I manually swapped these around and ran autoreconf. This fixed the issue. I followed up upstream and found that the same change had been made in http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=5f5c52cbc5ccbfba662c24619f4ba6ce7ae815a3. I also reported my finding to Gentoo developers at https://bugs.gentoo.org/show_bug.cgi?id=346089.