Thanks for looking at my problem Alban. I checked out those three options, but am still hitting the same brick wall.
Let me show you what I have, and maybe you can help me understand what piece I'm missing. I have all three of those dev libraries installed: $ dpkg -s libmad0-dev Package: libmad0-dev Status: install ok installed Priority: optional Section: libdevel Installed-Size: 188 Maintainer: Ubuntu Developers <[email protected]> Architecture: i386 Source: libmad Version: 0.15.1b-7ubuntu1 $ dpkg -s libtwolame-dev Package: libtwolame-dev Status: install ok installed Priority: optional Section: libdevel Installed-Size: 463 Maintainer: Ubuntu Developers <[email protected]> Architecture: i386 Source: twolame Version: 0.3.13-1build1 Replaces: libtwolame0-dev Depends: libtwolame0 (= 0.3.13-1build1), libc6-dev, pkg-config $ dpkg -s libmp3lame-dev Package: libmp3lame-dev Status: install ok installed Priority: optional Section: libdevel Installed-Size: 490 Maintainer: Ubuntu Developers <[email protected]> Architecture: i386 Source: lame Version: 3.99.3+repack1-1 Depends: libmp3lame0 (= 3.99.3+repack1-1) Apparently my Ubuntu installation already had symbolic links named with .so which point to the version-specific shared library file (e.g. libmad.so.0.2.1) $ file /usr/lib/libmad.so* /usr/lib/libtwolame.so* /usr/lib/i386-linux-gnu/libmad.so* /usr/lib/i386-linux-gnu/libmp3lame.so* /usr/lib/libmad.so: symbolic link to `/usr/lib/i386-linux-gnu/libmad.so' /usr/lib/libmad.so.0: symbolic link to `/usr/lib/i386-linux-gnu/libmad.so' /usr/lib/libtwolame.so: symbolic link to `libtwolame.so.0.0.0' /usr/lib/libtwolame.so.0: symbolic link to `libtwolame.so.0.0.0' /usr/lib/libtwolame.so.0.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x5a1b8b2e2ac8c079be35bd8c81073d2c589cd036, stripped /usr/lib/i386-linux-gnu/libmad.so: symbolic link to `libmad.so.0.2.1' /usr/lib/i386-linux-gnu/libmad.so.0: symbolic link to `libmad.so.0.2.1' /usr/lib/i386-linux-gnu/libmad.so.0.2.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xd6f31fd3bf3caff864965ed52a425c1f5454251f, stripped /usr/lib/i386-linux-gnu/libmp3lame.so: symbolic link to `libmp3lame.so.0.0.0' /usr/lib/i386-linux-gnu/libmp3lame.so.0: symbolic link to `libmp3lame.so.0.0.0' /usr/lib/i386-linux-gnu/libmp3lame.so.0.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x7b3ac3b48da49661b14fc4ab89524a3a51510c96, stripped caed reports in the system log that it has the MAD decoding capabilities during startup $ grep -A2 -B2 -i caed.*mad /var/log/syslog |sed -e 's/.*u-11//' ripcd: started caed: Found TwoLAME encoder library, MPEG L2 encoding supported caed: Found MAD decoder library, MPEG L2 decoding supported caed: Unable to set realtime scheduling: No such process caed: cae started Since that message is logged from within MainObject::LoadMad, I can tell that libmad.so was successfully loaded during caed's startup. It was a little bit trickier, but I was able to verify that the CGI program does successfully load libmad. I found this out by getting a fresh apache2 environment, then attaching strace[1] to every child process and then performing an rdimport of an mp3 file. I can see from the strace's output that it loads libmad: 31590 open("/usr/lib/i386-linux-gnu/libmad.so", O_RDONLY|O_CLOEXEC) = 5 31590 read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\20\0\0004\0\0\0"..., 512) = 512 31590 fstat64(5, {st_mode=S_IFREG|0644, st_size=91448, ...}) = 0 31590 mmap2(NULL, 94292, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x1821000 31590 mmap2(0x1837000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x15) = 0x1837000 31590 close(5) I must still be missing something, but I can't tell what. Is there any other place where I have to make Rivendell aware that it has mp3 decoding capabilities? Thanks again for your help and insight, Nate "DJ Homebody" Hartmann [1] For anyone trying to reproduce that test, here's the full command: sudo service apache2 restart ; sudo rm -v /tmp/apache2.strace.* ; for pid in `pidof apache2` ; do sudo strace -f -p$pid -o/tmp/apache2.strace.$pid & done ; sleep 3; rdimport --log-mode TEST /tmp/your-test-file.mp3 ; sudo killall strace ; grep libmad /tmp/*strace* On Tue, Oct 15, 2013 at 5:38 PM, Nate Hartmann <[email protected]>wrote: > Thanks for looking at my problem Alban. I checked out those three options, > but am still hitting the same brick wall. > > Let me show you what I have, and maybe you can help me understand what > piece I'm missing. > > I have all three of those dev libraries installed: > $ dpkg -s libmad0-dev > Package: libmad0-dev > Status: install ok installed > Priority: optional > Section: libdevel > Installed-Size: 188 > Maintainer: Ubuntu Developers <[email protected]> > Architecture: i386 > Source: libmad > Version: 0.15.1b-7ubuntu1 > $ dpkg -s libtwolame-dev > Package: libtwolame-dev > Status: install ok installed > Priority: optional > Section: libdevel > Installed-Size: 463 > Maintainer: Ubuntu Developers <[email protected]> > Architecture: i386 > Source: twolame > Version: 0.3.13-1build1 > Replaces: libtwolame0-dev > Depends: libtwolame0 (= 0.3.13-1build1), libc6-dev, pkg-config > $ dpkg -s libmp3lame-dev > Package: libmp3lame-dev > Status: install ok installed > Priority: optional > Section: libdevel > Installed-Size: 490 > Maintainer: Ubuntu Developers <[email protected]> > Architecture: i386 > Source: lame > Version: 3.99.3+repack1-1 > Depends: libmp3lame0 (= 3.99.3+repack1-1) > > > Apparently my Ubuntu installation already had symbolic links named with > .so which point to the version-specific shared library file (e.g. > libmad.so.0.2.1) > $ file /usr/lib/libmad.so* /usr/lib/libtwolame.so* > /usr/lib/i386-linux-gnu/libmad.so* /usr/lib/i386-linux-gnu/libmp3lame.so* > /usr/lib/libmad.so: symbolic link to > `/usr/lib/i386-linux-gnu/libmad.so' > /usr/lib/libmad.so.0: symbolic link to > `/usr/lib/i386-linux-gnu/libmad.so' > /usr/lib/libtwolame.so: symbolic link to > `libtwolame.so.0.0.0' > /usr/lib/libtwolame.so.0: symbolic link to > `libtwolame.so.0.0.0' > /usr/lib/libtwolame.so.0.0.0: ELF 32-bit LSB shared object, > Intel 80386, version 1 (SYSV), dynamically linked, > BuildID[sha1]=0x5a1b8b2e2ac8c079be35bd8c81073d2c589cd036, stripped > /usr/lib/i386-linux-gnu/libmad.so: symbolic link to > `libmad.so.0.2.1' > /usr/lib/i386-linux-gnu/libmad.so.0: symbolic link to > `libmad.so.0.2.1' > /usr/lib/i386-linux-gnu/libmad.so.0.2.1: ELF 32-bit LSB shared object, > Intel 80386, version 1 (SYSV), dynamically linked, > BuildID[sha1]=0xd6f31fd3bf3caff864965ed52a425c1f5454251f, stripped > /usr/lib/i386-linux-gnu/libmp3lame.so: symbolic link to > `libmp3lame.so.0.0.0' > /usr/lib/i386-linux-gnu/libmp3lame.so.0: symbolic link to > `libmp3lame.so.0.0.0' > /usr/lib/i386-linux-gnu/libmp3lame.so.0.0.0: ELF 32-bit LSB shared object, > Intel 80386, version 1 (SYSV), dynamically linked, > BuildID[sha1]=0x7b3ac3b48da49661b14fc4ab89524a3a51510c96, stripped > > caed reports in the system log that it has the MAD decoding capabilities > during startup > $ grep -A2 -B2 -i caed.*mad /var/log/syslog |sed -e 's/.*u-11//' > ripcd: started > caed: Found TwoLAME encoder library, MPEG L2 encoding supported > caed: Found MAD decoder library, MPEG L2 decoding supported > caed: Unable to set realtime scheduling: No such process > caed: cae started > > Since that message is logged from within MainObject::LoadMad, I can tell > that libmad.so was successfully loaded during caed's startup. > > It was a little bit trickier, but I was able to verify that the CGI > program does successfully load libmad. I found this out by getting a fresh > apache2 environment, then attaching strace[1] to every child process and > then performing an rdimport of an mp3 file. I can see from the strace's > output that it loads libmad: > > 31590 open("/usr/lib/i386-linux-gnu/libmad.so", O_RDONLY|O_CLOEXEC) = 5 > 31590 read(5, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\20\0\0004\0\0\0"..., > 512) = 512 > 31590 fstat64(5, {st_mode=S_IFREG|0644, st_size=91448, ...}) = 0 > 31590 mmap2(NULL, 94292, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, > 5, 0) = 0x1821000 > 31590 mmap2(0x1837000, 8192, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x15) = 0x1837000 > 31590 close(5) > > I must still be missing something, but I can't tell what. Is there any > other place where I have to make Rivendell aware that it has mp3 decoding > capabilities? > > Thanks again for your help and insight, > Nate "DJ Homebody" Hartmann > > [1] For anyone trying to reproduce that test, here's the full command: > sudo service apache2 restart ; sudo rm -v /tmp/apache2.strace.* ; for pid > in `pidof apache2` ; do sudo strace -f -p$pid -o/tmp/apache2.strace.$pid & > done ; sleep 3; rdimport --log-mode TEST /tmp/your-test-file.mp3 ; sudo > killall strace ; grep libmad /tmp/*strace* > > > > On Mon, Oct 14, 2013 at 9:25 PM, Alban Peignier <[email protected]> wrote: > >> Hi Nate, >> >> Rivendell uses dlopen to find libmad.so, libmp3lame.so and libtwolame.so. >> >> On Debian/Ubuntu systems, these libraries are available as libmad.so.0, >> libmp3lame.so.0 and libtwolame.so.0. >> >> You can either : >> >> * create manual links >> * install the associated libXYZ-dev packages (with provided link) >> * apply the same patch as the debian packaging does [0] >> >> Or more simply use the debian/ubuntu packages :) >> >> 0. >> >> http://projects.tryphon.eu/projects/rivendell2-debian/repository/revisions/master/entry/debian/patches/0005-Add-version-for-dlopened-libraries.patch >> >> Regards, >> -- >> Alban Peignier - [email protected] >> >> Tryphon : Radio, Web et Logiciels Libres >> http://www.tryphon.eu >> > >
_______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
