Bug#667653: mpg123 FTBFS on armhf
I pulled that change into another 1.13 release, it is a bit different from your patch. Could you (peter?) test http://mpg123.org/download/mpg123-1.13.8.tar.bz2 if it builds now? I extrated the tarball on an armhf system and did ./configure and make and it seemed to build successfully. I have not tried to build a debian package from it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#667653: mpg123 FTBFS on armhf
> I pulled that change into another 1.13 release, it is a bit different from > your patch. Could you (peter?) test > http://mpg123.org/download/mpg123-1.13.8.tar.bz2 if it builds now? I'll make > it officialy public, then. > Final report. I tested it with: --with-cpu=neon + -marm => WORKS --with-cpu=neon + -mthumb => WORKS --with-cpu=arm_nofpu + -marm=> WORKS --with-cpu=arm_nofpu + -mthumb => WORKS Seems that using the new LSL notation was not needed and the old MOV with inline shift still work in this case. Regards, Miguel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#667653: mpg123 FTBFS on armhf
Okay, our assembly expert got me, too: We have a fix for this in mpg123 trunk since september last year! I pulled that change into another 1.13 release, it is a bit different from your patch. Could you (peter?) test http://mpg123.org/download/mpg123-1.13.8.tar.bz2 if it builds now? I'll make it officialy public, then. The fresh 1.14-beta2 has the fix, too, btw. Alrighty then, Thomas signature.asc Description: PGP signature
Bug#667653: mpg123 FTBFS on armhf
Am Fri, 6 Apr 2012 22:27:07 -0400 schrieb Miguel Colon : > I saw that layer3.c includes "#include "mpg123lib_intern.h" and that > in that file there is a block: > > # elif defined(OPT_ARM) > /* for arm */ > # define REAL_MUL_ASM(x, y, radix) \ > Damn, you got me there! I really did not think about those support macros only about our "real" assembly instructions in plain assembler files. Thanks for investigating. I'll present you work to our assembly man who wrote this code and see to it that the next mpg123 release contains the fix. Alrighty then, Thomas signature.asc Description: PGP signature
Bug#667653: mpg123 FTBFS on armhf
> As mpg123 upstream it would be cool to get note of such issues without > having to look for them in the debian bts. Having some bot subscribe > and post to mpg123-de...@lists.sourceforge.net would be splendit; but if > that is too troublesome, sending an info to maintai...@mpg123.org would > be just as fine (using the generic address in case I vanish in future). > But perhaps I overlooked a generic way to subscribe an address to all > future reports. Hello: I have not tried it myself but I think this is what you are asking for: http://www.debian.org/doc/manuals/developers-reference/resources.html#pkg-tracking-system Section 4.10.1 explains the subscribe and the keyword options. I would filter out some of them since it would be too verbose IMO. > Second: There is no inline assembly in mpg123. The file at hand > (layer3.c) is plain C all around. So, without further data, I must > assume that this is a bug in gcc that is worked around by adding -marm. > You might consider asking gcc folks about this. I had some free time so I looked into this. The armhf architecture defaults to -mthumb instead of -marm and: 1) --with-cpu=arm_nofpu it fails with -mthumb and works with -marm (-DOPT_ARM -DREAL_IS_FIXED) 2) --with-cpu=neon it works with both. (-DOPT_NEON -DREAL_IS_FLOAT) This lead me to believe that it was most likely related to -DOPT_ARM. I saw that layer3.c includes "#include "mpg123lib_intern.h" and that in that file there is a block: # elif defined(OPT_ARM) /* for arm */ # define REAL_MUL_ASM(x, y, radix) \ I patched this file by basically doing -# elif defined(OPT_ARM) +# elif defined(OxPT_ARxM) Without the patch it FTBFS but with the patch it builds. Looking at the ASM code it seems that these 2 asm block use PRE-UAL ARM syntax which only work in ARM and not thumb. The newer UAL syntax works with both. Here is a link that mentions some of the changes: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cjagjjbc.html Attached is a patch to really fix this and the orr problem with a header inside the patch explaining the changes. Using -marm was really a workaround to hide the problem but not a real solution to this and disabled all the advantages of using -mthumb. Reference for thumb2 instructions: http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf Hope this helps, Miguel 0005-thumbs2.patch Description: Binary data
Bug#667653: mpg123 FTBFS on armhf
What is this ...? As mpg123 upstream it would be cool to get note of such issues without having to look for them in the debian bts. Having some bot subscribe and post to mpg123-de...@lists.sourceforge.net would be splendit; but if that is too troublesome, sending an info to maintai...@mpg123.org would be just as fine (using the generic address in case I vanish in future). But perhaps I overlooked a generic way to subscribe an address to all future reports. Second: There is no inline assembly in mpg123. The file at hand (layer3.c) is plain C all around. So, without further data, I must assume that this is a bug in gcc that is worked around by adding -marm. You might consider asking gcc folks about this. Alrighty then, Thomas signature.asc Description: PGP signature
Bug#667653: mpg123 FTBFS on armhf
Package: mpg123 Version: 1.13.7-6 Severity: important Tags: patch User: debian-...@lists.debian.org Usertags: armhf mpg123 FTBFS on armhf with the following errors. /bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../src -I../../src -I../../src/libmpg123 -DOPT_ARM -DREAL_IS_FIXED -D_FORTIFY_SOURCE=2 -O2 -fomit-frame-pointer -funroll-all-loops -finline-functions -ffast-math -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -c -o layer3.lo layer3.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src -I../../src -I../../src/libmpg123 -DOPT_ARM -DREAL_IS_FIXED -D_FORTIFY_SOURCE=2 -O2 -fomit-frame-pointer -funroll-all-loops -finline-functions -ffast-math -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -c layer3.c -fPIC -DPIC -o .libs/layer3.o /tmp/ccUolZ9g.s: Assembler messages: /tmp/ccUolZ9g.s:4188: Error: shift must be constant -- `orr r6,r6,r7,lsl ip' /tmp/ccUolZ9g.s:4233: Error: shift must be constant -- `orr r7,r7,ip,lsl r8' /tmp/ccUolZ9g.s:4490: Error: shift must be constant -- `orr r6,r6,r7,lsl ip' /tmp/ccUolZ9g.s:4733: Error: shift must be constant -- `orr fp,fp,r7,lsl ip' /tmp/ccUolZ9g.s:4763: Error: shift must be constant -- `orr fp,fp,r7,lsl ip' /tmp/ccUolZ9g.s:4797: Error: shift must be constant -- `orr r6,r6,r7,lsl ip' /tmp/ccUolZ9g.s:4831: Error: shift must be constant -- `orr r8,r8,r1,lsl r0' /tmp/ccUolZ9g.s:4866: Error: shift must be constant -- `orr sl,sl,r1,lsl r6' /tmp/ccUolZ9g.s:7004: Error: shift must be constant -- `orr r7,r7,ip,lsl r8' /tmp/ccUolZ9g.s:7057: Error: shift must be constant -- `orr r7,r7,ip,lsl r8' /tmp/ccUolZ9g.s:7328: Error: shift must be constant -- `orr r8,r8,r7,lsl ip' /tmp/ccUolZ9g.s:7612: Error: shift must be constant -- `orr r8,r8,r6,lsl r7' /tmp/ccUolZ9g.s:7688: Error: shift must be constant -- `orr r8,r8,r6,lsl r7' /tmp/ccUolZ9g.s:7726: Error: shift must be constant -- `orr sl,sl,r7,lsl ip' /tmp/ccUolZ9g.s:7846: Error: shift must be constant -- `orr r8,r8,r1,lsl r0' /tmp/ccUolZ9g.s:7886: Error: shift must be constant -- `orr r8,r8,r1,lsl r6' make[4]: *** [layer3.lo] Error 1 The cause seems to be some thumb2 incompatible inline assembler. The attatched patch adds -marm to the CFLAGs to get arround this. diff -ur mpg123-1.13.7/debian/rules mpg123-1.13.7.new/debian/rules --- mpg123-1.13.7/debian/rules 2012-04-01 08:25:34.0 + +++ mpg123-1.13.7.new/debian/rules 2012-04-05 15:43:32.0 + @@ -31,6 +31,10 @@ CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS) LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS) +ifeq ($(ARCH),armhf) + CFLAGS += -marm +endif + LDFLAGS += -Wl,--as-needed #export DH_VERBOSE=1
