Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Flash 10 release candidate has been released at adobe labs.
Created an attachment (id=162737) [edit] flash player 10 release candidate
ah btw.. there are new dependencies.. dev-libs/nss net-misc/curl >=sys-libs/glibc-2.4 i added them in DEPEND
I was just fiddling about with the release candidate myself. There is indeed a further dependency on libcurl.so.3. The problem is that I only have libcurl.so.4.1.0 installed in /usr/lib by =net-misc/curl-7.18.2 (and thus libcurl.so.4). I have Adobe Reader installed and that has the appropriate library /opt/Adobe/Reader8/Reader/intellinux/lib/libcurl.so.3.0.0 which I copied to ~/.mozilla/plugins and then set up the appropriate symlink for libcurl.so.3 After that I had to run: export LD_LIBRARY_PATH=".:${LD_LIBRARY_PATH}" /usr/bin/firefox Naturally this was merely to test, and the only way to actually get the plugin to load -- firefox will ignore a plugin if all the required dependencies cannot be resolved. Requiring net-misc/curl is not enough due to the absence of libcurl.so.3
Created an attachment (id=162741) [edit] shared library dependencies Note: libcurl.so.3 is not found even with net-misc/curl emerged as libcurl.so.4 is put into /usr/lib but not libcurl.so.3
yes you're right. the same problem with lib{ssl,crypto}.so.o.9.7 i don't have them anymore.. and the flashplayer needs them now (libcurl.so.3 does) a solution would be to add acroread as a dep... but i rather unmerge flashplayer than emerge acroread :) how about creating an adobe-lib package? is that possible? or are there licence problems?
I don't really seem to have a problem with lib{ssl,crypto}.so.o.9.7 as they are both present in /usr/lib and merged as part of =dev-libs/openssl-0.9.8g-r2 It does seem, however, that they are provided in /opt/Adobe/Reader8/Reader/intellinux/lib along with libcurl.so.3. Many packages seem to be naughty and keep their own local copies of libcurl.so.3 so that they don't need to update to support libcurl.so.4. If you run equery b libcurl.so.{3,4} you can see the those that do (and probably that there is only libcurl.so.4 in /usr/lib). The following use their own copies of libcurl.so.3 for me: =app-office/openoffice-bin-2.4.1 =app-text/acroread-8.1.2-r3 =x11-misc/googleearth-4.2.205.5730 Could we have an adobe-libs? I don't think that would really be correct imho. The problem is that Adobe are not the only deviants. There are a few solutions I can think of: 1) Have a net-misc/curl-compat to provide older libcurl libraries. 2) Can net-misc/curl still build libcurl.so.3.x? If so, a "compat" use-flag. 3) Upstream fix: Get Adobe to change their package to install along with libcurl.so.3. This I think is unlikely due to the way that they handle flash player in the first place (i.e. possibility to install in user plugins folder demolishes sense of installer adding libcurl.so.3) 4) Upstream fix: Ask curl team to stick support in for older versions... But this pushes things backwards really. Application developers should update to newer library. Order of preference? 2, 1, 3, 4.
i agree, this would be a proper solution.. but i guess it's a little time consuming. so i made a version which depends on acroread. later we can add some curl use flags or whatever to do it right. ok?
oh about lib{ssl,crypto}.0.9.7, i think those shouldn't be there. afair i deleted them because it said so in an upgrade of openssl.. so i added them too as symlinks.
Created an attachment (id=162757) [edit] flash player 10 release candidate this one has the acroread dependency
There is still one problem with using app-text/acroread as a temporary dependency solution and symlinking into /usr/lib - I feel that this leads to clutter and potential problems should a better way of fixing the libcurl problem be introduced. Is it not better to add /etc/env.d/99netscape-flash-lib-hack containing: LDPATH="/opt/Adobe/Reader8/Reader/intellinux/lib" And then you would have to call update-env to ensure that the libraries were added to the dynamic library cache. This can then be better removed on unmerge with less chance of side effects? Perhaps I am just being picky! As for the lib{ssl,crypto}.0.9.7 thing, I do have lib{ssl,crypto}.0.9.8 also: $ equery b libcrypto.so.0.9.{7..8} [ Searching for file(s) libcrypto.so.0.9.7,libcrypto.so.0.9.8 in *... ] ... dev-libs/openssl-0.9.8g-r2 (/usr/lib/libcrypto.so.0.9.8) dev-libs/openssl-0.9.8g-r2 (/usr/lib/libcrypto.so.0.9.7) $ equery b libcrypto.so [ Searching for file(s) libcrypto.so in *... ] ... dev-libs/openssl-0.9.8g-r2 (/usr/lib/libcrypto.so -> libcrypto.so.0.9.8) Both are provided. I don't recall a message saying to remove one, but there is usually a request that you revdep-rebuild I think to ensure that applications link against the newer library where feasible.
i linked the required libs into /usr/lib/nsbrowser/plugins. but the env file looks also good.. :) ah sorry for not being specific. i'm using openssl 0.9.8h-r1.. in this package the 0.9.7 version is obsolete. > equery b libssl.so.0.9.{7..8} [ Searching for file(s) libssl.so.0.9.7,libssl.so.0.9.8 in *... ] app-text/acroread-8.1.2-r3 (/opt/Adobe/Reader8/Reader/intellinux/lib/libssl.so.0.9.7) net-www/netscape-flash-10_rc20080811 (/usr/lib/nsbrowser/plugins/libssl.so.0.9.7 -> /opt/netscape/plugins/libssl.so.0.9.7) net-www/netscape-flash-10_rc20080811 (/opt/netscape/plugins/libssl.so.0.9.7 -> /opt/Adobe/Reader8/Reader/intellinux/lib/libssl.so.0.9.7) dev-libs/openssl-0.9.8h-r1 (/usr/lib/libssl.so.0.9.8)
i just read in an official blog that a symlink from libcurl.so.4 to libcurl.so.3 should work :) that would fix all our problems, right? :)
Created an attachment (id=162772) [edit] flash player 10 release candidate, libcurl.so.4 -> libcurl.so.3 link i linked from libcurl.so.4 to libcurl.so.3 as mentioned here: http://blogs.adobe.com/penguin.swf/2008/08/10rc1.html quote mike m. "A symlink should serve as a good solution until we find a better, more transparent solution." it works for me.. and i think for a temporary fix it's good enough.
symlink is not good, think about amd64 too...we need 32bit binary.... the LDPATH is good instead.
A few points: Problems with x86_64 require an upstream solution -- there is no 64-bit compatible flash player as yet. I have no 64-bit machine available to check on, but are there not usually both 32-bit and 64-bit libraries available on the system? I don't really have much knowledge of that I'm afraid. Otherwise a symlink to the appropriate one depending on architecture would be the best solution. It should be noted that symlinking from .4 to .3 is only a temporary option, and is certainly not ideal. As Mike M. says on that blog: [A symlink should serve as a good solution until we find a better, more transparent solution. -Mike M.] This ebuild should not become stable with such a hack. Another problem remains with the latest version that you've put up. If you execute cat /etc/ld.so.conf, you will not see /usr/lib/nsbrowser/plugins listed, and thus the libcurl.so.3 will not be found by libflashplayer.so unless the current directory were explicitly checked which is unlikely to happen. That leaves three options for the temporary hack approach: 1) The /etc/env.d/99netscape-flash-lib-hack from comment #10 2) Put the symlink in /usr/lib 3) Put the symlink in /usr/lib/nsbrowser/plugins and make that the LDPATH in the env file from comment #10. (About the openssl libraries -- no worries. I didn't realise you were using a later unstable build. This is another problem to think about, however, if either of the symlink [.3 --> .4] or upstream change to flash player approaches don't work out as an end solution. I have a feeling that Adobe might make a change however given the list of distributions for which the rc plugin fails.)
no symlink is good because adobe sw is crap. symlink from an ebuild which has nothing to do with that lib is wrong as concept. i totally agree with problems....i understand....but this is not a nice solution, even for unstable. (and...i'm bleeding edge user!)
More information about symlinking to libcurl.so.4. Turns out that the ABI is supposedly the same. Other distributions have already taken this approach despite being ugly. See http://wtogami.livejournal.com/2008/08/11/
if ABi is the same we can just hexedit the bin file and move .3 to .4 i always do it :)
Surely you mean edit a copy of .4 to make it .3. This could potentially work -- probably better to just copy the .3 from app-text/acroread though and have the real thing, however, or stick with the symlink.
no i mean: hexedit libflashflaplayer.so and change the .3 to .4.... like you would edit a normal file, but in hex.
Ah, sorry. Yes. That sounds like a very good solution :) I was so embroiled in the discussion on libcurl that I misunderstood. I've hexedited libflashplayer.so, produced a patch and updated the ebuild. (You'll have to check I've done the right thing in the ebuild -- don't modify them that often.)
Created an attachment (id=162893) [edit] flash player 10 release candidate, binary patch --> libcurl.so.4 The binary patch file to update libflashplayer.so
Created an attachment (id=162895) [edit] flash player 10 release candidate, binary patch --> libcurl.so.4 The updated ebuild for the patch.
Bad news, folks... though it is an elegant solution, this editing of the binary is probably prohibited by the '2.5 No modification' clause of the license. I have requested permission from adobe to allow this change, but I don't expect they'll get back to me soon - We may be stuck with the symlink trick. Though perhaps I'll try contacting the curl maintainer and see if they'll consider adding a .3 symlink in their ebuild - easier to manage for everyone that needs the older version... Btw, I'm on holiday right now, so I won't get this into the tree until probably mid next week. Thanks very much for the ebuilds and patches!
Argh. Didn't think about that. If they say no, it would suck - it is only changing a single byte (in fact, two bits!) Thanks for contacting them - enjoy the rest of your holiday. [By the way - this release is quite nice - just been using it. It largely fixes transparency and z-index issues. Finally - decent flash support under Linux.]
(In reply to comment #23) > Created an attachment (id=162895) [edit] > flash player 10 release candidate, binary patch --> libcurl.so.4 > > The updated ebuild for the patch. > There is a typo in the ebuild. replace: epatch ${FILES_DIR}/netscape-flash-10_rc20080811-libcurl-hack.patch.bz2 with: epatch ${FILESDIR}/netscape-flash-10_rc20080811-libcurl-hack.patch.bz2 With that change the ebuild worked for me. I can confirm that flash transparancy works now together with www-client/mozilla-firefox-bin-3.0.1-r1.
(In reply to comment #25) > Argh. Didn't think about that. If they say no, it would suck - it is only > changing a single byte (in fact, two bits!) > > Thanks for contacting them - enjoy the rest of your holiday. I hope I shall be adding this to the tree soon, just waiting on some input from other devs and the Gentoo Foundation on whether or not the binary patch is allowed or not. If it is not, I will still add this but with the libcurl.so.3 symlink. =========== Note to myself: I will also be adding the new 'mms.cfg' file, detailed at http://www.adobe.com/devnet/flashplayer/articles/flash_player_admin_guide.html
Nick Pope, thanks for your ebuild and binary patch. But How to do with amd64 mechine? My system is 64bit. My keywords in make.conf is ~amd64. I emerged your ebuild netscape-flash-10_rc20080811.ebuild, then $ ldd /opt/netscape/plugins/libflashplayer.so The output is below: linux-gate.so.1 => (0xf7ef0000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/32/libstdc++.so.6 (0xf7393000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf737b000) libX11.so.6 => /usr/lib32/libX11.so.6 (0xf728f000) libXext.so.6 => /usr/lib32/libXext.so.6 (0xf727f000) libXt.so.6 => /usr/lib32/libXt.so.6 (0xf722f000) libfreetype.so.6 => /usr/lib32/libfreetype.so.6 (0xf71af000) libfontconfig.so.1 => /usr/lib32/libfontconfig.so.1 (0xf7185000) libcurl.so.4 => not found libgtk-x11-2.0.so.0 => /usr/lib32/libgtk-x11-2.0.so.0 (0xf6e24000) libgdk-x11-2.0.so.0 => /usr/lib32/libgdk-x11-2.0.so.0 (0xf6da2000) libatk-1.0.so.0 => /usr/lib32/libatk-1.0.so.0 (0xf6d87000) libgdk_pixbuf-2.0.so.0 => /usr/lib32/libgdk_pixbuf-2.0.so.0 (0xf6d6f000) libpangoxft-1.0.so.0 => /usr/lib32/libpangoxft-1.0.so.0 (0xf6d67000) libpangox-1.0.so.0 => /usr/lib32/libpangox-1.0.so.0 (0xf6d5a000) libpango-1.0.so.0 => /usr/lib32/libpango-1.0.so.0 (0xf6d1f000) libgobject-2.0.so.0 => /usr/lib32/libgobject-2.0.so.0 (0xf6ce4000) libgmodule-2.0.so.0 => /usr/lib32/libgmodule-2.0.so.0 (0xf6ce0000) libdl.so.2 => /lib32/libdl.so.2 (0xf6cdc000) libglib-2.0.so.0 => /usr/lib32/libglib-2.0.so.0 (0xf6c1f000) libssl3.so => not found libnss3.so => not found libnspr4.so => not found libm.so.6 => /lib32/libm.so.6 (0xf6bf8000) libgcc_s.so.1 => /lib32/libgcc_s.so.1 (0xf6bea000) libc.so.6 => /lib32/libc.so.6 (0xf6aaa000) /lib/ld-linux.so.2 (0xf7ef1000) libXau.so.6 => /usr/lib32/libXau.so.6 (0xf6aa5000) libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf6a9f000) libSM.so.6 => /usr/lib32/libSM.so.6 (0xf6a96000) libICE.so.6 => /usr/lib32/libICE.so.6 (0xf6a7e000) libz.so.1 => /lib32/libz.so.1 (0xf6a6b000) libexpat.so.1 => /usr/lib32/libexpat.so.1 (0xf6a49000) libpangocairo-1.0.so.0 => /usr/lib32/libpangocairo-1.0.so.0 (0xf6a3f000) libXcomposite.so.1 => /usr/lib32/libXcomposite.so.1 (0xf6a3b000) libXdamage.so.1 => /usr/lib32/libXdamage.so.1 (0xf6a37000) libXfixes.so.3 => /usr/lib32/libXfixes.so.3 (0xf6a31000) libcairo.so.2 => /usr/lib32/libcairo.so.2 (0xf69bf000) libXrender.so.1 => /usr/lib32/libXrender.so.1 (0xf69b6000) libXinerama.so.1 => /usr/lib32/libXinerama.so.1 (0xf69b2000) libXi.so.6 => /usr/lib32/libXi.so.6 (0xf69a9000) libXrandr.so.2 => /usr/lib32/libXrandr.so.2 (0xf69a2000) libXcursor.so.1 => /usr/lib32/libXcursor.so.1 (0xf6997000) libpangoft2-1.0.so.0 => /usr/lib32/libpangoft2-1.0.so.0 (0xf6969000) libXft.so.2 => /usr/lib32/libXft.so.2 (0xf6956000) libpng12.so.0 => /usr/lib32/libpng12.so.0 (0xf6932000) You can see there are 4 shared libraries not found. libcurl.so.4 => not found libssl3.so => not found libnss3.so => not found libnspr4.so => not found Exactly, the 4 shared libraries are not found in /usr/lib32, but are found in /usr/lib64 in my system. How do I install the 32bit version of the 4 shared libraries? It seems the acroread dependency and LDPATH setting must be still needed on amd64 system. acroread provides libcurl.so.3 of 32bit, and it depends on xulrunner-bin which provides the rest 3 shared libraries of 32bit. Jim Ramsay, Nick Pope please think about the 64bit mechine, and help me and people like me. Thank you:)
@ kouyu: Please refer to my previous: http://bugs.gentoo.org/show_bug.cgi?id=234542#c15 64-bit support is completely lacking in Adobe Flash. This is an upstream problem. The only way that we could possibly have flash working under 64-bit systems is if the following conditions are met: 1) You are running a 32-bit copy of Firefox (or other supported browser). I have also heard there is a way of having a 64-bit and separate 32-bit firefox profile. You'll have to research. There is also net-www/nspluginwrapper as discussed at http://gentoo-wiki.com/HOWTO_AMD64/flash, but I read somewhere else that this may no longer work. 2) You would need to find binary copies of the missing 32-bit libraries. Gentoo has some x86 compatibility libraries in portage (app-emulation/emul-linux-x86-*) but looking at http://www.gentoo.org/proj/en/base/amd64/emul/content.xml I can't see the appropriate packages emulated. I ran equery b lib{nss,ssl}3.so libcurl.so.4 libnspr4.so to identify the core packages that contain your missing 32-bit libraries. They are: dev-libs/nss dev-libs/nspr net-misc/curl If you could find someone to create an app-emulation/emul-linux-x86-net or something to solve this problem, it would be the best solution. (Otherwise track down some 32-bit binaries and drop them in /usr/lib32 -- this is a nasty thing to do though as then no package is "managing" them.) I cannot test anything, as I have no access to a 64-bit machine. If we cannot get 64-bit to work at all, perhaps we should remove ~amd64 from the ebuild keywords.
More info I've just dug up. It looks like by 10 final Adobe might have a better solution to the libcurl problem: http://blogs.adobe.com/penguin.swf/2008/08/curl_tradeoffs.html Also, there are semi-official rumours of 64-bit support, but no official plan for release as yet: http://blogs.adobe.com/penguin.swf/2008/08/random_blog_post.html I get the impression that Adobe are probably a little embarrassed by the open source offerings (which don't support many of the flash 9+ features before anyone starts using them) having 64-bit support and are probably working very hard to include it in their official plug-in. So keep watching ;)
(In reply to comment #29) > @ kouyu: > > Please refer to my previous: http://bugs.gentoo.org/show_bug.cgi?id=234542#c15 Yes, I had seen > > 64-bit support is completely lacking in Adobe Flash. This is an upstream Yes, I also had known this fact. > problem. The only way that we could possibly have flash working under 64-bit > systems is if the following conditions are met: > > 1) You are running a 32-bit copy of Firefox (or other supported browser). I > have also heard there is a way of having a 64-bit and separate 32-bit firefox > profile. You'll have to research. There is also net-www/nspluginwrapper as > discussed at http://gentoo-wiki.com/HOWTO_AMD64/flash, but I read somewhere > else that this may no longer work. > > 2) You would need to find binary copies of the missing 32-bit libraries. > Gentoo has some x86 compatibility libraries in portage > (app-emulation/emul-linux-x86-*) but looking at > http://www.gentoo.org/proj/en/base/amd64/emul/content.xml I can't see the > appropriate packages emulated. Yes, the both methods are good. But I think you have a little misunderstanding. I think I should tell you first about this: I have been using flash plugin of firefox for a long time, it can work with firefox on my 64bit mechine after I have done this only: $ emerge netscape-flash $ emerge nspluginwrapper $ nspluginwrapper -i /usr/lib32/nsbrowser/plugins/libflashplayer.so And then firefox can play flash, such as youtube video. But before today, netscape-flash emerged in my system was netscape-flash-10_beta20080702(not 10_rc20080811) which is in official portage tree, and that version did not depend on libcurl.so.3 libssl3.so libnss3.so libnspr4.so. So that version can be emerged and work. netscape-flash-10_beta20080702 can be used under nspluginwrapper's help on my 64bit mechine, so that is why I still asked you how to use netscape-flash-10_rc20080811 on 64bit mechine, though I had known adobe doesn't support 64bit flash. > > I ran equery b lib{nss,ssl}3.so libcurl.so.4 libnspr4.so to identify the core > packages that contain your missing 32-bit libraries. They are: > dev-libs/nss > dev-libs/nspr > net-misc/curl Yes, I knew this. I told you in my last comment libnss3.so libssl3.so libnspr4.so can be found in my system, in /usr/lib64, but not in /usr/lib32. Because the packages which they belong to are not x86 emulation libraries, but are native libraries. So they are 64bit libraries and installed in /usr/lib64 not /usr/lib32. On 64bit mechine, the all libraries which netscape-flash-10_rc20080811 depends on are x86 emulation libraries. So you can see the all libraries are in /usr/lib32. Because they are provided by app-emulation/emul-linux-x86-*, and I emerged them all already. But that 4 libraries(libnss3.so libssl3.so libnspr4.so libcurl.so.3) are not provided by them. And I also told you that I had found which packages provide that 4 libraries: libnss3.so libssl3.so libnspr4.so are provided by net-libs/xulrunner-bin libcurl.so.3 is provided by app-text/acroread (You told me this) So in my last comment I said the acroread dependecy may be still needed for 10_rc20080811 on 64bit mechine as well as xulrunner-bin. But I also saw you said "There is still one problem with using app-text/acroread as a temporary dependency solution and symlinking into /usr/lib - I feel that this leads to clutter and potential problems should a better way of fixing the libcurl problem be introduced. " in comment #10. Since you said depending on acroread is a temporary solution, and fixing libcurl problem is introduced, I think on 32bit system the solution may be adding libcurl.so.3 in net-misc/curl package, but on 64bit the solution may be adding a new emul-linux-x86-? package. Same with xulrunner-bin. That is why I asked you and Jim Ramsay to think about 64bit mechine. I am trying to remind you not to forget 64bit mechine which the previous version of netscape-flash can work with firefox on, when you are looking for the solutions. > > If you could find someone to create an app-emulation/emul-linux-x86-net or > something to solve this problem, it would be the best solution. (Otherwise > track down some 32-bit binaries and drop them in /usr/lib32 -- this is a nasty > thing to do though as then no package is "managing" them.) > > I cannot test anything, as I have no access to a 64-bit machine. > > > If we cannot get 64-bit to work at all, perhaps we should remove ~amd64 from > the ebuild keywords. No, please don't do that, I can get 64bit to work at least with previous version of netscape-flash >
@kouyu: Thanks for the excellent sleuthing. I may indeed have to make flash depend on xulrunner-bin for many of those libs. As for libcurl, that's trickier. I have an outstanding bug 224747 which is asking for libcurl to go into emul-linux-x86-baselibs, but it's not there yet. Maybe depending on adobe reader is the answer until then, though I don't like it. And don't worry - When this actually goes in the tree it will indeed be ~amd64 and work (as well as it can) on 64b platforms.
Created an attachment (id=163565) [edit] netscape-flash-10_beta20080811.ebuild Okay, I've come to a decision. For libcurl.so.3 I will make both x86 and amd64 depend on app-text/acroread and install an env.d file as Nick suggested, since it also ensures the proper openssl libs are available. I will not patch the binary because I don't know enough about the law to know if I can. For amd64, I now depend on xulrunner-bin for the various libs we need from there. I haven't personally tested this ebuild on x86 yet, but it appears to work great for amd64. Please report here if x86 doesn't work for you! I'll be adding it to the tree very soon if I hear no bug reports here.
Okay, no complaints (plus I tested it on my own x86 system), so it's in the tree. Enjoy! I didn't add the magic config file... maybe in a later -r1.
(In reply to comment #33) > Created an attachment (id=163565) [edit] > netscape-flash-10_beta20080811.ebuild > > Okay, I've come to a decision. > > For libcurl.so.3 I will make both x86 and amd64 depend on app-text/acroread and > install an env.d file as Nick suggested, since it also ensures the proper > openssl libs are available. I will not patch the binary because I don't know > enough about the law to know if I can. > > For amd64, I now depend on xulrunner-bin for the various libs we need from > there. > > I haven't personally tested this ebuild on x86 yet, but it appears to work > great for amd64. Please report here if x86 doesn't work for you! I'll be > adding it to the tree very soon if I hear no bug reports here. > I think this ebuild needs to check for firefox use flag and depend on mozilla-firefox-bin instead of xulrunner-bin (or use xulrunner use flag and depend on xulrunner-bin). People on amd64, if they are installing netscape-flash as it exists today, most likely are using mozilla-firefox-bin as there browser. This saves on additional download and dep.
*** Bug 235532 has been marked as a duplicate of this bug. ***
Why amd64 users are most likely to use mozilla-firefox-bin instead of the mozilla-firefox ? Since nspluginwrapper is stable, there is no need to use mozilla-firefox-bin to get the support for 32bits plugins in firefox, and so there is absolutely no reason to use the binary version (excluding compilation time, which is short using most amd64 systems). For now, I masked flash 10 because I really don't want acroread on my system. The right solution imho is to get the 32bits emulation of the missings libraries, with an emul-linux-x86-* ebuild for example. Maybe opening a bug about that for the emulation team could be a idea ?
(In reply to comment #37) > Why amd64 users are most likely to use mozilla-firefox-bin instead of the > mozilla-firefox ? > Since nspluginwrapper is stable, there is no need to use mozilla-firefox-bin to > get the support for 32bits plugins in firefox, and so there is absolutely no > reason to use the binary version (excluding compilation time, which is short > using most amd64 systems). > > For now, I masked flash 10 because I really don't want acroread on my system. > The right solution imho is to get the 32bits emulation of the missings > libraries, with an emul-linux-x86-* ebuild for example. Maybe opening a bug > about that for the emulation team could be a idea ? > I was more looking for an option for people who have mozilla-firefox-bin installed. I am not going to get into how stable nspluginwrapper is and how much cpu it sucks etc. But the point is that some people do use the mozilla-firefo-bin version and asking them to install xulrunner-bin as well is wasteful.
Opera users also do not want to install xul-runner and adcroread.
I just created a directory called /opt/lib32-compat/ and it has: $ l /opt/lib32-compat/ total 660 drwxr-xr-x 2 root root 4096 Aug 22 19:28 ./ drwxr-xr-x 14 root root 4096 Aug 22 19:26 ../ lrwxrwxrwx 1 root root 16 Aug 22 19:24 libcurl.so -> libcurl.so.4.0.1* lrwxrwxrwx 1 root root 16 Aug 22 19:24 libcurl.so.3 -> libcurl.so.4.0.1* lrwxrwxrwx 1 root root 16 Aug 22 19:28 libcurl.so.4 -> libcurl.so.4.0.1* -rwxr-xr-x 1 root root 195232 Aug 22 19:23 libcurl.so.4.0.1* lrwxrwxrwx 1 root root 19 Aug 22 19:27 libgnutls.so -> libgnutls.so.26.1.2* lrwxrwxrwx 1 root root 19 Aug 22 19:27 libgnutls.so.26 -> libgnutls.so.26.1.2* -rwxr-xr-x 1 root root 405388 Feb 3 2008 libgnutls.so.26.1.2* lrwxrwxrwx 1 root root 18 Aug 22 19:27 libtasn1.so -> libtasn1.so.3.0.14* lrwxrwxrwx 1 root root 18 Aug 22 19:27 libtasn1.so.3 -> libtasn1.so.3.0.14* -rwxr-xr-x 1 root root 50700 Feb 3 2008 libtasn1.so.3.0.14* All copied from the 32-bit chroot I had created for livecd. I removed xul-runner and acroread from deps and emerged latest flash. Now, I just start firefox with LD_LIBRARY_PATH=/opt/lib32-compat firefox and the plugin works fine. Its hacky but working solution. Mind you this trick will work with mozilla-firefox-bin only (many libs like nss and nspr are picked from /opt/firefox) and you should have 32-bit emul libraries installed in /usr/lib32.
*** Bug 235578 has been marked as a duplicate of this bug. ***
*** Bug 235661 has been marked as a duplicate of this bug. ***
*** Bug 235691 has been marked as a duplicate of this bug. ***
Reopening - this bug needs more visibility because all kinds of people are at odds with its solution. :)
(In reply to comment #44) > Reopening - this bug needs more visibility because all kinds of people are at > odds with its solution. :) Yikes, no doubt! Okay, then here's what I'll do: - Make a custom tarball with libcurl.so.3 (and the openssl libs too) and throw it up on mirrors://gentoo - Remove the acroread dependency in favour of this new special 'flash-libcompat' tarball - I'll also fixup the amd64 deps so it will use ( xulrunner-bin || mozilla-firefox-bin ) In fact, I've just uploaded the custom tarball, so once that propagates to the mirrors I'll commit my new ebuild and make all the noise stop :)
Okay, I re-committed netscape-flash-10_beta20080811.ebuild as I outlined above. -> No more dependency on app-text/acroread, we now use my custom tarball with the binary x86 libraries. -> The amd64 version will now accept either xulrunner-bin or mozilla-firefox-bin, which right now is the easiest way to get some of the other magic 32-bit libs that flash needs. Enjoy, once it hits your rsync mirror. I'm intentionally leaving this bug open for the moment so it stays visible until most people have the new version.
(In reply to comment #46) > Okay, I re-committed netscape-flash-10_beta20080811.ebuild as I outlined above. > > -> No more dependency on app-text/acroread, we now use my custom tarball with > the binary x86 libraries. > > -> The amd64 version will now accept either xulrunner-bin or > mozilla-firefox-bin, which right now is the easiest way to get some of the > other magic 32-bit libs that flash needs. > > Enjoy, once it hits your rsync mirror. > > I'm intentionally leaving this bug open for the moment so it stays visible > until most people have the new version. > Will you remove dependancy on xul-runnerl? There are many people who use Opera and do not want to install firefox or xul-runner. I think that required libraries should be included in flash-libcompat as it's a place created for them.
I asked developers of flash if lastest beta depends on xul-runner or flash and their answer was "No".
(In reply to comment #48) > I asked developers of flash if lastest beta depends on xul-runner or flash and > their answer was "No". Of course not - It was just the easiest way to get libnss3.so and a bunch of other libs that aren't available in any other emul-linux-x86 package. I may add these libs to the libflash-compat library, but it may take me a couple days to find the time to do so. If someone else has the time to package these all up, I'd be happy to add your tarball to the tree.
(In reply to comment #49) > If someone else has the time to package these all up, I'd be happy to add your > tarball to the tree. Of course, as soon as I do this, the people who have netscape-flash-bin or xulrunner-bin installed will complain because now these libraries are duplicated on their system yet again :P
(In reply to comment #50) > (In reply to comment #49) > > If someone else has the time to package these all up, I'd be happy to add your > > tarball to the tree. > > Of course, as soon as I do this, the people who have netscape-flash-bin or > xulrunner-bin installed will complain because now these libraries are > duplicated on their system yet again :P > That's why we have conditionals. Can't we do this in the ebuild language: untar the specialized tar containing all libraries in work area if xul-runner-bin OR mozilla-firefox-bin is installed, remove the libraries (this set should be same for these two packages) that are provided by these. Its definitely more work, but is doable.
(In reply to comment #51) > (In reply to comment #50) > > (In reply to comment #49) > > > If someone else has the time to package these all up, I'd be happy to add your > > > tarball to the tree. > > > > Of course, as soon as I do this, the people who have netscape-flash-bin or > > xulrunner-bin installed will complain because now these libraries are > > duplicated on their system yet again :P > > > > That's why we have conditionals. Can't we do this in the ebuild language: > untar the specialized tar containing all libraries in work area > if xul-runner-bin OR mozilla-firefox-bin is installed, remove the libraries > (this set should be same for these two packages) that are provided by these. > > Its definitely more work, but is doable. It is indeed doable. Write me that ebuild and I'll consider throwing it in the tree.
how to use in amd64 profile? i have the variable but seems cannot read the lib... *** NSPlugin Viewer *** ERROR: libcurl.so.3: cannot open shared object file: No such file or directory if we have the compat, why we need xulrunner-bin?
i need to downgrade as i cannot use the provided libcurl.so.3 ....am i the only amd64 user to have this issue?
another question: can't we add the nss needed lib to the compat pack so we don't need xulrunner-bin on amd64?
(In reply to comment #53) > how to use in amd64 profile? i have the variable but seems cannot read the > lib... > > *** NSPlugin Viewer *** ERROR: libcurl.so.3: cannot open shared object file: > No such file or directory Sorry, I have not seen this issue - it seems to work just fine for me on amd64. Could you please attach the output of this command on your machine: ldd /opt/flash-libcompat/libcurl.so.3 > if we have the compat, why we need xulrunner-bin? As for why we have xulrunner-bin, it is a pre-existing package that contains a number of the libraries we need. Using this is much easier for me than maintaining yet more libraries in the 'compat' tarball, which obviously still has problems on some systems!
ldd /opt/flash-libcompat/libcurl.so.3 linux-gate.so.1 => (0xffffe000) libssl.so.0.9.7 => not found libcrypto.so.0.9.7 => not found libz.so.1 => /lib32/libz.so.1 (0xf7f09000) libdl.so.2 => /lib32/libdl.so.2 (0xf7f04000) libc.so.6 => /lib32/libc.so.6 (0xf7d9b000) /lib/ld-linux.so.2 (0xf7f98000) looks like the LDPATH didn't get included...did it? ldd /opt/flash-libcompat/libcurl.so.3 linux-gate.so.1 => (0xffffe000) libssl.so.0.9.7 => not found libcrypto.so.0.9.7 => not found libz.so.1 => /lib32/libz.so.1 (0xf7f09000) libdl.so.2 => /lib32/libdl.so.2 (0xf7f04000) libc.so.6 => /lib32/libc.so.6 (0xf7d9b000) /lib/ld-linux.so.2 (0xf7f98000) patrizio@blight ~ $ echo $LDPATH /usr/kde/3.5/lib:/usr/kde/3.5/lib64:/usr/kde/3.5/lib32: patrizio@blight ~ $ cd /opt/flash-libcompat/ patrizio@blight flash-libcompat $ ls libcrypto.so.0.9.7* libcurl.so.3* libssl.so.0.9.7* patrizio@blight flash-libcompat $ ls -l totale 1369 -rwxr-xr-x 1 root root 1004584 1 set 22:02 libcrypto.so.0.9.7* -rwxr-xr-x 1 root root 206540 1 set 22:02 libcurl.so.3* -rwxr-xr-x 1 root root 184168 1 set 22:02 libssl.so.0.9.7* patrizio@blight flash-libcompat $ export LDPATH=$LDPATH:/opt/flash-libcompat/ patrizio@blight flash-libcompat $ echo $LDPATH /usr/kde/3.5/lib:/usr/kde/3.5/lib64:/usr/kde/3.5/lib32::/opt/flash-libcompat/ patrizio@blight flash-libcompat $ ldd /opt/flash-libcompat/libcurl.so.3 linux-gate.so.1 => (0xffffe000) libssl.so.0.9.7 => not found libcrypto.so.0.9.7 => not found libz.so.1 => /lib32/libz.so.1 (0xf7f2e000) libdl.so.2 => /lib32/libdl.so.2 (0xf7f29000) libc.so.6 => /lib32/libc.so.6 (0xf7dc0000) /lib/ld-linux.so.2 (0xf7fbd000) even later...after the export... for the xulrunner...i think only nss lib is needed...not that big ihmo...
(In reply to comment #57) > ldd /opt/flash-libcompat/libcurl.so.3 > linux-gate.so.1 => (0xffffe000) > libssl.so.0.9.7 => not found > libcrypto.so.0.9.7 => not found > libz.so.1 => /lib32/libz.so.1 (0xf7f09000) > libdl.so.2 => /lib32/libdl.so.2 (0xf7f04000) > libc.so.6 => /lib32/libc.so.6 (0xf7d9b000) > /lib/ld-linux.so.2 (0xf7f98000) > > looks like the LDPATH didn't get included...did it? This isn't done via LDPATH, it should be set in /etc/env.d/99flash-libcompat, and that should cause the proper path to appear in /etc/ld.so.conf when the ebuild runs 'env-update'. Try manually running 'env-update' as root, check the contents of /etc/ld.so.conf, and then try running the 'ldd' line again, thanks! If it still shows those 2 libs as "not found", please paste the contents of /etc/env.d/99flash-libcompat and /etc/ld.so.conf here. > for the xulrunner...i think only nss lib is needed...not that big ihmo... No, the following libraries are all used from xulrunner-bin (at least on my system): libssl3.so => /opt/xulrunner/libssl3.so (0xf6c67000) libnss3.so => /opt/xulrunner/libnss3.so (0xf6bf4000) libnspr4.so => /opt/xulrunner/libnspr4.so (0xf6bc1000) libplc4.so => /opt/xulrunner/libplc4.so (0xf67de000) libplds4.so => /opt/xulrunner/libplds4.so (0xf67d9000) libsoftokn3.so => /opt/xulrunner/libsoftokn3.so (0xf678b000) Plus if those depend on any other libs, those will be taken care of too for free. I just don't have time to pare this down to the lowest subset of libraries. Perhaps if this dependency set stays the same for the next couple beta releases from Adobe I'll consider condensing it - And definitely if the actual flash-10 release has the same concerns. - But until then it's too much work for the small size benefit in my opinion, sorry. Plus as your case demonstrates, *something* is wrong with the way I'm doing the existing libcompat anyway - removing xulrunner-bin would just make it more wrong :)
greate it works....ldconfig was broken....
Good news everyone! The next RC has been released, and it still needs all the libs I'm currently using from xulrunner-bin, so I've decided to put these in the new 'flash-libcompat' package. When you upgrade to the latest RC you can uninstall xulrunner-bin (if this was the only package depending on it, of course :)
