[Sumover-dev] RAT and linux 64b

Piers O'Hanlon p.ohanlon at cs.ucl.ac.uk
Thu Jul 31 09:36:19 BST 2008


Hi,

> As Douglas told me, the problem was indeed coming from ALSA. I modified
> myself the configure script yesterday, and managed to compile and run RAT
> without any problem. Thanks again for your help and your reactivity.
>
Ah ok - thats interesting. I'll have to look into that.

If you get a chance it would be great if you could test out rat with
ALSA using valgrind and email me the output
valgrind --trace-children=yes -v ./rat 224.4.4.4/4444

Thanks,

Piers.

> Regards,
>
> --
> --------------
> Brice Maret - ARTAL Technologies
> Ensemble "La Rue" - Bat. 9
> Rue Pierre-Gilles de Gennes
> BP  38138
> 31681  LABEGE CEDEX
> tel: 05 61 00 39 41
> e-mail : brice.maret at artal.fr
>
>
> Piers O'Hanlon a écrit :
>>
>> Hi,
>>
>> I've just committed new configure/configure.in with a new option to
>> allow for disabling of ALSA:
>> ./configure --disable-alsa. You could try building with ALSA disabled
>> to see if RAT works without it on 64bit.
>> You could also test RAT by running it with valgrind see if it comes up
>> with a memory error eg.:
>> valgrind --trace-children=yes  ./rat 224.4.4.4/4444
>>
>> Piers.
>>
>>
>>
>> 2008/7/30 Douglas Kosovic <douglask at itee.uq.edu.au>:
>>
>>>
>>> Hi Brice,
>>>
>>>
>>>>
>>>> Thank you for the answer as well as for the source code. I was trying to
>>>> run a RAT v4.2.23 downloaded from
>>>> http://www-mice.cs.ucl.ac.uk/multimedia/software/rat/, it looks like
>>>> this
>>>> version is not 64b compliant, but yours works well (at least until this
>>>> message :
>>>>
>>>
>>>
>>>>
>>>> [pid/22661 +1177 auddev_alsa.c] ALSA version identifier == à    <
>>>>
>>>
>>> This doesn't look good, the memory seems corrupted, it should be
>>> outputting
>>> something like:
>>>
>>> [pid/4110 +1177 auddev_alsa.c] ALSA version identifier == Advanced Linux
>>> Sound Architecture Driver Version 1.0.16rc2 (Thu Jan 31 16:40:16 2008
>>> UTC).
>>>
>>> I think when I used to build RAT on x86-64 Fedora Core 3 (which RHEL 4 is
>>> based on), I used to disable building the ALSA support because I had all
>>> sorts of issues with ALSA. For Fedora Core 4 and later I would build the
>>> ALSA support. To disable building the ALSA support I think I used to
>>> patch
>>> the configure script to avoid detecting ALSA or something.
>>>
>>>
>>>>
>>>> It's probably nothing though, the important thing is the message I had
>>>> before is not present anymore, it will probably work now. Thanks again!
>>>>
>>>
>>> I don't know, if RAT doesn't work I would be pointing the finger at ALSA
>>> as
>>> the likely candidate for the failure.
>>>
>>>
>>> Cheers,
>>> Doug
>>>
>>>
>>>>
>>>> Douglas Kosovic a écrit :
>>>>
>>>>>
>>>>> Hi Brice,
>>>>>
>>>>>
>>>>> I've built rat RPMs for x86-64 Fedora 7, 8 & 9 and x86-64 RHEL 5 from
>>>>> SVN and they all work.
>>>>> If you want to try building a current SVN snapshot RPM, download
>>>>> rat-4.4.01-0.1.20080730svn.el5.src.rpm from:
>>>>>  http://www.vislab.uq.edu.au/ag3/rhel/5/SRPMS/
>>>>> then as root issue:
>>>>>
>>>>> rpmbuild -D "dist .el4" --rebuild
>>>>> rat-4.4.01-0.1.20080730svn.el5.src.rpm
>>>>>
>>>>> If you were already building from the SVN source code in the last 3
>>>>> weeks, there was a glibc issue with malloc/free being outside a
>>>>> fork/exec, which corrupted the command-line arguments passed to the
>>>>> forked processes. Depending on the glibc version, sometimes it would
>>>>> fail on x86-64, sometimes on i386. If you check-out now or use the
>>>>> above
>>>>> SRPM, you should be okay.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Doug
>>>>>
>>>
>>> _______________________________________________
>>> Sumover-dev mailing list
>>> Sumover-dev at cs.ucl.ac.uk
>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/sumover-dev
>>>
>>>
>>
>> .
>>
>>
>
>



More information about the Sumover-dev mailing list