Bug#893851: ffcall: Fix build for MIPS release 6

[YunQiang Su]

On Fri, Mar 23, 2018 at 9:38 PM, YunQiang Su <wzssyqa at gmail.com> wrote:
> On Fri, Mar 23, 2018 at 8:41 PM, Sébastien Villemot
> <sebastien at debian.org> wrote:
>> On Fri, Mar 23, 2018 at 08:02:58PM +0800, YunQiang Su wrote:
>>> On Fri, Mar 23, 2018 at 7:58 PM, YunQiang Su <wzssyqa at gmail.com> wrote:
>>> > On Fri, Mar 23, 2018 at 7:27 PM, Sébastien Villemot
>>> > <sebastien at debian.org> wrote:
>>> >> Dear YunQiang,
>>> >>
>>> >> On Fri, Mar 23, 2018 at 06:15:08PM +0800, YunQiang Su wrote:
>>> >>> Package: src:ffcall
>>> >>> Version: 2.1-1
>>> >>>
>>> >>> MIPS release 6 drops some instructions: bnel/beql included.
>>> >>> For r6, we should use bne/beq for replace.
>>> >>>
>>> >>> The patch has submit in salsa as a merge request.
>>> >>>
>>> >>> https://salsa.debian.org/common-lisp-team/ffcall/merge_requests/1
>>> >>
>>> >> Thanks for your report and your patch.
>>> >>
>>> >> You may have overlooked the fact that these assembly files are actually
>>> >> generated by GCC from C source code (see the DEP-3 header of
>>> >> debian/patches/mips-fpxx.patch), so your proposed patch is not very
>>> >> maintainable in the long term.
>>> >
>>> > Oh, thanks. Since then, I guess we should generate these .S files
>>> > when build instead of put them in the source code.
>>> >
>>> > I will have a look at it.
>>>
>>> After read Makefile.devel, I think that we should call the right
>>> target in debian/rules.
>>> Should this the ideal way?
>>
>> This could be a possiblity, but this is not supported by upstream. And we would
>> have to patch this Makefile.devel to make it work (it expects non-standard
>> names for GCC). So I do not really like this solution.
>>
>
> In fact we can patch it to use $(CC), and pass it when we call these targets,
> and then we can drop the patch for the .S/.s files.
> The length of patch file will be much shorter.

If we figure out a command
   $(CROSS_TOOL)
which can has options like "mips64-linux gcc",
then the patch can be even shorter.

>
> Anyway, we will have to patch it.
> Wish my attached patch can change your mind. ;)
>
>> Another possibility, that I would prefer, is to treat mipsr6 as a different ABI
>> (which it actually is), adding the corresponding *.S files with a patch. Do you
>> think this is feasible?
>
> The patch work may be much bigger than the solution 1.
> and the patch will be much longer.
> If you still prefer this solution, I will try to figure out a patch.
>
>>
>> If not, then I think I still prefer to incorporate the first version of your
>> patch.
>>
>> --
>> ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
>> ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
>> ⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
>> ⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org
>
>
>
> --
> YunQiang Su



-- 
YunQiang Su