Configuring libffi ignores CC/CXX from mozconfig and picks up the system compiler

RESOLVED FIXED in mozilla30

Status

()

Core
Build Config
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: standard8, Assigned: glandium)

Tracking

(Blocks: 1 bug)

unspecified
mozilla30
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
I've been investigating an issue with some of our builds and libffi. As a result, I've noticed that libffi isn't actually picking up the compiler referenced in CC/CXX in the mozconfig, but is picking up the system mozconfig.

So on our Firefox builders, in mozconfig.linux we have:

CC=/tools/gcc-4.5-0moz3/bin/gcc
CXX=/tools/gcc-4.5-0moz3/bin/g++

However, libffi configure is picking "gcc" i.e. the system one, which is actually version 4.1.1.

That doesn't seem quite right, especially as I believe 4.1.1 supports a different default debug symbol set(?).

You can see this happening if you read through the configure lines of any nightly build, e.g. https://tbpl.mozilla.org/php/getParsedLog.php?id=11120042&tree=Firefox&full=1
(Reporter)

Updated

6 years ago
Duplicate of this bug: 748325
I encountered this bug while building with AddressSanitizer (because that requires passing -faddress-sanitizer to the compiler, which gcc won't understand and error out while configuring libffi). I worked around this by using "export CC=...".

I further noticed, that it seems that libffi also doesn't build with -fPIC, and I had to explicitly add that too. Maybe this is somewhat related and libffi ignores more than just CC/CXX?

Comment 3

6 years ago
I'm hitting a similar problem when I use clang to build.
In this case the build fails during configuration:

configuring in ctypes/libffi
running /bin/sh /var/tmp/mozilla-central/js/src/ctypes/libffi/configure  --disable-shared --enable-static --disable-raw-api --with-pic --cache-file=/var/tmp/mozilla-central/moz-build-dir/js/src/ctypes/libffi/config.cache --srcdir=/var/tmp/mozilla-central/js/src/ctypes/libffi
configure: creating cache /var/tmp/mozilla-central/moz-build-dir/js/src/ctypes/libffi/config.cache
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/var/tmp/mozilla-central/moz-build-dir/js/src/ctypes/libffi':
configure: error: C compiler cannot create executables
See `config.log' for more details.
configure: error: /var/tmp/mozilla-central/js/src/ctypes/libffi/configure failed for ctypes/libffi
configure: error: /var/tmp/mozilla-central/js/src/configure failed for js/src
*** Fix above errors and then restart with               "make -f client.mk build"

A simple fix is to add "export CC=$CC" to js/src/configure:

15638       export CC=$CC
15639
15640       echo "running ${CONFIG_SHELL-/bin/sh} $ac_sub_configure $ac_sub_configure_args --cache-file=$ac_sub_cache_file --srcdir=$ac_sub_srcdir"

Comment 4

6 years ago
Created attachment 623053 [details] [diff] [review]
Fix libffi CC problem

This (naïve) patch fixes the problem for me.
Duplicate of this bug: 779333
I think what is happening is that some of the mozconfigs (eg build/unix/mozconfig.linux) only set CC and CXX without exporting them, though others do. And that mostly works because almost all of the configures in the tree share a cache. libffi for some reason uses its own.

So, I see the following ways to fix this:

1. The patch already attached, though I would export CXX too while you're at it.
2. Make all the mozconfigs export CC and CXX
3. Have libffi share the cache (there are probably scary reasons why this isn't already done.)

Btw, how is even the toplevel configure getting CC when it's not exported? Is it sourced by the same shell invocation that sources the mozconfigs or something?
mozconfigs are sourced by the toplevel configure, so that Just Works there.

Updated

5 years ago
Blocks: 809404

Comment 8

4 years ago
Created attachment 759183 [details] [diff] [review]
Make libffi accept MOZ_OPTIMIZE_FLAGS

In my build, I use the patch to make libffi accept MOZ_OPTIMIZE_FLAGS on Windows MSVC build.
(Assignee)

Updated

4 years ago
Blocks: 462427
(Assignee)

Updated

4 years ago
Assignee: nobody → mh+mozilla
Component: js-ctypes → Build Config
(Assignee)

Comment 9

4 years ago
Created attachment 8372182 [details] [diff] [review]
Always export CC, CXX and a few other variables to libffi's configure

Also, always pass --build and --host.


Note the for var in ... thing is stolen from the main configure.in (it's used for jemalloc3)
It avoids exporting and leaking the export in subsequent things happening in configure, which, in this case is nothing, but that block is going to move in bug 969164 and there will, then, be things happening after ffi subconfigure.

This was green on try: https://tbpl.mozilla.org/?tree=Try&rev=0b7329d0b7b3

Note I didn't want to risk it with flags, so i only moved the program variables.

I removed HOST_CC because the ffi build system doesn't do anything with it afaict.
Attachment #8372182 - Flags: review?(ted)
Comment on attachment 8372182 [details] [diff] [review]
Always export CC, CXX and a few other variables to libffi's configure

Review of attachment 8372182 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/configure.in
@@ +4557,5 @@
>      ac_configure_args="$ac_configure_args LD=link CPP=\"cl -nologo -EP\" SHELL=sh.exe"
>      case "${target_cpu}" in
>      x86_64)
>        # Need target since MSYS tools into mozilla-build may be 32bit
> +      ac_configure_args="$ac_configure_args CC=\"$_topsrcdir/js/src/ctypes/libffi/msvcc.sh -m64\""

Above you're passing CC/LD in $ac_configure_args, and then here you're setting them again. Is that going to cause any issues? If nothing else it seems wrong, maybe move the LD/CC bit to an else from the if _MSC_VER?
Attachment #8372182 - Flags: review?(ted) → review+
(Assignee)

Comment 11

4 years ago
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #10)
> Above you're passing CC/LD in $ac_configure_args, and then here you're
> setting them again. Is that going to cause any issues? If nothing else it
> seems wrong, maybe move the LD/CC bit to an else from the if _MSC_VER?

As long as the overrides are coming after, it's fine. I'd rather not make the logic more complex (especially since there are other cases further below in the file)
(Assignee)

Comment 12

4 years ago
And proof it works as intended in the log:
checking for i686-pc-mingw32-gcc... /c/builds/moz2_slave/try-w32-0000000000000000000000/build/js/src/ctypes/libffi/msvcc.sh
(Assignee)

Comment 13

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/b362e45c17cb
https://hg.mozilla.org/mozilla-central/rev/b362e45c17cb
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.