Mark Banner (:standard8) Reporter
	Description • 12 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

	Christian Holler (:decoder)
	Comment 2 • 12 years ago

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?

	Octoploid
	Comment 3 • 12 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"

	Octoploid
	Comment 4 • 12 years ago

This (naïve) patch fixes the problem for me.

	Steve Fink [:sfink] [:s:]
	Comment 6 • 12 years ago

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?

	(not currently active) Ted Mielczarek
	Comment 7 • 12 years ago

mozconfigs are sourced by the toplevel configure, so that Just Works there.

	xunxun
	Comment 8 • 11 years ago

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

	Mike Hommey [:glandium] Assignee
	Comment 9 • 11 years ago

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.

	(not currently active) Ted Mielczarek
	Comment 10 • 11 years ago

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?

	Mike Hommey [:glandium] Assignee
	Comment 11 • 11 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)

	Mike Hommey [:glandium] Assignee
	Comment 12 • 11 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

	Mike Hommey [:glandium] Assignee
	Comment 13 • 11 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/b362e45c17cb

	Ryan VanderMeulen [:RyanVM]
	Comment 14 • 11 years ago

https://hg.mozilla.org/mozilla-central/rev/b362e45c17cb