[ovs-dev] [PATCH] m4: Fix 32bit build with 64bit version of libunwind-dev installed.

Ilya Maximets i.maximets at ovn.org
Tue Oct 1 17:29:41 UTC 2019

On 01.10.2019 19:56, Ben Pfaff wrote:
> On Tue, Oct 01, 2019 at 07:46:10PM +0300, Ilya Maximets wrote:
>> On 01.10.2019 19:17, Ben Pfaff wrote:
>>> On Tue, Oct 01, 2019 at 02:22:20PM +0300, Ilya Maximets wrote:
>>>> 32 and 64 bit versions of libunwind-dev package can not be installed
>>>> at the same time at least in Debian and Ubuntu.  AC_CHECK_LIB macro
>>>> doesn't know if we have '-m32' in OVS_CFLAGS, so we need to
>>>> additionally check for actual compiling possibility before enabling
>>>> the feature.  Otherwise 'make' will fail due to inability to
>>>> build with 64bit libunwind headers:
>>>>       https://travis-ci.org/openvswitch/ovs/jobs/590580374
>>>>       /usr/include/libunwind.h:23:28: fatal error:
>>>>           libunwind-x86.h: No such file or directory
>>>> CC: William Tu <u9012063 at gmail.com>
>>>> Fixes: e2ed6fbeb18c ("fatal-signal: Catch SIGSEGV and print backtrace.")
>>>> Signed-off-by: Ilya Maximets <i.maximets at ovn.org>
>>> I think there's some confusion here on the use of options.  CFLAGS is
>>> for the user, OVS_CFLAGS is for the OVS configure script to use itself.
>>> .cirrus.yml and .travis/linux-build.sh are setting OVS_CFLAGS, but they
>>> should not because they are the "user", not the configure script.  If
>>> they set CFLAGS, instead, I believe that there would be no problem here.
>>> See commit 95626395a3db ("build: Respect CFLAGS and LDFLAGS passed to
>>> make") and the documentation it references.
>> That's an interesting point.
>> However, 'configure' script makes decision about building with libunwind
>> and it needs to know  if we're going to build 32 or 64 bit binary to
>> enable or disable the feature. Setting CFLAGS for configure script breaks
>> it in a following way:
>> $ CFLAGS='-m32' ./configure
>> ...
>> checking for gcc... gcc
>> checking whether the C compiler works... no
> Is this because the 32-bit C library isn't installed?  It should be easy
> to fix with "sudo dnf install glibc-devel.i686" or the distro-specific
> equivalent.

Yes, you're right. It works after installation of gcc-multilib.

I'll think about how to rework CI scripts tomorrow.

> I don't see how it's reasonable to run "configure" with a toolchain
> different from the one we're going to use for building.  Adding -m32
> changes the ABI and the API.
> My usual way to do this is actually to use CC="gcc -m32".  That way the
> -m32, which is important, can't get separated at all!

More information about the dev mailing list