Closed Bug 1262155 Opened 8 years ago Closed 8 years ago

Stop using libffi's autoconf build system

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox48 affected, firefox52 fixed)

Status:
RESOLVED FIXED
Milestone:
mozilla52
Tracking Flags:
Tracking Status
firefox48 --- affected
firefox52 --- fixed

People

(Reporter: ted, Assigned: chmanchester)

References

Details

Attachments

(3 files, 4 obsolete files)

Bug 1262155 - Always pass defines when compiling SOBJS.
58 bytes, text/x-review-board-request
ted
: review+
Details
Bug 1262155 - Add some generic compiler-based conditions to moz.configure.
58 bytes, text/x-review-board-request
ted
: review+
Details
Bug 1262155 - Use moz.build instead of libffi's build system.
58 bytes, text/x-review-board-request
glandium
: review+
Details 
I did this in bug 1239083 for ICU, and I'd like to do it again for libffi.
Chris: we talked about this at the build meeting Thursday.
Assignee: nobody → cmanchester
Attachment #8784169 - Flags: review?(ted)
Attachment #8784170 - Flags: review?(ted)
Attachment #8784171 - Flags: review?(ted)
Attachment #8784172 - Flags: review?(ted)
Attachment #8784173 - Flags: review?(ted)
Attachment #8784174 - Flags: review?(ted)
Comment on attachment 8784169 [details]
Bug 1262155 - Always pass defines when compiling SOBJS.

https://reviewboard.mozilla.org/r/73716/#review71550

::: config/config.mk:334
(Diff revision 1)
>  
>  COMPILE_CFLAGS	= $(VISIBILITY_FLAGS) $(DEFINES) $(INCLUDES) $(OS_INCLUDES) $(DSO_CFLAGS) $(DSO_PIC_CFLAGS) $(RTL_FLAGS) $(OS_COMPILE_CFLAGS) $(_DEPEND_CFLAGS) $(CFLAGS) $(MOZBUILD_CFLAGS)
>  COMPILE_CXXFLAGS = $(if $(DISABLE_STL_WRAPPING),,$(STL_FLAGS)) $(VISIBILITY_FLAGS) $(DEFINES) $(INCLUDES) $(OS_INCLUDES) $(DSO_CFLAGS) $(DSO_PIC_CFLAGS) $(RTL_FLAGS) $(OS_COMPILE_CXXFLAGS) $(_DEPEND_CFLAGS) $(CXXFLAGS) $(MOZBUILD_CXXFLAGS)
>  COMPILE_CMFLAGS = $(OS_COMPILE_CMFLAGS) $(MOZBUILD_CMFLAGS)
>  COMPILE_CMMFLAGS = $(OS_COMPILE_CMMFLAGS) $(MOZBUILD_CMMFLAGS)
> -ASFLAGS += $(MOZBUILD_ASFLAGS)
> +ASFLAGS += $(DEFINES) $(MOZBUILD_ASFLAGS)

This should be added to the SOBJS rule in rules.mk, not to global ASFLAGS. (.s assembler sources are not preprocessed, and produce ASOBJS ; .S assembler sources are preprocessed, and produce SOBJS)
Ted: the last patch in this series has most of the meat in it, looking at that first might make sense. The earlier ones are small prerequisites.
Attachment #8784188 - Attachment is obsolete: true
Attachment #8784188 - Flags: review?(ted)
Awesome! I'll take a look at these tomorrow.
Comment on attachment 8784174 [details]
Bug 1262155 - Use moz.build instead of libffi's build system.

https://reviewboard.mozilla.org/r/73726/#review71572

::: config/external/ffi/moz.build:20
(Diff revision 4)
> +    ffi_h = CONFIGURE_SUBST_FILES['/js/src/ctypes/libffi/include/ffi.h']
> +    ffi_h.local_substs.update({
> +        'TARGET': CONFIG['FFI_TARGET'],
> +        'FFI_EXEC_TRAMPOLINE_TABLE': '0',
> +    })

I'd rather go with a GENERATED_FILES here, rather than add "local_substs" to CONFIGURE_SUBST_FILES (we should reduce the number of CONFIGURE_SUBST_FILES, btw)
Attachment #8784173 - Attachment is obsolete: true
Attachment #8784173 - Flags: review?(ted)
Comment on attachment 8784172 [details]
Bug 1262155 - Allow specifying a custom suffix for the test program generated by try_invoke_compiler.

