View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000102 | ardour | bugs | public | 2003-10-28 14:19 | 2004-05-07 03:17 |
Reporter | blubbfisch | Assigned To | paul | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Summary | 0000102: configure error on powerpc | ||||
Description | configure for ardour 0.9-beta7 fails for powerpc-platform, because gcc doesn't know about -march on powerpc. | ||||
Additional Information | QUICK FIX: find -name configure |xargs sed -i "s/-march=\$target_cpu/-mcpu=7450-maltivec -mabi=altivec/" | ||||
Tags | No tags attached. | ||||
|
Can we consider this to be a gcc bug? Which version of gcc are you using? |
|
this is totally a gcc bug. -march is listed in the info pages for gcc. it is not listed as a processor specific option. i really don't want to fix this in our configure scripts (though we will if strictly necessary). |
|
Errm, AFAIK gcc _never_ supported the -march flag on powerpc.... I only ever remember using -mcpu=750 or similar. Bug or not, it is extremely inconsistent and annoying. I only managed to convince autoconf and friends to behave by hardcoding the flags into configure.in myself. Any interest in getting the altivec-and-co-detection code? |
|
you're right and i'm wrong. i looked at gcc info again; -march is x86 specific. if you can give us some code that sets the flags properly for PPC, that would be great. |
|
Ok, here we go. it isn't exactly elegant, but it worked for me :-) if test "$target_cpu" = "powerpc"; then AC_DEFINE(POWERPC, 1, "Are we running a ppc CPU?") altivecLinux=`cat /proc/cpuinfo | grep -i altivec >/dev/null` if test "$?" = "0"; then AC_DEFINE(HAVE_ALTIVEC_LINUX, 1, "Is there Altivec Support ?") if test "$gcc_major_version" = "3"; then dnl -mcpu=7450 does not reliably work with gcc 3.* OPTIM_FLAGS="-O2 -mcpu=7400 -maltivec -mabi=altivec" else OPTIM_FLAGS="-O3 -mcpu=7400" fi else OPTIM_FLAGS="-O3 -mcpu=750 -mmultiple" fi OPTIM_FLAGS="$OPTIM_FLAGS -mhard-float -mpowerpc-gfxopt" elif echo $target_cpu | grep "i*86" >/dev/null; then cat /proc/cpuinfo | grep mmx >/dev/null if test $? = 0; then mmx="-mmmx" fi cat /proc/cpuinfo | grep sse >/dev/null if test $? = 0; then sse="-msse -mfpmath=sse" fi cat /proc/cpuinfo | grep 3dnow >/dev/null if test $? = 0; then dreidnow="-m3dnow" fi AC_DEFINE(INTEL, 1, "Nope its intel") if test "$target_cpu" = "i586"; then OPTIM_FLAGS="-O3 -march=i586" elif test "$target_cpu" = "i686"; then OPTIM_FLAGS="-O3 -march=i686" if test "$gcc_major_version" = "3"; then OPTIM_FLAGS="$OPTIM_FLAGS $mmx $sse $dreidnow" fi fi fi and then I use $OPTIM_FLAGS to add to the user's CFLAGS... Keep in mind that gcc _might_ have problems with Optimization higher than -O2 together with -maltivec, although ardour runs fine on my G4 with -O6! |
|
added ppc detection code to configure.ac's in my tree. |
|
configure script material added to configure.ac for libs/ardour and gtk_ardour. |
|
Reminder sent to blubbfisch Could you mark this bug as closed if this has fixed your problem? |
|
Errm, oops, sorry, forgot about this. thanks for reminding me. configure and make work now on ppc, BUT: it's a total mess of different options (some parts are compiled with -O6 only, some are compiled without any optimization at all, only -mpowerpc-gfxopt and -mhard-float). Bug or feature? Shouldn't software acknowledge any set CFLAGS CXXFLAGS in the users's environment and just strip those flags known not to work with the specific code, respectively add flags known to be very helpful in optimizing? I know this is a lot of sed/awk magic, but may well be worth the effort to yield the best possible compilation flags. Have fun* Niklas |
Date Modified | Username | Field | Change |
---|---|---|---|
2003-10-28 14:19 | blubbfisch | New Issue | |
2003-10-28 14:28 | taybin | Note Added: 0000117 | |
2003-10-28 15:16 | paul | Note Added: 0000118 | |
2003-10-28 15:17 | taybin | Status | new => acknowledged |
2003-10-28 15:17 | taybin | Description Updated | |
2003-10-28 15:25 | blubbfisch | Note Added: 0000120 | |
2003-10-28 15:36 | paul | Note Added: 0000122 | |
2003-10-28 15:46 | blubbfisch | Note Added: 0000123 | |
2003-10-28 17:29 | paul | Note Added: 0000124 | |
2003-10-28 17:30 | paul | Status | acknowledged => assigned |
2003-11-05 04:15 | paul | Status | assigned => resolved |
2003-11-05 04:15 | paul | Resolution | open => fixed |
2003-11-05 04:15 | paul | Assigned To | => paul |
2003-11-05 04:15 | paul | Note Added: 0000145 | |
2003-11-12 20:09 | taybin | Note Added: 0000172 | |
2003-11-13 10:12 | blubbfisch | Note Added: 0000174 | |
2004-05-07 03:17 | taybin | Status | resolved => closed |