You are not logged in.
I'm trying to get supercollider-git 20101109-1 working http://aur.archlinux.org/packages.php?ID=42513
There is an upstream problem with the compiler configuration, which means that my CPU (AthlonXP 2500+) doesn't have its features properly detected, specifically the package gets built with SSE2 support when the CPU only supports SSE. (this I've gleaned/guessed from http://new-supercollider-mailing-lists- … 92i40.html and a few other sources)
I have tried to build the package with:
$ makepkg --config ./makepkg.conf
where ./makepkg.conf contains some -msse2=0 flags, added by me:
CARCH="i686"
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=i686 -mtune=generic -O2 -pipe -msse2=0"
CXXFLAGS="-march=i686 -mtune=generic -O2 -pipe -msse2=0"
LDFLAGS="-Wl,--hash-style=gnu -Wl,--as-needed"But it seems that the package is still being built with the sse2 flag. Here's an excerpt from makepkg output:
Checking for C header file altivec.h... no
Checking for C header file xmmintrin.h... yes
NOTICE: CPU has SSE support
Checking for C header file X11/Intrinsic.h... yes
Checking for XQueryPointer() in C library X11... yes
----------------------------------------------------
To install SCVIM, please use scons in the directory ../editors/scvim/
----------------------------------------------------
To install SCED, please use the scons in the directory ../editors/sced/
------------------------------------------------------------------------
ALTIVEC: no
AUDIOAPI: Jack
MIDIAPI: ALSA
DEBUG: no
DEVELOPMENT: yes
LANG: yes
LID: yes
NO_LIBSNDFILE: no
WII: no
PREFIX: /usr
RENDEZVOUS: yes
SCEL: yes
SCVIM: yes
SCED: yes
SSE: yes
STRIP: no
CROSSCOMPILE: no
TERMINAL_CLIENT: yes
X11: yes
GPL3: yes
------------------------------------------------------------------------
scons: done reading SConscript files.
scons: Building targets ...
g++ -o Source/common/SC_AllocPool.o -c -Wno-deprecated -fPIC -Wno-unknown-pragmas -O3 -ffast-math -fno-finite-math-only -fstrength-reduce -march=i686 -msse -mfpmath=sse -msse2 -fPIC -DNOVA_SIMD -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DSC_DATA_DIR=\"/usr/share/SuperCollider\" -D_REENTRANT -DSC_LINUX -DNDEBUG -DSC_MEMORY_ALIGNMENT=16 -Iinclude/nova-simd -IHeaders/common -IHeaders/plugin_interface -IHeaders/server Source/common/SC_AllocPool.cppAnd, trying to run the subsequently installed package I get...
$ scsynth
Illegal instruction(BTW, this also happens with the out-of-date non-git version of supercollider, and building without AUR).
So... Is makepkg ignoring me? Is scons ignoring makepkg? Is g++ ignoring us all? I'm not terribly experienced at this but I would like to get the latest supercollider up and running (and maybe even help get it fixed in AUR/PKGBUILD).
Last edited by markhadman (2010-11-09 22:06:03)
Offline
see there in gc++ line -msse2 ?
you need to get rid of it or transform it in -mno-sse2
Give what you have. To someone, it may be better than you dare to think.
Offline
see there in gc++ line -msse2 ?
you need to get rid of it or transform it in -mno-sse2
Indeed, I just don't know how! Do I need to attack scons or g++ config files directly? Or am I doing the CFLAGS wrong in my custom makepkg.conf? As I said, I'm not very experienced...
Offline
you can force building without sse2 via scons. just edit the pkgbuild:
turn this
scons PREFIX=/usr SCED=yes DEVELOPMENT=yes READLINE=yes || return 1
into this:
scons PREFIX=/usr SCED=yes DEVELOPMENT=yes SSE2=no READLINE=yes || return 1
hope that helps.
otherwise you could try building supercollider with cmake (scons will be discontinued soon anyways)
- perhaps there the detection works :-/
instructions are in README LINUX, but i will update the pkgbuild to cmake anyways tomorrow.
Offline
Thanks hb, that's what I needed. Unfortunately compilation now fails with:
g++ -o Source/plugins/BinaryOpUGens.os -c -Wno-deprecated -Wno-unknown-pragmas -O3 -ffast-math -fno-finite-math-only -fstrength-reduce -march=i686 -msse -mfpmath=sse -fPIC -DNOVA_SIMD -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DSC_DATA_DIR=\"/usr/share/SuperCollider\" -D_REENTRANT -DSC_LINUX -DNDEBUG -DSC_MEMORY_ALIGNMENT=16 -DLIBSNDFILE_1018 -Iinclude/nova-simd -IHeaders/common -IHeaders/plugin_interface -IHeaders/server Source/plugins/BinaryOpUGens.cpp
In file included from include/nova-simd/vec_sse.hpp:33:0,
from include/nova-simd/vec.hpp:25,
from include/nova-simd/simd_binary_arithmetic.hpp:25,
from Source/plugins/BinaryOpUGens.cpp:32:
include/nova-simd/detail/vec_math.hpp: In function 'VecType nova::detail::vec_exp_float(const VecType&) [with VecType = nova::vec<float>]':
include/nova-simd/vec_sse.hpp:487:41: instantiated from here
include/nova-simd/detail/vec_math.hpp:125:39: error: no type named 'int_vec' in 'struct nova::vec<float>'
include/nova-simd/detail/vec_math.hpp: In function 'VecType nova::detail::vec_log_float(VecType) [with VecType = nova::vec<float>]':
include/nova-simd/vec_sse.hpp:492:41: instantiated from here
include/nova-simd/detail/vec_math.hpp:170:39: error: no type named 'int_vec' in 'struct nova::vec<float>'
include/nova-simd/detail/vec_math.hpp: In function 'VecType nova::detail::vec_exp_tanh_float(const VecType&) [with VecType = nova::vec<float>]':
include/nova-simd/detail/vec_math.hpp:516:95: instantiated from 'VecType nova::detail::vec_tanh_float(const VecType&) [with VecType = nova::vec<float>]'
include/nova-simd/vec_sse.hpp:554:42: instantiated from here
include/nova-simd/detail/vec_math.hpp:207:39: error: no type named 'int_vec' in 'struct nova::vec<float>'
scons: *** [Source/plugins/BinaryOpUGens.os] Error 1
scons: building terminated because of errors.
Aborting...Is that Game Over or is there still hope? If necessary I can go back to the non-git version of supercollider, but I strongly suspect that this is sse-related!
Last edited by markhadman (2010-11-09 22:52:16)
Offline
hm, I just updated the pkgbuild to use cmake, so try this and if this doesn't work then let's go upstream!
Offline
Yes, the new PKGBUILD compiles, installs and runs supercollider without changing any SSE/SSE2 flags.
(but only if I disable emacs support... even though I have emacs installed... that's a whole different matter though)
Offline
fine! emacs support should work again soon - upstream is working on it.
Last edited by hb (2010-11-10 12:14:15)
Offline