https://reviewboard.mozilla.org/r/73722/#review72780
Attachment #8784172 - Flags: review?(ted) → review+
Comment on attachment 8784170 [details]
Bug 1262155 - Add some generic compiler-based conditions to moz.configure.

https://reviewboard.mozilla.org/r/73718/#review72784

::: build/moz.configure/toolchain.configure:769
(Diff revision 5)
>                               other_compiler=cxx_compiler,
>                               other_c_compiler=c_compiler)
>  
> +# Generic compiler-based conditions.
> +non_msvc_compiler = depends(c_compiler)(lambda info: info.type != 'msvc')
> +building_with_gcc = depends(c_compiler)(lambda info: info.type == 'gcc')

I'm surprised this is the first time we've needed this!
Comment on attachment 8784170 [details]
Bug 1262155 - Add some generic compiler-based conditions to moz.configure.

https://reviewboard.mozilla.org/r/73718/#review72786
Attachment #8784170 - Flags: review?(ted) → review+
Comment on attachment 8784169 [details]
Bug 1262155 - Always pass defines when compiling SOBJS.

https://reviewboard.mozilla.org/r/73716/#review72826

Heh, I totally worked around the same issue with part of my ICU work:
https://dxr.mozilla.org/mozilla-central/source/config/external/icu/data/moz.build#21
Attachment #8784169 - Flags: review?(ted) → review+
Comment on attachment 8784171 [details]
Bug 1262155 - Add some generic compiler-based conditions to moz.configure.

https://reviewboard.mozilla.org/r/73720/#review72828

This could stand an additional unit test:
https://dxr.mozilla.org/mozilla-central/rev/1a5b53a831e5a6c20de1b081c774feb3ff76756c/python/mozbuild/mozbuild/test/configure/test_compile_checks.py#98

::: build/moz.configure/compile-checks.configure:19
(Diff revision 5)
>  #   test program. `return 0;` is appended to the function body automatically.
>  # - `language` is the language selection, so that the appropriate compiler is
>  #   used.
>  # - `flags` are the flags to be passed to the compiler, in addition to `-c`.
>  # - `check_msg` is the message to be printed to accompany compiling the test
>  #   program.

Add `prelude` to the docs in the comment here.

::: build/moz.configure/compile-checks.configure:22
(Diff revision 5)
>  # - `flags` are the flags to be passed to the compiler, in addition to `-c`.
>  # - `check_msg` is the message to be printed to accompany compiling the test
>  #   program.
>  @template
> -def try_compile(includes=None, body='', language='C++', flags=None, check_msg=None):
> +def try_compile(includes=None, body='', language='C++', flags=None, check_msg=None,
> +                prelude=None):

This formatting is a little wonky. Maybe reformat all the params at this point? I don't know what our Python style guide says about this (if it says anything).
Attachment #8784171 - Flags: review?(ted) → review+
Comment on attachment 8784174 [details]
Bug 1262155 - Use moz.build instead of libffi's build system.

https://reviewboard.mozilla.org/r/73726/#review72838

I have a bunch of comments here, but nothing I would block landing on. I do think you should have glandium give the ffi.configure bits a once-over to determine if we need to run those checks or if we could just hardcode the answers.

::: build/autoconf/ffi.m4:12
(Diff revision 5)
> -  if test "$BUILD_CTYPES" -a -z "$MOZ_SYSTEM_FFI"; then
> +if test "$BUILD_CTYPES" -a -z "$MOZ_SYSTEM_FFI"; then
> -    # Run the libffi 'configure' script.
> -    ac_configure_args="--disable-shared --enable-static --disable-raw-api"
> -    if test "$MOZ_DEBUG"; then
> -      ac_configure_args="$ac_configure_args --enable-debug"
> -    fi
> +
> +HAVE_LONG_DOUBLE=0
> +if test -z "$CROSS_COMPILE"; then
> +  AC_CHECK_SIZEOF(double)
> +  AC_CHECK_SIZEOF(long double)

