Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Jan 2008 17:07:11 +0100
From:      Alexander Leidinger <Alexander@Leidinger.net>
To:        Chuck Robey <chuckr@chuckr.org>
Cc:        freebsd-ports@freebsd.org, Rudy <crapsh@monkeybrains.net>
Subject:   Re: HOW-TO get Flash7 working!
Message-ID:  <20080111170711.t6wxj1bc68cgwwk4@webmail.leidinger.net>
In-Reply-To: <4786CEDC.3050009@chuckr.org>
References:  <64c038660801040516u5c42a6cpadb475ad67fb4730@mail.gmail.com> <20080104174955.52aa33fd@gumby.homeunix.com> <64c038660801041029t1a9662bayed3ca02fd46c7ece@mail.gmail.com> <64c038660801041226k1d350bc6p727e4666ea295727@mail.gmail.com> <477FFE14.1010704@monkeybrains.net> <477FFF63.50004@gmail.com> <47801D54.8050709@gmail.com> <47803E3F.2080005@monkeybrains.net> <47804901.6090007@gmail.com> <4786BF45.8030602@monkeybrains.net> <4786CEDC.3050009@chuckr.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Chuck Robey <chuckr@chuckr.org> (from Thu, 10 Jan 2008 =20
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 linu=
x
> 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 tha=
t
> once, and at least one fellow told me he thought that requiring every linu=
x
> 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 =20
understand my opinion to install end-user applications into PREFIX =20
instead of LINUXPREFIX (note: linux library ports _have_ to go to =20
LINUXBASE) is missing here.

No user shall have subdirs of LINUXPREFIX in his path. This would open =20
up Pandorra's box.

A clean way to achieve this is to have something in prefix which calls =20
the linux program. This can be a symlink or a wrapper in PREFIX. If =20
you install parts of a port into LINUXPREFIX and a link/wrapper in =20
PREFIX (or more generic: if you have 2 different prefixes in a port), =20
you have to do some ports-magic. If you install the port in a =20
sub-directory in PREFIX and add a wrapper in the PREFIX/bin, you don't =20
have to do ports-magic.

Writting a wrapper is easy, porting linux programs is already hard, =20
and the ports-magic is something which can result in tears when not =20
done correctly.

Also don't underestimate the pitfalls with accessing linux libs in the =20
linuxulator when they are in LINUXPREFIX. The best solution would be =20
to rewrite the linux run time linker and get rid of the linux default =20
one, but this is not really a pragmatic solution, we will get hit by =20
problems as soon as something important changes in the linux run time =20
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 =20
the ideal way, it is a pragmatic way. It's weighting the good and the =20
bad things of the different ways to get it working, and trying to do =20
it in a way which is beneficial to most people.

Bye,
Alexander.

--=20
Absence makes the heart grow fonder.
=09=09-- Sextus Aurelius

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID =3D B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID =3D 72077137



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080111170711.t6wxj1bc68cgwwk4>