Hi,
I committed a fix that does at least not crash converting a test wave to mp3 on
a i686 test build:
Committed revision 43459.
No idea how that behaves building for really old CPUs without SSE, …
As far as I can se the original classification (at LFS et al.) is also wrong.
It is not exactly related to i686, it is all x86 (i386++) build not targeting a
CPU with SSE, …
However, maybe that code should be changed, not to be built for this kind of
optimization settings, but maybe lame has a cupid switch for that code path, ...
As usual: patches welcome, …
René
On Nov 29, 2014, at 16:37, René Rebe <[email protected]> wrote:
> Hi,
>
> that certainly disables MMX support, is that really what you want? Maybe we
> should better look into fixing compiling the MMX support?
>
> (I played with that shortly, but other things consumed too much time the last
> hours, …)
>
> René
>
> On Nov 29, 2014, at 5:12, Barry Kauler <[email protected]> wrote:
>
>> ---------- Forwarded message ----------
>> From: Barry Kauler <[email protected]>
>> Date: Sat, 29 Nov 2014 10:11:44 +0800
>> Subject: [t2] Cannot compile lame: fixed, kind of
>> To: René Rebe <[email protected]>
>>
>> On 11/29/14, Barry Kauler <[email protected]> wrote:
>>> Rene,
>>> Would you mind checking on your local T2, that audio/lame compiles?
>>>
>>> I have never had any trouble with it before, that I can recall, but
>>> this time I get a compile error, that I have not yet been able to
>>> understand.
>>>
>>> I have always had lame in the package-list, always thought of it as
>>> one of the essentials. So, don't want to have to remove it.
>>>
>>> There are a lot of errors like this, about "inlining failed":
>>>
>>> In file included from xmm_quantize_sub.c:37:0:
>>> /usr/lib/gcc/i686-t2-linux-gnu/4.9.2/include/xmmintrin.h:929:1: error:
>>> inlining failed in call to always_inline '_mm_loadu_ps': target
>>> specific option mismatch
>>> _mm_loadu_ps (float const *__P)
>>> ^
>>> xmm_quantize_sub.c:65:18: error: called from here
>>> const __m128 vec_fabs_mask = _mm_loadu_ps(&fabs_mask._float[0]);
>>> ^
>>>
>>> I tried an older version of lame, even tried patches from ubuntu, no go.
>>>
>>
>> Rene,
>> I googled, this is a known problem. LFS have a fix:
>>
>> http://www.linuxfromscratch.org/blfs/view/svn/multimedia/lame.html
>>
>> Yes, I am doing a i686 build!
>>
>> ...can you implement that fix in T2?
>>
>> I have confirmed that lame.conf with this in it, does compile:
>>
>> lame_fix_i686()
>> {
>> sed -i -e '/xmmintrin\.h/d' configure
>> }
>> hook_add preconf 5 "lame_fix_i686"
>>
>> However, the LFS page states:
>>
>> Do not use this on other versions of gcc, or on x86_64.
>>
>> ...so, how to add test for gcc version and i686 target?
>>
>> Regards,
>> Barry
>>
>> -----------------------------------------------------------
>> If you wish to unsubscribe from this mailing, send mail to
>> [email protected] with a subject of: unsubscribe t2
>
> --
> ExactCODE GmbH, Lietzenburger Str. 42, DE-10117 Berlin
> DE Legal: Amtsgericht Berlin (Charlottenburg) HRB 105123B, Tax-ID#:
> DE251602478
> Managing Director: René Rebe
> http://exactcode.com | http://exactscan.com | http://ocrkit.com |
> http://t2-project.org | http://rene.rebe.de
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [email protected] with a subject of: unsubscribe t2
--
ExactCODE GmbH, Lietzenburger Str. 42, DE-10117 Berlin
DE Legal: Amtsgericht Berlin (Charlottenburg) HRB 105123B, Tax-ID#: DE251602478
Managing Director: René Rebe
http://exactcode.com | http://exactscan.com | http://ocrkit.com |
http://t2-project.org | http://rene.rebe.de
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[email protected] with a subject of: unsubscribe t2
