www/firefox on RPI2: error: instruction requires: armv6t2

[Mark Millard]

On 2017-May-12, at 5:34 PM, bob prohaska <fbsd at www.zefox.net> wrote:

> On Fri, May 12, 2017 at 02:36:48PM -0700, Mark Millard wrote:
>> 
>> My guess from the above is that the problem will
>> repeat in this rebuild.
>> 
>> 
>> 
> That's exactly what happened. A copy of make.log and  
> 
> armSP_FFTInv_CCSToR_F32_preTwiddleRadix2_unsafe_s.S
> 
> can be found at
> 
> http://www.zefox.net/~fbsd/rpi2/firefox/assembler_failure/

Your source is different than what I looked
at. Yours has capitalized .MACRO instead of
having a .macro as the assembler directive:

        .MACRO FFTSTAGE scaled, inverse, name

and that might make a difference for the specific
error. I have vague memories of seeing some other
list report that involved lower-casing an assembler
directive.

Jan Beich had a list reply that showed changes to
have lower case for such for clang in multiple
files:

https://android.googlesource.com/platform/external/chromium_org/third_party/openmax_dl/+/5d8507771824%5E%21/

Apparently what is in ports predates such
changes. (There may be other things that it
predates as well.) Nor does it seem to
patch such things.

The error messages with "\name" involved seem to
be tied to not recognizing .MACRO and .endm (macro
directives) and so not doing name substitution
from the macro directive's arguments.

Most everything else listed as an error in that
area looks to be assembler notation mismatches.
I've no clue what assembler might accept the
notation that is in use. If you change assemblers
other things may need to change, such as
-mcpu=corex-a7 might not be the right option
syntax for the purpose any more (just for
the assembler).

> It happens that make.log records a number of errors in the
> configuration phase of compilation. The errors don't seem fatal: 
> 
> Error processing command. Ignoring because optional. (optional:setup.py:python/psutil:build_ext:--inplace)
> 
> Could they be in some way related to the assembler problem?

I've no real clue but would guess not.

> If other files would be informative I'll gladly post them.

I'm running out of things that my generic background
knowledge covers.

Michal Meloun had a reply that mentioned:

"many pieces of assembly files still uses pre-UAL syntax"

and so may know more about the context than I do. Looking
it up UAL seems to be short for "Unified Assembler
Language". Apparently pre-UAL does not support 32-bit
Thumb Instructions.

Jan B. had written:

so the following wouldn't help?

Index: Mk/bsd.gecko.mk
===================================================================
--- Mk/bsd.gecko.mk	(revision 440464)
+++ Mk/bsd.gecko.mk	(working copy)
@@ -475,6 +475,10 @@ USE_BINUTILS=	# intel-gcm.s
 CFLAGS+=	-B${LOCALBASE}/bin
 LDFLAGS+=	-B${LOCALBASE}/bin
 . endif
+.elif ${ARCH:Marm*}
+USE_BINUTILS=	# media/openmax_dl/
+MOZ_EXPORT+=	ASFLAGS="${ASFLAGS}"
+ASFLAGS+=	-B${LOCALBASE}/bin
 .elif ${ARCH:Mpowerpc*}
 USES:=		compiler:gcc-c++11-lib ${USES:Ncompiler*c++11*}
 . if ${ARCH} == "powerpc64"

That would appear to try to use the assembler
from devel/binutils if I gather the intent
correctly. It is (implicitly) a reference
to /usr/ports/Mk/bsd.gecko.mk (presuming the
usual default place for the ports source
code tree).


Both the Jan B. and the Michal M. quotes are visible
in:

https://lists.freebsd.org/pipermail/freebsd-ports/2017-May/108511.html

There is more there than I've referenced above.

May be Jan B. or Michal M. know some about what tool(s) handle
such "pre-UAL" syntax and how to use such tools.

===
Mark Millard
markmi at dsl-only.net