Date: Mon, 14 Jan 2008 14:19:19 -0500 From: Chuck Robey <chuckr@chuckr.org> To: eculp <eculp@encontacto.net> Cc: freebsd-ports@freebsd.org Subject: Re: Another question based on: Re: HOW-TO get Flash7 working! Message-ID: <478BB5B7.40102@chuckr.org> In-Reply-To: <20080113082515.19316v8x3pbs3tcs@intranet.encontacto.net> References: <64c038660801040516u5c42a6cpadb475ad67fb4730@mail.gmail.com> <20080104174955.52aa33fd@gumby.homeunix.com> <64c038660801041029t1a9662bayed3ca02fd46c7ece@mail.gmail.com> <64c038660801041226k1d350bc6p727e4666ea295727@mail.gmail.com> <477FFE14.1010704@monkeybrains.net> <477FFF63.50004@gmail.com> <47801D54.8050709@gmail.com> <47803E3F.2080005@monkeybrains.net> <47804901.6090007@gmail.com> <4786BF45.8030602@monkeybrains.net> <4786CEDC.3050009@chuckr.org> <20080111170711.t6wxj1bc68cgwwk4@webmail.leidinger.net> <4787E597.9040902@chuckr.org> <20080112213747.443a4833@deskjail> <20080113082515.19316v8x3pbs3tcs@intranet.encontacto.net>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 eculp wrote: > The dialog at the end of this email is becoming a bit more philosophical > than I need right now ;). > > Is there an "accepted" or reasonably so, sure-fire way to get linux > flash[79] working in Prerelease or in current? If so, would you please > share how you did it on this list? Getting my method "accepted" so that I could modify the ports in question, is the reason for all this folderol. The method I detail below is what I followed, and it's complicated enough that NO WAY would I ever suggest anyone follow it, but I haven't been able to provoke anyone in authority to either agree or disagree (officially) with me, either to get me rolling, or to stop a major bore from putting everyone to sleep. I don['t enjoy all this arguing. > > Flash is becoming more dominate daily and there are many sites that are > basically unusable without it. Some banking, telco, etc. sites, etc. > That are difficult if not impossible too use for account access without > flash and don't pay much attention to end user requests based on the > installed base of Flash[89]. That brings up another detail, many sites > now require Flash[89] even though they don't actually need it probably > to impress their customers with their being on the technological, > bleeding edge. > > Thanks, Chuck, for getting this started and for finding a solution that > may or may not be appropriate for all. I would personally like to try > what you have done with flash9 if it is stable for you and if you would > be so kind as to document a bit clearer how to do it. > Well, I couldn't get any responses from my mail to the ports leaders, so I didn't even try to make a port of it. I looked over to my Gentoo Linux box, sand saw that my firefox there (which does flash just fine) had the libflashplayer.so in /usr/lib/firefox/plugins, so I copied that file tp my /usr/compat/usr/lib/linux-firefox/plugins. I did an ldd on that file, and found all files excepting one existed on my system, so one by one I moved them to /usr/compat/linux/usr/lib (checking each time, with the llinux ldd, that the loader was finding the file being used). I *think* that there was one that I coudlnt find (I'm not really sire at this point), but I think it was liobdl.so.2, so I copied that one from my Gentoo box also, and also the requisite softlink to libdl.so (remember that all linux libs need their symlinks to the library file without the version number). I need to admit that there were a couple of startup errors I got from the linux-firefox, ones that told me it couldn't find a aprticular library, but when I located the library that it couldn't find, and moved it to the compat tree, the error evaporated. Once I got finished with all this dance, flash9 worked fine using linux-firefox. > Thanks to all, > > ed > > Quoting Alexander Leidinger <Alexander@Leidinger.net>: > >> Quoting Chuck Robey <chuckr@chuckr.org> (Fri, 11 Jan 2008 16:54:31 >> -0500): >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Alexander Leidinger wrote: >>> > Quoting Chuck Robey <chuckr@chuckr.org> (from Thu, 10 Jan 2008 >>> 21:05:16 >>> > -0500): >>> > >>> >> I actually got the linux flash9 working. Why didn't I post it, >>> put in a >>> >> patch? Because one of the main reasons that it doesn't work now >>> is the >>> >> insane way that much Linux libraries are installed. If folks >>> would honor >>> > >>> > Would you mind telling us how, so that we understand the problem? >>> > >>> >> hier(7) then all linux libs would go into /usr/compat/usr/lib, but >>> >> instead, many linux ports (including browsers, believe me) install >>> into >>> >> $(PREFIX)/lib/libsubdir. This means every single linux app that uses >>> >> linux >>> >> libs hsa to be run with a shell wrapper, artificially extending the >>> >> LD_LIBRARY_PATH. Since no porter of an app installing libs knows >>> all the >>> >> ports that might use their libs, random breakages are the rule of the >>> >> day, >>> >> to say nothing of the egregious harm to security this kind of >>> strategy >>> >> causes. It's a big reason why the flash things don't work. Want >>> proof? >>> >> Go use the linux ldd to see just how long the list of libraries >>> is, that >>> >> those extensions use, then you'll begin to see. Not all those >>> libs are >>> >> browser products, either. Have fun trying to get a wrapper to work >>> >> there. >>> >> >>> >> I volunteered to fix this situation all myself, if only the ports >>> >> management would give me written agreement that the strategy I decry >>> >> is in >>> >> fact bad software practice, so that I may point to that document >>> to port >>> >> authors, when I ask for permission to edit their work. Ports >>> management >>> >> hasn't seen fit to reply, or at least, I haven't seen it if they >>> did. I >>> >> don't intend to force anyone, but without having ports mangement >>> >> backing, I >>> >> am NOT going to have this argument with every porter, no way. I >>> tried >>> >> that >>> >> once, and at least one fellow told me he thought that requiring every >>> >> linux >>> >> application to have it's own wrapper was the "cleaner" way to go. >>> >> Huh, if >>> >> that's so, then I guess I should be stopped anyhow. You think >>> that way? >>> > >>> > I think you are referring to me here. I think the important part to >>> > understand my opinion to install end-user applications into PREFIX >>> > instead of LINUXPREFIX (note: linux library ports _have_ to go to >>> > LINUXBASE) is missing here. >>> >>> In fact, I have never been at all good at remembering names, to the >>> point >>> that I no longer even try. I haven't the faintest idea (even now) if it >>> was you or not. If it pleases you, though, that's fine, assume away. I >>> don't think I was insulting, I have made enough of an ass of myself >>> in the >>> past to realize the folly of being sarcastic (it always comes back to >>> bite >>> you). >> >> I didn't understand it as insulting. >> >>> > No user shall have subdirs of LINUXPREFIX in his path. This would open >>> > up Pandorra's box. >>> >>> OK, need to stop you here. I don't know what that LINUXPREFIX item >>> is. I >> >> It was either my mispelling of LINUXBASE, or my failed try to make a >> distinction between the user chosen prefix for two different >> "management domains". Chose the error you like more. ;-) >> >>> just grepped for it in /usr/ports subdirs Mk, emulators, and www >>> (recursive >>> one), and even did an apropos. I did a bit of googling and found a >>> LINUXPREFIX in some Linux docs, is that the one you're referring to? >>> What's it mean, how's it used? >>> >>> Regardless, please, could you explain why it would open up Pandora's >>> Box? >>> Maybe if I could have a better handle on what it is, I might not ask >>> that >>> question, but I can't, so I'm asking. >> >> If an user has the bin directories in the LINUXBASE in his path >> - he may accidentally execute linux programs when FreeBSD programs >> may be required >> - a configure run may detect linux things and enable stuff which >> is not valid for FreeBSD >> - ... (I don't remember everything by heart, and I'm too lazy >> currently to try to reverse engineer all of them in my brain, >> but you get the big picture of the bad stuff which can happen) >> >> All of this may be confusing, specially for newbies. And if we require >> that users add some LINUXBASE directories to their PATH (which means >> manual activity to be able to run a program, where the current approach >> doesn't need this and has not the above drawbacks) by default, even >> newbies do that, and they will not be able to handle this situation and >> will throw FreeBSD away. >> >>> One item that some might not know: most unixes have a strong bias >>> towards >>> installing everything into /usr/bin or /usr/lib. Many Linux boxes don't >>> even have a /usr/local, or opt, or whatever. Much Linux software >>> makes the >>> assumption that it's using a prefix of /usr. I hate this myself, I MUCH >>> more like FreeBSD's way of doing things, but I can have my cake and >>> eat it >>> too, if Linux software is installed into /compat/linux/usr/bin (and lib, >>> etc), I get the separation as far as FreeBSD is concerned, but Linux >>> software is fooled into obeying their abhorrent lack of separation. >>> Real nice. >>> >>> [Man, your mail is huge, I would have preferred to make it decide >>> things in >>> smaller bits, but I guess not.] Continuing ... >>> >>> > >>> > A clean way to achieve this is to have something in prefix which calls >>> > the linux program. This can be a symlink or a wrapper in PREFIX. If >>> you >>> > install parts of a port into LINUXPREFIX and a link/wrapper in PREFIX >>> > (or more generic: if you have 2 different prefixes in a port), you >>> have >>> > to do some ports-magic. If you install the port in a sub-directory in >>> > PREFIX and add a wrapper in the PREFIX/bin, you don't have to do >>> > ports-magic. >>> >>> OK. Ab initio, I have always felt that using wrappers was a tacky >>> way to >>> do things. Not that it wasn't sometimes the only available way to >>> go, but >> >> It would be nice to do it without the wrapper, but as I already said, >> the current situation looks to me as the most pragmatic one. And as the >> linuxulator in the kernel is a wrapper of some kind itself, I prefer to >> not say bad things about wrappers... ;) >> >>> certainly to be avoided. I also have always felt that screwing with >>> LD_LIBRARY_PATH, as your wrappers would need to do, is a security >>> problem, >> >> I fail to see how it is a security problem, when the wrapper sets >> LD_LIBRARY_PATH. You can set it yourself and give the application some >> "wrong" stuff, but if we assume the wrapper in the port is not a trojan >> horse but sets the LD_LIBRARY_PATH correctly, then it should be fine. >> Depending on the concrete situation I may agree upon the security >> problem point of view, but for this I need to know the concrete >> situation. >> >>> which again might sometimes be the best way to go, but not ever the >>> first >>> choice. This is only part of my argument, though (I would be >>> embarrassed >>> if my argument was only based upon my prejudices). >>> >>> The larger real problem is, some ports install libs, and do not know >>> what >>> possible executables might need to have their wrappers adjusted. Also, >>> some items are difficult to use any wrappers on at all. As an >>> example, the >>> flash9 plugin needed a linux lib, libdl.so (I think it was .so.2). If I >>> wanted to be complete, it really needed about twenty different >>> libraries, >>> but libdl.so will serve as an example well enough). It had been >>> installed >>> in some subdir of /usr/local/lib. I couldn't get a wrapper to work in >> >> As Boris already commented, it seems some other port is interfering >> here, or something is broken on your end. Please use pkg_which to >> investigate which port installed it there, so that we can have a look >> at this port. >> >>> that case, and I wasn't going to bork up my linux LD_LIBRARY_PATH with >>> about half a dozen locations (which do change occaisonally). Trying >>> to do >>> all the work of maintaining that wrapper would have made the task nearly >>> impossible, so I decided to just copy libs to >>> /usr/compat/usr/linux/usr/lib, and it was immediately recognized. I >>> went >>> about doing an linux ldd on the plugin, then moving libs and making sure >>> with the linux ldd that the plugin was happy once I'd moved the libs. >>> There were one or two that needed to be in a subdir of the browser dir >>> itself, but mostly, putting it in the compat path worked, and once I was >>> finished, flash9 just worked ok. >> >> It needs careful investigation which ports install those libs there and >> why. Maybe something is wrong, maybe not. It would help if you list the >> libs which you think are installed incorrectly together with the ports >> which installed them. We can have a look at them then and decide how >> the situation can be improved. >> >>> Making a wrapper for the flash9, even if you could coax the browser to >>> accept the plugin with a wrapper around it, would not be much of a fun >>> task, and the people who put the libs in place, they don't have to help >>> you, because you have told them they can put their libs any darn >>> place they >>> please. >> >> While it is possible to make a wrapper around dynamic libs (with the >> help of /etc/libmap.conf), a solution without it is preferred. >> >>> Another really nice fallout from putting things into the compat >>> structure >>> is that chroots now work very nicely to make you an extremely compatible >>> linux arch. Can't do that with having everything installed all over. >> >> Sorry to disappoint you, but the linux_base ports are not designed for >> this. We rely on some fallthrough to the FreeBSD root directory for >> some config files which we have at the same location than linux and are >> syntactically compatible. >> >> If you want a linux base system to chroot into, you should install one >> of the linux_dist ports. >> >>> If you could please, in answering this email, explain your "Pandora's >>> Box" >>> comment, and also explain why installing hard to maintain wrappers is >>> better than the way that Linux itself does it, I'd appreciate that. I >> >> Linux can do it without wrappers, as it hasn't to emulate a foreign >> API. As we have to do this, we sometimes have to use wrappers. >> >>> can't see why, and tossing it off with a tagline like "opening Pandora's >>> Box" is cheating, although I can see, can understand why you did it, >>> explaining this long argument is tedious, I grant you that. Still, you >>> opened the box ... >> >> If you have some more questions, just ask. >> >> Bye, >> Alexander. >> >> -- >> Professor: Some say I'm robbing the cradle but I say she's robbing >> the grave. >> http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 >> http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 >> _______________________________________________ >> freebsd-ports@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ports >> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" >> > > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHi7W3z62J6PPcoOkRAuPzAJ0W8pGNo4MZ6Lb9eAhXIQCEYrjoBwCcCzxt 76lnI9pVwdalt9c7S2Cl33w= =YN6G -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?478BB5B7.40102>