HOW-TO get Flash7 working!

Chuck Robey chuckr at
Tue Jan 15 13:10:50 PST 2008

Hash: SHA1

Boris Samorodov wrote:

> OK, let's leave libdl an all concerned with it in the past. And
> let's concentrate at port errors (ports with errors?).
>> I haven't sent any of this to emulation.  I dislike crossposting without
>> some truly major reason, and this thread did begin in ports.  I wonder,
>> does the fact that your own port installs into /compat mean that you,
>> yourself, agree with my thesis, that all Linux items belong inmstalled into
>> the /compat/linux tree?
> Actually, no. ;-) That means that those ports are linux infrastructure
> ports which (so far noboby doubts it) belong to /compat/linux.

I think I would not class it as that way ... if I had to limit it, I would
make it catch all ports that install libraries.  This means both what you
class as "linux infrastructure" and also most things like browsers, that
install rafts of libraries.  It's mailing the manipulation of the
LD_LIBRARY_PATH that I'm trying to avoid.  I dislike having to fiddle with
that on _all_ linux executables, which is required if ports can't be relied
upon to put the ports in locations that linux applications expect them to
be, where they are in my own Gentoo Linux box by default.  Not that
everything there goes into (/compat/linux)/lib or /usr/lib, but always at
least some subdirectory of those, at least.

>> What is your own opinion of this?
> You know, when something goes wrong with a port and I can't repair it
> myself, I do to a dortor^w kernel committer for help. If he says
> "don't do it, it hurts" I do just what he says. Said that I should add
> that I do it not blindly but because I see that it really (most of the
> cases) helps. Yet there are open PRs which still are not closed,
> workaround not found, etc.
> Nobody says that current linuxulator is ideal. I'd say that current
> situation just hurts less. It is (unfortunately) very sensitive
> instrument. :-( (I don't want to end the letter in a sad end, and
> here is an old Russian phrase which may remind current situation:
> "One wrong movement, and you are a father...")

I haven't got any bone at all with our linuxulator, and I don't see
anything in that which is motivating, in any way, to require libs of linux
applications to go into /usr/local hierarchy instead of /compat hierarchy.
  I like the way our linuxulator works, please don't paint me as having any
argument with it.

Before I make the next point, realize that all Linux distributions I have
seen put all their items into the usr tree, and not the /usr/local tree.  I
don't particularly like it (I rather like the way FreeBSD does it with
/usr/local) but what Linux apps do is an established fact, not really open
to argument.

Anyway, if your infrastructure ports put items into /compat, as I want, why
do you want to break with the Linux standard, and put the Linux
non-infrastructure items in the /usr/local tree?  Note, this is against
what our own hier(7) says to do.

Note again that I am really, truly, only wanting this for all libraries, it
just seems more reasonable to me, if it's done for all infrastructure and
all libraries, to extend it to ALL Linux items.  A point I made before, but
got lost, is that it nicely allows one to use chroot also, to make the
environment iven more linux-like.  I tried it, it worked nicely for the
items that were in that tree.  Doesn't work for items in /usr/local.


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


More information about the freebsd-ports mailing list