HOW-TO get Flash7 working!
chuckr at chuckr.org
Fri Jan 11 13:58:16 PST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Alexander Leidinger wrote:
> Quoting Chuck Robey <chuckr at chuckr.org> (from Thu, 10 Jan 2008 21:05:16
>> 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
>> 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
>> 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
>> 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
>> once, and at least one fellow told me he thought that requiring every
>> 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
> 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
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.
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
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
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,
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
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.
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
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.
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
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 ...
> 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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the freebsd-ports