HOW-TO get Flash7 working!
Alexander at Leidinger.net
Fri Jan 11 08:07:29 PST 2008
Quoting Chuck Robey <chuckr at chuckr.org> (from Thu, 10 Jan 2008
> 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.
No user shall have subdirs of LINUXPREFIX in his path. This would open
up Pandorra's box.
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.
Writting a wrapper is easy, porting linux programs is already hard,
and the ports-magic is something which can result in tears when not
Also don't underestimate the pitfalls with accessing linux libs in the
linuxulator when they are in LINUXPREFIX. The best solution would be
to rewrite the linux run time linker and get rid of the linux default
one, but this is not really a pragmatic solution, we will get hit by
problems as soon as something important changes in the linux run time
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
the ideal way, it is a pragmatic way. It's weighting the good and the
bad things of the different ways to get it working, and trying to do
it in a way which is beneficial to most people.
Absence makes the heart grow fonder.
-- Sextus Aurelius
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
More information about the freebsd-ports