Closed Bug 631928 Opened 11 years ago Closed 10 years ago
Check for libffi
_cv _as _x86 _pcrel should not look for just "warning"
I posted the patch upstream: http://sourceware.org/ml/libffi-discuss/2011/msg00024.html but not reply so far. The problem is that the configure for ffi does two things which are strange at least * uses CFLAGS when processing an assembly file * greps the output instead of checking the error code This makes it fail when trying to build with lto since clang will produce an warning about '-emit-llvm' not being used (since it is processing an assembly file). The above patch changes configure to use the error code. Dropping CFLAGS would also solve it.
11 years ago
10 years ago
Attachment #520911 - Flags: review? → review?(ted.mielczarek)
Comment on attachment 520911 [details] [diff] [review] don't check for 'warning' This seems sensible enough, but I'd really rather have someone from upstream chime in. (Also, we do need to push all libffi changes upstream for sanity's sake.)
Attachment #520911 - Flags: review?(ted.mielczarek) → review+
I have pinged the upstream thread: http://www.cygwin.com/ml/libffi-discuss/2011/msg00110.html
@Rafael: Maybe the topic of your mail to libffi-discuss was to cryptic so nobody knows what you envision to do with this patch. I know, the explanation is in your mail but some people don't have the time to read every mail with the necessary attentiveness. And then again I came across some developer who didn't know what llvm was. So I would say repost your mail with a more descriptive topic which lays out your intention clearly. Btw. I am not affiliated with the libffi-project, I just want to solve some communication problems.
The libffi list isn't always immediately responsive, either. You might have to ping the list a few times to get a response.
Trying yet again: http://www.cygwin.com/ml/libffi-discuss/2011/msg00116.html Do we have a strong policy of never having local patches to libffi? Once NSS merges to m-c this will be one of the two bugs (the other being 635790) blocking building m-c with clang.
We do have local patches to libffi, but we try to keep them minimal. Since you've pushed thrice to upstream, we can take it. :) Can you roll a new patch with your additions added to js/src/ctypes/libffi.patch, with the bug# referenced?
I am not sure how js/src/ctypes/libffi.patch was generated the first time. To try to reduce the noise (file order for example) in this change I did echo > js/src/ctypes/libffi.patch for i in js/src/ctypes/libffi/Makefile.in js/src/ctypes/libffi/configure js/src/ctypes/libffi/src/x86/ffi64.c js/src/ctypes/libffi/src/arm/ffi.c js/src/ctypes/libffi/src/arm/ffitarget.h js/src/ctypes/libffi/src/arm/sysv.S js/src/ctypes/libffi/testsuite/lib/libffi-dg.exp js/src/ctypes/libffi/testsuite/libffi.call/cls_double_va.c js/src/ctypes/libffi/testsuite/libffi.call/cls_longdouble_va.c js/src/ctypes/libffi/include/ffi.h.in js/src/ctypes/libffi/configure.ac; do git diff -U8 tmp tmp2 $i >> js/src/ctypes/libffi.patch; done
Attachment #520911 - Attachment is obsolete: true
Sounds fine, as long as everything's still in there!
To the best of my knowledge it is.
Assignee: nobody → respindola
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [fixed in tracemonkey]
This was fixed some time ago.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.