Re: FTBFS: fftw3
Ben Collins <bcollins@debian.org> writes:
>> The gcc flags are inconsistent between sparc and x86 (and former gcc
>> maintainers can forget which way round they are...). -mcpu on sparc
>> selects the instruction/register set, not just the tuning as it does
>> on x86.
>
> Not quite true, I believe.
> IIRC, i486 -> pentiumpro incurs some
> instructions being used in addition to normal x86 instructions.
The manual is quite explicit. If I remember correctly, I once
clarified the x86 section after checking the machine description
files.
>> For sparc, -mtune=ultrasparc would be reasonable, on the basis that
>> number crunching normally should be tuned for recent machines. On the
>> other hand, if it can be made to go significantly faster on ultras by
>> compiling with -mcpu=ultrasparc, it would be worth making multiple
>> library versions like openssl does.
>
>
> Similar to how -mcpu=i686 does not run on i386 machines,
No, that's -march=i686.
> so -mcpu=ultrasparc wont run on pre-ultrasparc machines.
Which is why that version would live in /usr/lib/v9, just like
openssl's libcrypto.
> It's a given. I can't see how this is confusing.
It's clearly confusing that the same flag has different meanings for
different gcc cpu families. That's why the original suggestion for
compiler flags is wrong and would have to be replaced by
architecture-specific cases. I was trying to explain that situation
for the benefit of someone doing cross-platform maintenance because I
recognise the issue and actually checked the doc.
I can't see how it's confusing to suggest multilibbing like openssl,
whether or not it's actually justified in this case. It apparently is
confusing, though.
Reply to: