This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 46712 - btls fails to build with gcc is v4.4.7 or earlier as they lack alignof/alignas
Summary: btls fails to build with gcc is v4.4.7 or earlier as they lack alignof/alignas
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: misc (show other bugs)
Version: Trunk
Hardware: PC Linux
: Low minor
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-11-10 14:45 UTC by Robert van der Boon
Modified: 2017-01-04 19:01 UTC (History)
4 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
configure.ac.patch (1.34 KB, patch)
2016-12-13 13:21 UTC, Robert van der Boon
Details | Diff

Description Robert van der Boon 2016-11-10 14:45:42 UTC
I've got a redhat 6.6 machine that I use to build mono, which has gcc 4.4.7 as the /usr/bin/gcc. (As this is a company machine I can't do a system update to a newer gcc version.)
Since 4.8 I need to specify --enable-btls=no on the configure command line, otherwise I'll get failures building the boringssl part. I gather this is because gcc 4.4.7 is not C++11 compliant and is missing some necessary header files (it complains about stdalign.h missing).

If I change my environment to use my GCC 5.2.0 from /usr/local/gcc-5.2.0 (by setting PATH, CPATH, LD_LIBRARY_PATH, and LIBRARY_PATH) I see that this version used by the rest of the mono build, but the btls build will still try to use gcc 4.4.7. I think this is because the btls part is using CMAKE, and configure/make does not tell cmake that it should use non-default CC/CXX compilers.

The result is that for redhat6 I have to specify --enable-btls=no to get mono to compile even while having a compiler version available with which it could be compiled successfully.


Configure should:
- change --enable-btls to 'no' when a compiler is used that isn't supported, and
- Add two -D to the cmake command line: -DCMAKE_C_COMPILER=${CC} -DCMAKE_CXX_COMPILER=${CXX}
  so that the mono build of btls uses the same CC/CXX as the rest of mono.
Comment 1 Miguel de Icaza [MSFT] 2016-11-28 02:28:20 UTC
you might want to find a way to express these macros for older GCCs:

alignas(x)
alignof(x)

From the source that uses it, there is a fallback for MS C++, something similar might exist in some form or shape in GCC 4.4.7:

#if defined(_MSC_VER)
#if !defined(__cplusplus) || _MSC_VER < 1900
#define alignas(x) __declspec(align(x))
#define alignof __alignof
#endif
#else
#include <stdalign.h>
#endif
Comment 2 Robert van der Boon 2016-11-28 08:06:57 UTC
For me most important is that the compilation of BTLS uses the same gcc as the compilation of Mono, I actually do not _want_ to compile with gcc 4.4.7, it's just that the btls code always is (while the mono code respects path settings).

My situation is:
/usr/bin/gcc                   v4.4.7
/usr/local/gcc-5.2.0/bin/gcc   v5.2.0

I set my path/libpath/etc to 5.2.0.

Running configure/autoconf picks up gcc 5.2.0, so the mono code is built using gcc 5.2.0 (just as I intended).
Building mono with Btls calls into CMake, for CMake to generate the Makefiles used to build Btls. CMake resolves gcc to /usr/bin/gcc, as it does not respect the path. And thus Btls is attempted to build with gcc 4.4.7, which is not what I want.

Of course being able to compile BTLS with gcc 4.4.7 is good (thanks for the hint, I'll try sometime this week), will let you know how that goes. (It seems I need __attribute__((aligned(x))) and __alignof__.)
Comment 3 Robert van der Boon 2016-11-28 11:10:11 UTC
Tested with the alignof settings, which didn't work (as it failed somewhere else). I've checked the external/boringssl/BUILDING.md, an it states that building with 4.8+ is supported. As far as I'm concerned I am not going to try building with GCC 4.4.7 any further.
The issue that the btls part does not use the configured gcc, but always the system default, still stands.
Comment 4 Robert van der Boon 2016-11-28 12:13:24 UTC
When I do the following between "autogen.sh" and "make" then mono and btls line up again:
CC=`which gcc`
CXX=`which c++`
sed -i -e "s@^BTLS_CMAKE_ARGS =  -DBTLS_ARCH=@BTLS_CMAKE_ARGS = -DCMAKE_C_COMPILER=${CC} -DCMAKE_CXX_COMPILER=${CXX} -DBTLS_ARCH=@g" mono/btls/Makefile

i.e. I manually fix up the btls makefile to pass the paths to gcc/c++ to CMake so that it generates makefiles with the proper paths in build-shared. I assume this can be incorporated in autoconf/automake somehow, but that is beyond me.
Comment 5 Robert van der Boon 2016-12-13 13:21:44 UTC
Created attachment 18869 [details]
configure.ac.patch

This patch:
- disables BTLS when using GCC < 4.4.7
- passes the CC/CXX full paths to BTLS CMake to ensure that CMake is using the same CC/CXX as the mono build does.

This plays nice with the RedHat/CentOS/Fedora Software Collection List support as well.
Comment 6 Robert van der Boon 2016-12-13 13:23:05 UTC
I meant: disables BTLS when using GCC < 4.8
Comment 7 Alexander Köplinger [MSFT] 2017-01-04 19:01:46 UTC
Fixed by https://github.com/mono/mono/pull/4200 in master and mono-4.8.0-branch.

Thanks for the patch, it was very useful. I decided to not use -DCMAKE_C_COMPILER since CMake recommends setting CC instead: https://cmake.org/Wiki/CMake_Useful_Variables#Compilers_and_Tools

I also just check for stdalign.h as that works on Debian 7 as well which still ships with gcc4.7 (and it apparently built fine on our bots there).

Note You need to log in before you can comment on or make changes to this bug.