Bugzilla – Bug 7279
flac binaries broken on Ubuntu AMD64
Last modified: 2009-09-08 09:14:22 UTC
As discussed in this thread: http://forums.slimdevices.com/showthread.php?t=43739 It seems the additional transcoding binaries supplied with the Ubuntu/Debian packages are 32 bit versions regardless of the package type installed. I have Ubuntu 7.10 AMD64 running and the binaries in /usr/share/squeezecentre/Bin/i386-linux are 32bit versions. When trying to run these directly a file not found error is shown - not terribly helpful, but indicative that the file is not executable on the target CPU. This exhibited itself with the AlienBBC plugin failing to transcode streams into FLAC format, but I suspect it would be the same if playing local FLAC audio files too. Replacing the flac binary with one from /usr/bin/flac fixed the problem. I haven't tested the other binaries (alac, sox etc.), but suspect they have the same issue going by the folder name.
please don't preset targets
Very sorry - I've never raised a bug on here before. Hope you can fix the problem anyway.
We shouldn't include Flac binaries with the package, we have a dependency on flac already. Sox too.
(In reply to comment #3) > We shouldn't include Flac binaries with the package, we have a dependency on > flac already. Sox too. > True, but I still find it curious that those binaries run fine for me on x86_64 CentOS. In the past I've also run the bundled (32-bit) mysqld binary on x86_64 Fedora. Maybe this is why the entire Bin directory was excluded from the old SlimServer deb package? Anyway, someone with access to a 64-bit Debian or Ubuntu box should probably also test alac, wvunpack, etc...
Not a show-stopper for 7.0. Please patch in trunk. Thx!
I'm seeing what looks like the same bug. The flac and wvunpack binaries in /usr/share/squeezecenter/Bin/i386-linux won't run. This showed up for me when I was unable to play tracks off of a flac with embedded cuesheet. I think the problem is that those 2 binaries are dynamically linked, and the others are statically linked. When I try running either of them at the command-line, I see: > ./flac zsh: no such file or directory: ./flac which I think is the dynamic linker unable to provide 32-bit libs. I worked around it by symlinking to the system flac. My preferred fix would be to just depend on system versions of all these binaries when possible, but I understand wanting to bundle dependencies, so just replacing those with statically linked binaries ought to work too. Information about my setup: SqueezeCenter Version: 7.0.1 - 17957 - Debian - EN - utf8 Perl Version: 5.8.8 x86_64-linux-gnu-thread-multi MySQL Version: 5.0.45-Debian_1ubuntu3.3 Platform Architecture: x86_64-linux Server Port Number: 9000 Total Players Recognized: 1 Cache Folder: /var/lib/squeezecenter/cache Preferences Folder: /var/lib/squeezecenter/prefs Plugin Folders: /usr/sbin/Slim/Plugin, /usr/share/perl5/Slim/Plugin, /usr/share/squeezecenter/Plugins Name: Squeezebox Model: Squeezebox v3 Firmware: 86 Wireless Signal Strength: 100
Ping Matt; have you made any progress on this?
Matt are we going to link to the system files for this? Can that change be made for 7.0.1?
It seems to me that the 'right' fix for this is to adjust the way we look for binaries in general. On a *nix system, we should only use our included binaries when the existing binares are no where to be found in the users already existin $path. If we made this change, anyone who already has a 'flac' binary on their system will use that instead and will likely get better performance and compatibility. I'm not sure where this change should be made in the code ... or what adverse affects it may have to other portions of code. Dean/Michael/Andy, Can any of you comment/look at it/implement the fix if it makes sense?
(In reply to comment #10) > It seems to me that the 'right' fix for this is to adjust the way we look for > binaries in general. On a *nix system, we should only use our included binaries > when the existing binares are no where to be found in the users already existin > $path. If we made this change, anyone who already has a 'flac' binary on their > system will use that instead and will likely get better performance and > compatibility. But that still won't fix it for people running AMD64 who don't have a system flac binary. Isn't the real problem here that the bundled binaries work fine on x86 but not (in some cases) on AMD64? > > I'm not sure where this change should be made in the code ... or what adverse > affects it may have to other portions of code. > The code that generalizes x86 and x86_64 is in OSDetect.pm.
We already require 'flac' as a package dependency for the package to install in the first place ... its not unreasonable to expect that if that package is installed, we can use the installed version of 'flac'.
(In reply to comment #12) > We already require 'flac' as a package dependency for the package to install in > the first place ... its not unreasonable to expect that if that package is > installed, we can use the installed version of 'flac'. > But my concern is that none of the bundled binaries seem to run on Debian/AMD64. What happens if someone wants to install from the tarball (or svn) on that platform? Based on these bug reports, my guess is that it will still be broken. Has anyone tested the tarball on Debian/AMD64? In that situation, we really have no control over which other packages are installed in the system.
Guys who're installing from a tarball should be able to install a binary on whatever system they are, shouldn't they? There are packages for Windows, OSX, and all major Linux distributions - whoever is running none of these should know why he does so, and be prepared for a bit more trouble. Matt - if I understand you right, we are already requiring flac, thus should _not_ use our own on system where this is a requirement? Then I'd say it would be easiest to exclude our binaries from packages which define a dependency (.deb in this case?).
(In reply to comment #14) > Guys who're installing from a tarball should be able to install a binary on > whatever system they are, shouldn't they? There are packages for Windows, OSX, > and all major Linux distributions - whoever is running none of these should > know why he does so, and be prepared for a bit more trouble. > > Matt - if I understand you right, we are already requiring flac, thus should > _not_ use our own on system where this is a requirement? Then I'd say it would > be easiest to exclude our binaries from packages which define a dependency > (.deb in this case?). > I agree that Matt's solution will fix the Deb package. I still think that shipping binaries that are broken on Debian/AMD64 but munging the arch so SC automatically finds them is bad. Shipping a second set of x86_64 Linux binaries is one possible fix, but would certainly bloat things.
Matt, are you the one to make this change?
Matt, is this going to be able to be done for the 7.0.1
I have removed the flac binary from the Debian build through change #18823. Tonight's nightly should have this fix in it.
Last nights build worked perfectly for me ... the Flac binary is not there, and everything else works fine. Closing this bug.
I should note that, as referenced in my comment, wvunpack is probably going to be broken for people too, because it fails in the same way as flac on my amd64 Ubuntu box and is similarly dynamically linked. I have no wavpack files so I haven't tested this end-to-end yet.
Reduce number of active targets for SC