Check for libffi_cv_as_x86_pcrel should not look for just "warning"

RESOLVED FIXED

Status

()

Core
js-ctypes
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: espindola, Assigned: espindola)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed in tracemonkey])

Attachments

(1 attachment, 1 obsolete attachment)

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.
Blocks: 574346
Created attachment 520911 [details] [diff] [review]
don't check for 'warning'
Attachment #520911 - Flags: review?
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.

Comment 5

6 years ago
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.

Comment 7

6 years ago
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?
Created attachment 526097 [details] [diff] [review]
patch including js/src/ctypes/libffi.patch

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

Comment 9

6 years ago
Sounds fine, as long as everything's still in there!
To the best of my knowledge it is.
Keywords: checkin-needed
Assignee: nobody → respindola
Status: NEW → ASSIGNED
Keywords: checkin-needed
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [fixed in tracemonkey]
This was fixed some time ago.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.