Another question based on: Re: HOW-TO get Flash7 working!

Chuck Robey chuckr at
Mon Jan 14 11:22:49 PST 2008

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 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, so I copied that one from my Gentoo box also, and also the
requisite softlink to (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 at>:
>> Quoting Chuck Robey <chuckr at> (Fri, 11 Jan 2008 16:54:31
>> -0500):
>>> Hash: SHA1
>>> Alexander Leidinger wrote:
>>> > Quoting Chuck Robey <chuckr at> (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, (I think it was .so.2).  If I
>>> wanted to be complete, it really needed about twenty different
>>> libraries,
>>> but 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.
>>  Alexander @ PGP ID = B0063FE7
>>     netchild @  : PGP ID = 72077137
>> _______________________________________________
>> freebsd-ports at mailing list
>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at"
> _______________________________________________
> freebsd-ports at mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at"

Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla -


More information about the freebsd-ports mailing list