libflashsupport useless on amd64

[Hari]

Binary package hint: libflashsupport

  $ file /usr/lib/libflashsupport.so
  /usr/lib/libflashsupport.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), stripped

This is useless for the flash plugin, which is 32-bit. So, we probably need a lib32flashsupport package.

[M (braurede-deactivatedaccount)]

Please see http://jean-christophe.dubacq.fr/index.php?post/2007/07/17/adobe-on-amd64-without-chroot-acrobat-flash for a solution

[the_vorpal_blade (the-vorpal-blade)]

The fix in the link no longer works. Installing it causes flash to be extremely unstable (it crashes after 5-10 seconds of video playback) and does not fix the sound problem. I'm running the most recent version of hardy.

I suggest an increase in severity, since this should is a problem in the default install of the 64 bit version that is extremely annoying to the average user.

[the_vorpal_blade (the-vorpal-blade)]

Or rather, not in the default install, but in an oft-installed component.

[Jeremy Visser (jeremy-visser)]

I cannot think of a single user persona (except for maybe Richard Stallman) that would not install Flash at some point in time. So yeah, I agree, it's pretty serious.

[Oliver Grawert (ogra)]

can you please test with the libflashsupport from the archive ? (hardy only)
if it works someone could probably ask for a backport.

[Kai Schroeder (kai-schroeder)]

libflashsupport from the archive also does not work

[Jeremy Visser (jeremy-visser)]

Yep, running Hardy here. No dice.

[Joonas Javanainen (gekkio)]

I managed to compile 32-bit libflashsupport with a simple hack.
Luckily ia32-libs package contains all the 32-bit libraries needed, so all I had to do was recompile the package with -m32 and /usr/lib32 as library path.
Also, two symlinks are required in /usr/lib32.
Please note that this is completely untested, but it works for me.

I also uploaded the compiled package to
http://www.jawsy.org/ubuntu/hardy/

If it works with these simple modifications, all we need is someone to fiddle with the debian packaging to create lib32flashsupport.

Quick instructions:
sudo apt-get install fakeroot dpkg-dev ia32-libs
sudo apt-get build-dep libflashsupport
sudo ln -s /usr/lib32/libgnutls.so.13 /usr/lib/32/libgnutls.so
sudo ln -s /usr/lib32/libpulse.so.0 /usr/lib32/libpulse.so
apt-get source libflashsupport
cd libflashsupport-1.9
patch -p0 < where_the_patch_file_is
fakeroot dpkg-buildpackage
cd ..
You'll find the deb here. It has the same name as the 64-bit one so the 64-bit is replaced (doesn't matter at this point anyway).

[Jonathan Rogers (jonner)]

Thank you very much for the package. It seems it's now quite a bit easier to build libflashsupport on x86_64 than it was a couple of months ago when I did it on my Hardy machine, since more libraries like libpulse and libgnutls have been added to ia32-libs. However, I did have to do a couple of extra things to get your package to work on my system.

First, I assume that the third line in your instructions should read "sudo ln -s /usr/lib32/libgnutls.so.13 /usr/lib32/libgnutls.so". Are those symlinks even necessary? On my machine, they don't seem to be, since /usr/lib32/libflashsupport.so from your package links to /usr/lib32/libpulse.so.0 and /usr/lib32/libgnutls.so.13 from ia32-libs. Did you need those symlinks to build the package?

Second, ia32-libs still doesn't seem to include /lib32/libcap.so.1, which /usr/lib32/libflashsupport.so from your package links to. I simply copied the libcap.so.1.10 from the i386 libcap1 package to /lib32 and ran "sudo ldconfig". Did you do something like that on your machine?

So, in summary, it looks like the main things remaining is for libcap.so.1 to be added to ia32-libs and for patch to be accepted.

[Jonathan Rogers (jonner)]

Joonas, which version of gcc do you have installed? I have gcc version 4.2.3-1ubuntu3 and gcc-4.2 version 4.2.3-2ubuntu1 installed. However, my gcc command does not seem to be able to build 32-bit binaries using the -m32 option. When I follow your instructions, configure complains that the compiler can't create executables. I believe the problem is with the static libgcc the gcc uses when linking. I have also installed gcc-3.4 version 3.4.6-6ubuntu3 for comparison.

The command "gcc -print-libgcc-file-name" returns "/usr/lib/gcc/x86_64-linux-gnu/4.2.3/libgcc.a" which looks right. However, "gcc -m32 -print-libgcc-file-name" gives me exactly the same result: "/usr/lib/gcc/x86_64-linux-gnu/4.2.3/libgcc.a" which can't be right.

In contrast "gcc-3.4 -print-libgcc-file-name" gives me "/usr/lib/gcc/x86_64-linux-gnu/3.4.6/libgcc.a" and "gcc-3.4 -m32 -print-libgcc-file-name" gives me "/usr/lib/gcc/x86_64-linux-gnu/3.4.6/32/libgcc.a".

As far as I can tell, this is a serious bug in the Hardy gcc-4.2 (and gcc-4.1) packages, so I probably need to submit separately.

[Jonathan Rogers (jonner)]

I was able to follow Joonas's instructions, only adding CC=gcc-3.4 to debian/rules to avoid the buggy default gcc-4.2. Of course, this is just a workaround, when it's really gcc-4.2 that needs to be fixed.

[Jonathan Rogers (jonner)]

Forget my patch, as I was ignorant of the gcc-multilib packages which seem to only exist for gcc-4.x. I think it's quite confusing that on my Hardy system, "gcc-3.4 -m32" works properly with no -multilib packages installed, while "gcc-3.3 -m32", "gcc-4.1 -m32", and "gcc-4.2 -m32" don't.

Now that I have gcc-multilib and gcc-4.2-multilib installed, Joonas' patch works fine for me as long as I have the 32-bit libcap.so.1.10 installed manually. I do need the symlinks /usr/lib32/libpulse.so and /usr/lib32/libgnutls.so to build, though I'm not sure why, as they're not needed at runtime. So, here's a slightly updated version of the build instructions, still using Joonas' original patch:

Quick instructions:
sudo apt-get install fakeroot dpkg-dev ia32-libs gcc-multilib
sudo apt-get build-dep libflashsupport
sudo ln -s /usr/lib32/libgnutls.so.13 /usr/lib32/libgnutls.so
sudo ln -s /usr/lib32/libpulse.so.0 /usr/lib32/libpulse.so
apt-get source libflashsupport
cd libflashsupport-1.9
patch -p0 < where_the_patch_file_is
fakeroot dpkg-buildpackage
cd ..
You'll find the deb here. It has the same name as the 64-bit one so the 64-bit is replaced (doesn't matter at this point anyway).

[Joonas Javanainen (gekkio)]

Thanks for testing the patch, that was quicker than I expected. :)

Jonathan said: "Joonas' patch works fine for me as long as I have the 32-bit libcap.so.1.10 installed manually. "
I noticed that I had installed manually a 32-bit version of libcap earlier (I built libflashsupport on gutsy using almost the same way as now), so indeed it has to be added to ia32-libs first.
I used libflashsupport on my 64-bit gutsy almost since gutsy was released, so my patch shouldn't create any major stability problems. This bug is a major one for AMD64 users, so it should be resolved before hardy release.

Please also note that the patch modifies the build rules so that it probably won't build on i386 anymore. A simple way to fix this would be AFAIK to create separate libflashsupport and lib32flashsupport packages from the same source package. But the package uses cdbs, which seems to not support building two different packages with different build options from the same source.
If I have some spare time, I'll rewrite the build rules to build both 32-bit and 64-bit packages. Then we only need libcap in ia32-libs and a solution to the symlinks issue when building the package.

[TRiSS (triss)]

running this command:

getlibs -p libflashsupport

made flash have sound on my hardy x86_64 system.... so adding a 32bit libflashsupport definately seems the way to go.... (getlibs is a utility that installs 32bit libraries for you, see http://ubuntuforums.org/showthread.php?t=474790)

[the_vorpal_blade (the-vorpal-blade)]

Does this mean that the patch is unnecessary, and all we need is libpcap in lib32?
I went ahead and reinstalled the version in the repos, and still have sound in flash (with the manually installed libpcap) so I think the answer is yes, unless the patched version has been packaged recently.

[Jonathan Rogers (jonner)]

No, the libflashsupport binary package on amd64 contains a 64-bit library. This is completely useless because there is no 64-bit proprietary flash plugin. The source package must be changed to cause it to build a 32-bit libflashsupport binary on amd64, which the 32-bit flash plugin can use.

[Christian Roessner (christian-roessner-net)]

I fixed that problem in an other manner:

I did aptitude download libflashsupport on a 32bit system and copied the deb package to my 64bit system.

Then created a directory under /usr/local/src. In my case I called it libflashsupport-i386

Then:

dpkg -x libflashsupport_1.9-0ubuntu2_i386.deb /usr/local/src/libflashsupport-i386

/usr/local/src/libflashsupport-i386/usr/lib:
ldd libflashsupport.so
 linux-gate.so.1 => (0xf7f6d000)
 libpulse.so.0 => /usr/lib32/libpulse.so.0 (0xf7eff000)
 libgnutls.so.13 => /usr/lib32/libgnutls.so.13 (0xf7e85000)
 libc.so.6 => /lib32/libc.so.6 (0xf7d26000)
 libSM.so.6 => /usr/lib32/libSM.so.6 (0xf7d1d000)
 libICE.so.6 => /usr/lib32/libICE.so.6 (0xf7d05000)
 libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7c17000)
 libcap.so.1 => /lib32/libcap.so.1 (0xf7c13000)
 librt.so.1 => /lib32/librt.so.1 (0xf7c0a000)
 libdl.so.2 => /lib32/libdl.so.2 (0xf7c05000)
 libm.so.6 => /lib32/libm.so.6 (0xf7bdf000)
 libpthread.so.0 => /lib32/libpthread.so.0 (0xf7bc6000)
 libtasn1.so.3 => /usr/lib32/libtasn1.so.3 (0xf7bb4000)
 libz.so.1 => /usr/lib32/libz.so.1 (0xf7b9e000)
 libgcrypt.so.11 => /lib32/libgcrypt.so.11 (0xf7b35000)
 /lib/ld-linux.so.2 (0x46452000)
 libxcb-xlib.so.0 => /usr/lib32/libxcb-xlib.so.0 (0xf7b31000)
 libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7b18000)
 libgpg-error.so.0 => /lib32/libgpg-error.so.0 (0xf7b14000)
 libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7b11000)
 libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7b0c000)

looked ok for me.

cd /usr/lib32/
ln -s /usr/local/src/libflashsupport-i386/usr/lib/libflashsupport.so
ldconfig

Started firefox and played a youtube video. While playing:

lsof | grep libflashsupport
npviewer. 14357 croessner mem REG 253,0 10924 2901271 /usr/local/src/libflashsupport-i386/usr/lib/libflashsupport.so

So, as you can see it is working and you do not need to compile or replace the 64bit package. But it was really great to have a lib32flahsupport package for intrepid. This is a sad solution to compile or to do my trick. Just only advanced users will get this to work. So please a word to the current package maintainer: Can you please create the required package? I would do this, if I knew more about debian packaging.