After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 664606 - vala testsuite fails on multilib builds as it drops CFLAGS
vala testsuite fails on multilib builds as it drops CFLAGS
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: general
0.14.x
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2011-11-23 02:52 UTC by Nathan Phillip Brink (binki)
Modified: 2012-02-01 15:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
buildscript-0.14.0-74-gd03557e.txt (91.98 KB, text/plain)
2011-11-23 02:52 UTC, Nathan Phillip Brink (binki)
  Details
vala--0.14.0-74-gd03557e-testsuite-CFLAGS.patch (1.67 KB, patch)
2011-11-23 03:03 UTC, Nathan Phillip Brink (binki)
none Details | Review

Description Nathan Phillip Brink (binki) 2011-11-23 02:52:21 UTC
Created attachment 201963 [details]
buildscript-0.14.0-74-gd03557e.txt

When vala is built with CFLAGS=-m32 and PKG_CONFIG_LIBDIR="/usr/lib32/pkgconfig:/usr/share/pkgconfig" to get the 32-bit versions of libs and headers, the error in the attached buildscript is encountered when running the testsuite (not to mention the numerous parallel build errors). This build error happens because the testsuite ignores CFLAGS, causing GCC to enter 64-bit mode, when invoking VALAC. Yet, because PKG_CONFIG_LIBDIR is set for 32-bit building, the C code produced by valac is compiled against glib's 32-bit headers. This causes the usual following error:

/usr/include/glib-2.0/glib/gthread.h:347:3: error: size of unnamed array is negative

This error is produced because glib is checking the sanity of ABI compatibility between its headers and the mode gcc is in, producing a negative index for an array dereference to prevent the compilation from proceeding.

An example of how to get pkg-config to behave properly when compiling 32-bit code on a multilib amd64 machine:

ohnobinki@ohnopublishing ~/vala $ pkg-config --cflags glib
-I/usr/include/glib-1.2 -I/usr/lib64/glib/include  
ohnobinki@ohnopublishing ~/vala $ PKG_CONFIG_LIBDIR="/usr/lib32/pkgconfig:/usr/share/pkgconfig" pkg-config --cflags glib
-I/usr/include/glib-1.2 -I/usr/lib32/glib/include
Comment 1 Nathan Phillip Brink (binki) 2011-11-23 03:03:07 UTC
Created attachment 201964 [details] [review]
vala--0.14.0-74-gd03557e-testsuite-CFLAGS.patch

This patch fixes the compilation problem shown in attachment 201963 [details] for me by respecting CFLAGS, LDFLAGS, and CPPFLAGS when compiling a vala program in the testsuite.
Comment 2 Luca Bruno 2011-11-23 15:05:23 UTC
Thanks for your patch. Why should we honor CPPFLAGS?
Comment 3 Nathan Phillip Brink (binki) 2012-02-01 14:24:34 UTC
(In reply to comment #2)
> Thanks for your patch. Why should we honor CPPFLAGS?

See
  $ info '(automake1.11) Standard Configuration Variables'

Since valac invokes the C compiler driver on the generated C files, the C compiler driver in turn invokes the preprocessor, compiler, assembler, and linker in turn. A user building vala may need to specify a preprocessor-specific flag, such as -I or -D, for the generated C code to be compiled successfully. These flags belong in CPPFLAGS. If CPPFLAGS is arbitrarily ignored by the testsuite script when automake uses it everywhere else in its own build rules, certain testsuite failure errors caused by ignoring CPPFLAGS may be confusing to the user.

Maybe I don't see your point; why should one not honor CPPFLAGS?
Comment 4 Luca Bruno 2012-02-01 14:37:00 UTC
(In reply to comment #3)
> Maybe I don't see your point; why should one not honor CPPFLAGS?

Because it's C code, not C++?
Comment 5 Luca Bruno 2012-02-01 14:40:17 UTC
Sorry, my mistake. I recognized that as CXXFLAGS. CPPFLAGS is obviously fine.
Comment 6 Luca Bruno 2012-02-01 15:02:42 UTC
commit 224a2fcb750aca13e917b3319dc8985ce5fde2e9
Author: Nathan Phillip Brink <binki@gentoo.org>
Date:   Wed Nov 23 02:57:23 2011 +0000

    tests: Honor CFLAGS, LDFLAGS, and CPPFLAGS
    
    Fixes bug 664606.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.