This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Questions about the libffi development process


On 04/22/2015 10:25 PM, Russell Keith-Magee wrote:
> I can certainly appreciate the problem of having access to appropriate
> hardware for testing, and I'm definitely appreciative of the efforts
> of those (such as yourself) who are doing work that I don't have the
> skills to handle myself. If nothing else, the patch that caused this
> ARMv7 problem also *fixed* a big problem on iOS AARCH64; for that, you
> definitely have my gratitude.
> 
> My concern is that it isn't at all clear how the project as a whole is
> responding to this problem - hence my original question. From the
> perspective of an outside observer - someone who *uses* libffi, and
> can definitely report bugs, but isn't in a good position to fix bugs -
> a patch has been applied to trunk that fails the most basic of
> acceptance tests.

I reject that characterization.

The breakdown I see is that whoever submitted the iOS port in the first place
just dumped the code and left.  They are failing to maintain their port.  In
other projects, that is grounds for simply deleting the port entirely.  On the
basis that users can either maintain the port, or continue using the last
version that did work.  To do otherwise holds the entire project hostage to a
port that no one can (or cares to) maintain.


> I'm asking what, if any,
> processes are in place to make sure that a known critical bug doesn't
> get rolled into a stable release; and what, if any, processes are in
> place to get this bug in front of the eyes of people who *are* in a
> position to fix it.

None.

> That solution (or something close to it) was already proposed on
> ticket #181; while it does solve one compilation problem, it opens a
> whole lot more errors. Compile log follows:

Ok.  Guessing, based on other changes I've made for clang on other ports, the
following has a chance of working.  Sadly, fedora 21 clang is totally
mis-configured so I can't easily test that on arm-linux.


r~

Attachment: d-arm-clang
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]