You are here: Home » Reply

Reply To: The case for reviving Firefly

#18765

mas
Participant

Ok, after about 2h of fixing the dependency issues I got it and what an amazingly long lib list:

-rwxr-xr-x 1 root root 1175053 16. Mar 16:05 forked-daapd
sprinter sbin # ldd -r forked-daapd
linux-gate.so.1 => (0xb7783000)
libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0xb7767000)
libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb772d000)
libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0xb7720000)
libdl.so.2 => /lib/libdl.so.2 (0xb771c000)
libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb7653000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7639000)
libavcodec.so.52 => /usr/lib/libavcodec.so.52 (0xb6d7c000)
libavformat.so.52 => /usr/lib/libavformat.so.52 (0xb6cd0000)
libswscale.so.0 => /usr/lib/libswscale.so.0 (0xb6ca2000)
libavutil.so.50 => /usr/lib/libavutil.so.50 (0xb6c8f000)
libconfuse.so.0 => /usr/lib/libconfuse.so.0 (0xb6c83000)
libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0xb6c49000)
libogg.so.0 => /usr/lib/libogg.so.0 (0xb6c42000)
libm.so.6 => /lib/libm.so.6 (0xb6c1c000)
libtag_c.so.0 => /usr/lib/libtag_c.so.0 (0xb6c17000)
libtag.so.1 => /usr/lib/libtag.so.1 (0xb6b7f000)
libevent_core-1.4.so.2 => /usr/lib/libevent_core-1.4.so.2 (0xb6b75000)
libnsl.so.1 => /lib/libnsl.so.1 (0xb6b5d000)
librt.so.1 => /lib/librt.so.1 (0xb6b54000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb6b3f000)
libavl.so.1 => /usr/local/lib/libavl.so.1 (0xb6b3c000)
libantlr3c.so => /usr/lib/libantlr3c.so (0xb6b26000)
libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb6ab0000)
libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb6aaa000)
libc.so.6 => /lib/libc.so.6 (0xb6960000)
/lib/ld-linux.so.2 (0xb7784000)
libz.so.1 => /lib/libz.so.1 (0xb694c000)
libmp3lame.so.0 => /usr/lib/libmp3lame.so.0 (0xb68d7000)
libopenjpeg.so.2 => /usr/lib/libopenjpeg.so.2 (0xb68b9000)
libspeex.so.1 => /usr/lib/libspeex.so.1 (0xb68a1000)
libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb67a7000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb677d000)
libx264.so.78 => /usr/lib/libx264.so.78 (0xb6707000)
libxvidcore.so.4 => /usr/lib/libxvidcore.so.4 (0xb661c000)
libbz2.so.1 => /lib/libbz2.so.1 (0xb6609000)
libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/libstdc++.so.6 (0xb651d000)
libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/libgcc_s.so.1 (0xb650f000)



Was quite a nightmare to get this to compile on gentoo-linux. Except installing the antlr3 packages it was required to

1. Manually download the avl-0.3.5 source, compile it and install it manually as the makefile of this old package seems to be not compatible with a modern Make version really. Sorry, such old, outdated stuff should not be used any more. Theres likely a reason that no gentoo ebuilt exists for this. I bet it will give trouble in other distributions as well.

2. Manually downloading and installing the runtime/C stuff and headers as the existing antl3 package from gentoo didn’t seem to include the headers from the C runtime. Also nasty but I am blaming gentoo here. Seems theit antlr3 isn’t a real developer package.

I haven’t yet found time to really test the forked-mtdaapd executable, but in order to use it as a substitute or starting point for new development I think that it would be necessary to rework the code from forked-daapd to not use antlr and avl as I foresee otherwise problems also with other distributions.
And we would likely want something that at least runs on the Top10 linux distributions without too many troubles of portability.
It would also not be a bad thing to remove eventually some of the dependencies, as the list is mighty long.

Just compare to the old mt-daapd version, which is also half the size of the binary:

sprinter sbin # ldd -r /usr/sbin/mt-daapd
linux-gate.so.1 => (0xb7868000)
libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0xb7850000)
libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0xb783f000)
libdl.so.2 => /lib/libdl.so.2 (0xb783b000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7822000)
libid3tag.so.0 => /usr/lib/libid3tag.so.0 (0xb7810000)
libz.so.1 => /lib/libz.so.1 (0xb77fc000)
libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb7732000)
libogg.so.0 => /usr/lib/libogg.so.0 (0xb772b000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb7701000)
libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0xb76f8000)
libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0xb76bf000)
libc.so.6 => /lib/libc.so.6 (0xb7575000)
libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb753a000)
/lib/ld-linux.so.2 (0xb7869000)
libm.so.6 => /lib/libm.so.6 (0xb7514000)

So in short, why is this fork – after stripping some functions out – using soo many libraries?