HOW-TO get Flash7 working!

[Alexander Leidinger]

Quoting Chuck Robey <chuckr at 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.

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  
done correctly.

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.

Bye,
Alexander.

-- 
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