Can you not move this to moz.configure yet? (Presumably we don't have an equivalent to AC_CHECK_SIZEOF?) Alternately: I bet you could just hardcode the answer on all the platforms we care about. Sounds like on gcc/x86 it's always true, but on msvc/x86 it's not:
https://en.wikipedia.org/wiki/Long_double

::: build/autoconf/ffi.m4:22
(Diff revision 5)
> -      esac
> -    fi
> +fi
> +AC_SUBST(HAVE_LONG_DOUBLE)
>  
> -    # Use a separate cache file for libffi, since it does things differently
> -    # from our configure.
> +if test "$MOZ_BUILD_APP" = js; then
> +  AC_CHECK_FUNCS(mmap memcpy)

Can you file a followup for moving the rest of this to moz.configure?

::: build/moz.configure/ffi.configure:45
(Diff revision 5)
> +    set_config('FFI_%s' % name, check)
> +
> +# Invokes the given compiler command and returns the compilation result
> +# as a string.
> +# Returns None when the compiler invocation fails in some way.
> +# If `path` is given, the output will be written to the given path and

nit: out_path

::: build/moz.configure/ffi.configure:50
(Diff revision 5)
> +# If `path` is given, the output will be written to the given path and
> +# will be available to the caller after this function runs.
> +@imports('os')
> +@imports('tempfile')
> +@imports(_from='__builtin__', _import='open')
> +def check_compiled_output(compiler_info, prog, out_path=None, flags=None, **kwargs):

This seems like it could go in compile-checks.configure or somewhere more generic.

::: build/moz.configure/ffi.configure:84
(Diff revision 5)
> +            except:
> +                pass
> +
> +
> +@depends_when(c_compiler, when=building_with_gcc)
> +@checking('whether .eh_frame section should be read-only',

Does anything actually break if we just skip doing this test and hardcode the answer as READONLY? I can't find good information online as to whether this is a common thing or not, perhaps glandium would know.

::: build/moz.configure/ffi.configure:125
(Diff revision 5)
> +
> +set_ffi_build_var('EH_FRAME_FLAGS', eh_frame_flags)
> +
> +
> +@depends_when(c_compiler, when=building_with_gcc)
> +@checking('for __attribute__((visibility("hidden")))')

It doesn't look like we're actually bothering to test for this anymore, we just hardcode the answer when using GCC on non-Windows:
https://dxr.mozilla.org/mozilla-central/rev/1a5b53a831e5a6c20de1b081c774feb3ff76756c/old-configure.in#1362

Presumably we require a GCC new enough that it's not a problem.

::: build/moz.configure/ffi.configure:242
(Diff revision 5)
> +
> +
> +# Target selection, based on ffi/configure.ac.
> +@depends(target)
> +def ffi_target(target):
> +    target_dir = 'x86'

It doesn't seem quite right to use 'x86' for target_dir as the default. Is that what libffi's configure does, or is that a mistranslation?

::: config/external/ffi/Makefile.in:8
(Diff revision 5)
>  # This Source Code Form is subject to the terms of the Mozilla Public
>  # License, v. 2.0. If a copy of the MPL was not distributed with this
>  # file, You can obtain one at http://mozilla.org/MPL/2.0/.
>  
> -ifndef MOZ_SYSTEM_FFI
> -
> +# libffi's assembly files want to be pre-processed, so we still use the libffi
> +# wrapper to combine the preprocessor and assembler stages.

I'd like to see us find a cleaner solution here, but it can be in a followup bug. Just file one and put the bug number here?

::: config/external/ffi/moz.build:18
(Diff revision 5)
> +
> +    CONFIGURE_DEFINE_FILES += [
> +        '../../../js/src/ctypes/libffi/fficonfig.h',
> +    ]
> +    GENERATED_FILES += [
> +        '../../../js/src/ctypes/libffi/include/ffi.h',

This is a little ugly. Any reason you can't just build the code in this directory and tweak anything that's referencing it from the current location to point here instead?

::: config/external/ffi/subst_header.py:13
(Diff revision 5)
> +import buildconfig
> +from mozbuild.preprocessor import Preprocessor
> +
> +def main(output, input_file):
> +    pp = Preprocessor()
> +    pp.context.update({

It's unfortunate that we don't have a built-in way to do this in moz.build.
Attachment #8784174 - Flags: review?(ted) → review+
glandium, can you take a look at the checks I've moved from libffi's configure to ffi.configure in this series? Ted noticed during review at least one that can be assumed based on the compiler versions we require, but there may be others that are obsolete, and I couldn't find a good reference on these. Thank you.
Flags: needinfo?(mh+mozilla)
Comment on attachment 8784174 [details]
Bug 1262155 - Use moz.build instead of libffi's build system.

https://reviewboard.mozilla.org/r/73726/#review73414

::: build/autoconf/ffi.m4:9
(Diff revision 5)
> -    ac_configure_args="--disable-shared --enable-static --disable-raw-api"
> -    if test "$MOZ_DEBUG"; then
> -      ac_configure_args="$ac_configure_args --enable-debug"
> -    fi
> -    if test "$DSO_PIC_CFLAGS"; then
> -      ac_configure_args="$ac_configure_args --with-pic"
> -    fi
> -    for var in AS CC CXX CPP LD AR RANLIB STRIP; do
> +HAVE_LONG_DOUBLE=0
> +if test -z "$CROSS_COMPILE"; then
> +  AC_CHECK_SIZEOF(double)
> +  AC_CHECK_SIZEOF(long double)
> +
> +  if test $ac_cv_sizeof_double != $ac_cv_sizeof_long_double; then
> +    HAVE_LONG_DOUBLE=1
> +    AC_DEFINE(HAVE_LONG_DOUBLE)

ctypes doesn't support long double (cf. js/src/ctypes/typedefs.h not using ffi_type_longdouble). I don't think it's worth bothering with this until it does.

::: build/autoconf/ffi.m4:22
(Diff revision 5)
> -      esac
> -    fi
> +fi
> +AC_SUBST(HAVE_LONG_DOUBLE)
>  
> -    # Use a separate cache file for libffi, since it does things differently
> -    # from our configure.
> +if test "$MOZ_BUILD_APP" = js; then
> +  AC_CHECK_FUNCS(mmap memcpy)

mmap is only needed for dlmalloc.c, which we don't use. HAVE_MEMCPY is only useful when STDC_HEADERS is not defined. But autoconf should be setting it for us from AC_HEADER_STDC for non-Windows, and from an explicit AC_DEFINE for Windows.

So this AC_CHECK_FUNCS is not necessary.

::: build/autoconf/ffi.m4:23
(Diff revision 5)
> -    fi
> +fi
> +AC_SUBST(HAVE_LONG_DOUBLE)
>  
> -    # Use a separate cache file for libffi, since it does things differently
> -    # from our configure.
> -    old_config_files=$CONFIG_FILES
> +if test "$MOZ_BUILD_APP" = js; then
> +  AC_CHECK_FUNCS(mmap memcpy)
> +  AC_FUNC_ALLOCA

libffi only really needs to check for the alloca.h header and have HAVE_ALLOCA_H defined if it does exist. (We can do that in moz.configure now)

::: build/moz.configure/ffi.configure:64
(Diff revision 5)
> +            try:
> +                os.remove(path)
> +            except:
> +                pass

You could leave it to the finally clause to remove the file.

::: build/moz.configure/ffi.configure:102
(Diff revision 5)
> +            os.remove(obj_file)
> +        except:
> +            pass
> +        return
> +
> +    objdump = find_program('objdump')

might as well move OBJDUMP from old-configure.in

::: build/moz.configure/ffi.configure:121
(Diff revision 5)
> +            section_found = True
> +
> +    # Like the ffi build system, assume these are the correct flags.
> +    return '\"aw\"'
> +
> +set_ffi_build_var('EH_FRAME_FLAGS', eh_frame_flags)

It's "a" on all platforms except arm, where it's "aw". (but it's "a" on arm64). Just simpler to test against target.

::: build/moz.configure/ffi.configure:138
(Diff revision 5)
> +        return
> +
> +    if re.search('\.hidden.*foo', result):
> +        return True
> +
> +set_ffi_build_var('HAVE_HIDDEN_VISIBILITY_ATTRIBUTE',

See HAVE_VISIBILITY_HIDDEN_ATTRIBUTE in old-configure.in. We don't check if it's usable anymore. We just assume it is always available on gcc and clang, but not on Windows.

::: build/moz.configure/ffi.configure:141
(Diff revision 5)
> +        return True
> +
> +set_ffi_build_var('HAVE_HIDDEN_VISIBILITY_ATTRIBUTE',
> +                  have_hidden_visibility_attribute)
> +
> +@depends_when(c_compiler, when=non_msvc_compiler)

This likely needs to exclude clang-cl.

::: build/moz.configure/ffi.configure:151
(Diff revision 5)
> +    result = try_invoke_compiler(info.wrapper + [info.compiler] + info.flags,
> +                                 'C', prog_string, flags=flags, suffix='.s',
> +                                 onerror=lambda: None)
> +    return result is not None
> +
> +set_ffi_build_var('HAVE_AS_X86_PCREL', have_as_x86_pcrel)

This is surprisingly true on our windows x86 builds, and you wouldn't find it out here. Anyways, it's just simpler to hard code that it's true on x86 and x86-64 (and it doesn't matter if it's set on windows x64 because it's not ifdefed in the win64 assembly files, only the win32 one)

::: build/moz.configure/ffi.configure:170
(Diff revision 5)
> +                        code_as_prelude=True),
> +              when=non_msvc_compiler)
> +def have_as_cfi_pseudo_op(have_op):
> +    return have_op is not None
> +
> +set_ffi_build_var('HAVE_AS_CFI_PSEUDO_OP', have_as_cfi_pseudo_op)

This is only used in m68k code... I think we can skip that.

::: build/moz.configure/ffi.configure:179
(Diff revision 5)
> +                        'assembler .ascii pseudo-op support'),
> +              when=non_msvc_compiler)
> +def have_as_ascii_pseudo_op(have_op):
> +    return have_op is not None
> +
> +set_ffi_build_var('HAVE_AS_ASCII_PSEUDO_OP', have_as_ascii_pseudo_op)

This and HAS_AS_STRING_PSEUDO_OP are only used in x86/sysv.S. Other files use .ascii without checking for this ifdef, and it's been supported by GNU as since at least the oldest commit in the binutils git history, in 1999. Just set them unconditionally (and, in fact, you only really need .ascii).

::: build/moz.configure/ffi.configure:235
(Diff revision 5)
> +    except:
> +        pass
> +
> +    return result is not None
> +
> +set_ffi_build_var('HAVE_AS_X86_64_UNWIND_SECTION_TYPE',

This is supported since binutils 2.16, released in 2005.

::: build/moz.configure/ffi.configure:254
(Diff revision 5)
> +        target_name = 'X86_DARWIN'
> +    elif target.cpu == 'arm':
> +        target_dir = 'arm'
> +        target_name = 'ARM'
> +    else:
> +        target_name = target.cpu.upper()

considering you're not setting target_dir, you might as well throw an error on non x86, because this is going to be wrong in 99% of the cases that will end up here. And moz.build doesn't have the rules for non arm non x86 anyways. It's probably also not enough for non linux non os non windows. Invite people to use --with-system-ffi. Maybe we should automatically switch to that on unsupported platforms...
Attachment #8784174 - Flags: review-
Flags: needinfo?(mh+mozilla)
Comment on attachment 8784174 [details]
Bug 1262155 - Use moz.build instead of libffi's build system.

https://reviewboard.mozilla.org/r/73726/#review73414

> mmap is only needed for dlmalloc.c, which we don't use. HAVE_MEMCPY is only useful when STDC_HEADERS is not defined. But autoconf should be setting it for us from AC_HEADER_STDC for non-Windows, and from an explicit AC_DEFINE for Windows.
> 
> So this AC_CHECK_FUNCS is not necessary.

Apparently STDC_HEADERS isn't being set on some of our Linux static analysis builds. Something's going wrong, because we have:

17:58:51     INFO -  checking for ANSI C header files... no

and

17:59:25     INFO -  memory/jemalloc/src> checking for ANSI C header files... yes

in the same log.

> See HAVE_VISIBILITY_HIDDEN_ATTRIBUTE in old-configure.in. We don't check if it's usable anymore. We just assume it is always available on gcc and clang, but not on Windows.

This is testing whether `.hidden` is usable, which is not synonymous with `__attribute__((visibility("hidden")))` (it's not usable on our OS X builds).
Comment on attachment 8784174 [details]
Bug 1262155 - Use moz.build instead of libffi's build system.

https://reviewboard.mozilla.org/r/73726/#review73414

> Apparently STDC_HEADERS isn't being set on some of our Linux static analysis builds. Something's going wrong, because we have:
> 
> 17:58:51     INFO -  checking for ANSI C header files... no
> 
> and
> 
> 17:59:25     INFO -  memory/jemalloc/src> checking for ANSI C header files... yes
> 
> in the same log.

These builds are finding the wrong preprocessor...
Attachment #8784170 - Attachment is obsolete: true
Attachment #8784172 - Attachment is obsolete: true
Comment on attachment 8784174 [details]
Bug 1262155 - Use moz.build instead of libffi's build system.

https://reviewboard.mozilla.org/r/73726/#review76874

::: build/moz.configure/ffi.configure:54
(Diff revision 6)
> +@checking('whether .eh_frame section should be read-only',
> +          callback=lambda flags: flags == '\"a\"')

I don't think we should add a @checking message when we essentially hardcode something. We /may/ want to indicate the hardcoded choice in the output, but "Checking blah blah" seems like the wrong wording for those things.

::: build/moz.configure/ffi.configure:65
(Diff revision 6)
> +
> +set_ffi_build_var('EH_FRAME_FLAGS', eh_frame_flags)
> +
> +
> +@depends(target, c_compiler)
> +@checking('for __attribute__((visibility("hidden")))')

As you said yourself, this is not about __attribute__((visibility("hidden")), but about .hidden support in the assembler. But like .eh_frame, we don't actually want a @checking here.

::: build/moz.configure/ffi.configure:67
(Diff revision 6)
> +
> +
> +@depends(target, c_compiler)
> +@checking('for __attribute__((visibility("hidden")))')
> +def have_hidden_visibility_attribute(target, info):
> +    if info.type == 'gcc' and target.os != 'WINNT':

a quick check tells me that the HAVE_HIDDEN_VISIBILITY_ATTRIBUTE check from libffi's configure matches for clang on linux, so this check doesn't match. You probably just want to check that target.kernel not in ('Darwin', 'WINNT').

::: build/moz.configure/ffi.configure:75
(Diff revision 6)
> +set_ffi_build_var('HAVE_HIDDEN_VISIBILITY_ATTRIBUTE',
> +                  have_hidden_visibility_attribute)
> +
> +
> +@depends(target)
> +@checking('whether assembler supports pc related relocs')

likewise here wrt @checking.

::: build/moz.configure/ffi.configure:83
(Diff revision 6)
> +set_ffi_build_var('HAVE_AS_ASCII_PSEUDO_OP', always)
> +
> +set_ffi_build_var('HAVE_AS_STRING_PSEUDO_OP', always)
> +
> +set_ffi_build_var('HAVE_AS_X86_64_UNWIND_SECTION_TYPE', always)

This strikes me as something that should be set in the FFI moz.build. In fact, come to think of it, the same could be said of most if not all the tests above.
Attachment #8784174 - Flags: review?(mh+mozilla)
Comment on attachment 8784174 [details]
Bug 1262155 - Use moz.build instead of libffi's build system.

https://reviewboard.mozilla.org/r/73726/#review76874

> This strikes me as something that should be set in the FFI moz.build. In fact, come to think of it, the same could be said of most if not all the tests above.

I'd like to keep setting FFI_TARGET and FFI_TARGET_DIR here, they're used by multiple moz.builds.
Comment on attachment 8784174 [details]
Bug 1262155 - Use moz.build instead of libffi's build system.

https://reviewboard.mozilla.org/r/73726/#review78358

::: build/moz.configure/ffi.configure:56
(Diff revision 7)
> +set_config('FFI_TARGET', delayed_getattr(ffi_target, 'name'))
> +set_config('FFI_TARGET_DIR', delayed_getattr(ffi_target, 'dir'))

These two could probably also be set in the moz.build, but this bug has stalled for long enough, this can happen in a followup.
Attachment #8784174 - Flags: review?(mh+mozilla) → review+
Pushed by cmanchester@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/99484672d208
Always pass defines when compiling SOBJS. r=ted
https://hg.mozilla.org/integration/mozilla-inbound/rev/0f8ca5c828f2
Add some generic compiler-based conditions to moz.configure. r=ted
https://hg.mozilla.org/integration/mozilla-inbound/rev/cddf2e43ee9f
Use moz.build instead of libffi's build system. r=ted,glandium
This broke bug 1283678 again.
Blocks: 1283678
Via git bisect:
> 481ad0d18abf96d000fdb1694ec45e27ebfb726a is the first bad commit
> commit 481ad0d18abf96d000fdb1694ec45e27ebfb726a
> Author: Chris Manchester <cmanchester@mozilla.com>
> Date:   Mon Aug 8 16:58:54 2016 -0700
> 
>     Bug 1262155 - Use moz.build instead of libffi's build system. r=ted,glandium
> 
>     MozReview-Commit-ID: 3wobNk0HDU5
>
Depends on: 1336569
Depends on: 1423799
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: