Date: Fri, 11 Jan 2008 17:07:11 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Chuck Robey <chuckr@chuckr.org> Cc: freebsd-ports@freebsd.org, Rudy <crapsh@monkeybrains.net> Subject: Re: HOW-TO get Flash7 working! Message-ID: <20080111170711.t6wxj1bc68cgwwk4@webmail.leidinger.net> In-Reply-To: <4786CEDC.3050009@chuckr.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Chuck Robey <chuckr@chuckr.org> (from Thu, 10 Jan 2008 =20 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 linu= x > 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 tha= t > once, and at least one fellow told me he thought that requiring every linu= x > 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 =20 understand my opinion to install end-user applications into PREFIX =20 instead of LINUXPREFIX (note: linux library ports _have_ to go to =20 LINUXBASE) is missing here. No user shall have subdirs of LINUXPREFIX in his path. This would open =20 up Pandorra's box. A clean way to achieve this is to have something in prefix which calls =20 the linux program. This can be a symlink or a wrapper in PREFIX. If =20 you install parts of a port into LINUXPREFIX and a link/wrapper in =20 PREFIX (or more generic: if you have 2 different prefixes in a port), =20 you have to do some ports-magic. If you install the port in a =20 sub-directory in PREFIX and add a wrapper in the PREFIX/bin, you don't =20 have to do ports-magic. Writting a wrapper is easy, porting linux programs is already hard, =20 and the ports-magic is something which can result in tears when not =20 done correctly. Also don't underestimate the pitfalls with accessing linux libs in the =20 linuxulator when they are in LINUXPREFIX. The best solution would be =20 to rewrite the linux run time linker and get rid of the linux default =20 one, but this is not really a pragmatic solution, we will get hit by =20 problems as soon as something important changes in the linux run time =20 linker, and we don't have the man-power to permanently keep up. The current way of handling the linuxulator things in the ports is not =20 the ideal way, it is a pragmatic way. It's weighting the good and the =20 bad things of the different ways to get it working, and trying to do =20 it in a way which is beneficial to most people. Bye, Alexander. --=20 Absence makes the heart grow fonder. =09=09-- Sextus Aurelius http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080111170711.t6wxj1bc68cgwwk4>