Ticket #197 (closed bug: fixed)

Opened 15 years ago

Last modified 14 years ago

FFado 2.0~rc1 FTBFS on Sparc

Reported by: rexbron Assigned to:
Priority: minor Milestone: FFADO 2.0
Component: Version: FFADO 2.0-rc1 (1.999.40)
Keywords: ftbfs Cc:
The device the bug applies to:


As FFado has made it into the Ubuntu Jaunty archives, it is being built on more archs than just i386 and amd64. Relevant section from the build log:

g++ -o src/bebob/bebob_avdevice.os -c -DDEBUG -Wall -g -DDBUS_HAS_THREADS_INIT_DEFAULT \ 
-I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 \
-I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 \ 
-I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include \
-Iexternal/libconfig src/bebob/bebob_avdevice.cpp
In file included from src/libutil/Thread.h:56,
                 from src/libstreaming/StreamProcessorManager.h:32,
                 from src/devicemanager.h:33,
                 from src/bebob/bebob_avdevice.cpp:26:
src/libutil/Atomic.h: In function 'long int INC_ATOMIC(volatile int32_t*)':
src/libutil/Atomic.h:170: error: 'CAS' was not declared in this scope
src/libutil/Atomic.h: In function 'long int DEC_ATOMIC(volatile int32_t*)':
src/libutil/Atomic.h:179: error: 'CAS' was not declared in this scope
src/libutil/Atomic.h: In function 'long int ADD_ATOMIC(volatile int32_t*, int32_t)':
src/libutil/Atomic.h:188: error: 'CAS' was not declared in this scope
src/libutil/Atomic.h: In function 'long int SUBSTRACT_ATOMIC(volatile int32_t*, int32_t)':
src/libutil/Atomic.h:197: error: 'CAS' was not declared in this scope
src/libutil/Atomic.h: In function 'long int ZERO_ATOMIC(volatile int32_t*)':
src/libutil/Atomic.h:206: error: 'CAS' was not declared in this scope
scons: *** [src/bebob/bebob_avdevice.os] Error 1
scons: building terminated because of errors.
make: *** [debian/stamp-scons-build] Error 2

Full build log: http://launchpadlibrarian.net/22779537/buildlog_ubuntu-jaunty-sparc.libffado_2.0~rc1-0ubuntu1_FAILEDTOBUILD.txt.gz


sparc.patch (2.6 kB) - added by adi on 02/19/09 09:10:40.
patch adding sparc(64) targets and a non-atomic CAS
sparc-gccbuiltin.patch (2.6 kB) - added by adi on 02/20/09 03:44:12.
use gcc builtins for ultrasparc
atomic.patch (490 bytes) - added by adi on 10/09/09 06:21:29.
Remaining patch for libutil, now that the build system has been fixed.

Change History

02/19/09 09:09:28 changed by adi


It's way more than just Atomic.h:

Trying to find the system triple: (cached) sparc64-unknown-linux-gnu
Doing a DEBUG build
Detected DIST_TARGET = i686

The whole build system doesn't know anything about SPARC at the moment. I have a SPARC64 Debian system available, if anybody (developer) is interested in getting a login, just ping me. It has no firewire port (Sun Fire V880), but if need be, I could probably add a PCI 1394 controller and my io14.

Find attached a first patch. It adds sparc(64) to the build system and provides a generic compare-and-swap operation, though not atomic. Since there are different sparc processor versions, we'd probably need to code different versions for sparc v8 and v9.

Don't know if the Linux kernel, the gcc or libc provides something like atomic_cas_32 (see http://forums.sun.com/thread.jspa?threadID=5085084) on Solaris.

JFTR: http://developers.sun.com/solaris/articles/atomic_sparc/

Poll: should we just mark FFADO-2.0 as unsupported on SPARC? The attached patch fixes the build issue, but I have no runtime testing at all.

Last remark: Debian on Sparc64 is a 64bits kernel with a 32bits userland, only few apps are compiled for 64bits. The attached patch defaults to 32bit output, supporting also builds for 64bits. Hopefully. ;)

02/19/09 09:10:40 changed by adi

  • attachment sparc.patch added.

patch adding sparc(64) targets and a non-atomic CAS

02/19/09 13:13:13 changed by holin

The foremost question is, do we really want to support each of debian's gazillion archs? Is there man-power to back that up? In the long run, I don't think it will be useful to add skin-deep support for archs that will bit-rot in no time. I wouldn't be surprised if firewire support was shaky from the kernel upwards with anything but the most common archs, which these days has really come to include only x86 and x86_64.

As to the problem at hand, an easy, but not entirely trouble-free, solution is to use the atomic builtins that gcc >= 4.1 has. Of course a check for the gcc version has to be added, but from there on it's easy sailing.

02/20/09 03:44:12 changed by adi

  • attachment sparc-gccbuiltin.patch added.

use gcc builtins for ultrasparc

02/20/09 04:05:19 changed by adi

  • priority changed from major to minor.

I'd also opt for "amd64 and x86, nothing more". Other target architectures seem to vanish, and I guess the typical FFADO user won't neither have slow SparcStations? nor Sun Servers like my V880 (way too loud, to large).

Anyway, I've added a second patch, enabling gcc builtin atomics for sparc v9. That's sparc64, and afaik, these CPUs have been on the market for ages (so not a big restriction, probably comparable to 386 vs. Pentium, where v9 is the "Pentium").

Though we don't have manpower to support it, we could add this second patch. I claim there won't be a single person actually using it ;) As for "gcc >= 4.1 check": we just mention it in the README file. "On SPARC, you'd need gcc >= 4.1 to compile FFADO. This will only work for UltraSparc? (sun4u), SPARCv8 and earlier is not supported."

02/24/09 07:09:33 changed by rexbron

  • milestone changed from FFADO 2.0 to FFADO 2.1.

10/09/09 06:21:29 changed by adi

  • attachment atomic.patch added.

Remaining patch for libutil, now that the build system has been fixed.

10/09/09 06:29:18 changed by adi

  • milestone changed from FFADO 2.1 to FFADO 2.0.

The build system has been fixed in r1675. Now, support for atomic operations has to be added. I've attached a new patch to this ticket, atomic.patch.

Once applied, it gives a fallback to the gcc builtin atomic operation. This is sensible, it calls the corresponding hardware functions on each CPU type, so there's no need to provide handcrafted ASM code in ffado.

Since this patch doesn't affect the main FFADO targets amd64/i386/ppc, it's save to apply the patch. We don't lose anything, we just gain support for SPARC, hppa, ia64 and some other. I therefore changed the milestone to 2.0.

10/09/09 12:52:46 changed by arnonym

  • status changed from new to closed.
  • resolution set to fixed.

(In [1682]) Apply the atomic-patch also to the 2.0 branch.

Fixes #197.