Linux executable picks up FreeBSD library over linux one and
breaks
Alexander Leidinger
Alexander at Leidinger.net
Thu Dec 13 01:08:36 PST 2007
Quoting Chuck Robey <chuckr at chuckr.org> (from Wed, 12 Dec 2007
22:33:18 -0500):
> Alexander Leidinger wrote:
>> Quoting Chuck Robey <chuckr at chuckr.org> (from Mon, 03 Dec 2007
>> 13:30:50 -0500):
>>
>>> Alexander Leidinger wrote:
>>>> Quoting Chuck Robey <chuckr at chuckr.org> (from Sun, 02 Dec 2007
>>>> 13:23:33 -0500):
>>>>
>>>>> You've gotten some good suggestions, but I might add one more, I don't
>>>>> think it's been mentioned. I have foound, myself in the last 2 weeks,
>>>>> some FreeBSD ports putting in Linux tools, installing stuff in the
>>>>> wrong places, like sticking in SYSV libraries in /usr/local/lib instead
>>>>> of /compat/linux/usr/lib. I verified in that case that the Linux
>>>>
>>>> If they put the libs directly in /usr/local/lib instead of
>>>> /usr/local/lib/<linux_port_specific_directory>, then it is a big
>>>> error. But if it is in a subdirectory where no FreeBSD lib
>>>> resides, it is ok (the linux browser sets LD_LIBRARY_PATH in the
>>>> start script to the right path).
>>>>
>>>> Have a look how the native browser works, the private libs are
>>>> not in ldconfig either and the browser start script sets the
>>>> library path for the browser binary. At least it did this the
>>>> last time I checked...
>>>>
>>>
>>> Does that mean that all programs needing those libs must have wrapper
>>> shells, so as ot implement the LD_LIBRARY_PATH? I know of programs
>>
>> Yes. For the mozilla stuff it seems to be a design decision of them
>> to put the libs in a non-standard path (this is independent from
>> the OS). Don't shoot FreeBSD, shoot them if you don't like this.
>>
>>> that bomb if that's even set at all, and I think it can be a security
>>> tool, and I just think that there is no good reason for installing
>>> Linux libs outside of the compat tree. There isn't any good reason not
>>
>> You have 2 differet issue here. One issue is that some
>> program(-suites) decide to put their libs into a non-standard
>> directory. The other one is that you should not mix libs from linux
>> and FreeBSD.
>>
>>> to use the compat tree, is there? You know, there's a local there too,
>>> so you don't even need to be ignoring LOCALBASE, which is something I
>>> don't care for ports to do at all.
>>
>> Even if you have them in LINUXBASE, you could pick up the wrong libs
>> depending on the search order of the libs directories and the location
>> of the libs.
>>
>> The big goal is, that an user should not have the need to put
>> /compat/linux/... into his path to start a linux program. We can do this
>> by putting those linux programs into LOCALBASE (easy, if they don't
>> install libs or hide the libs in special dirs), or by putting them into
>> LINUXBASE and add a wrapper script to LOCALBASE (not as easy, as you
>> have to have more knowledge about pkg-plist in the ports to get the port
>> to do the right thing).
>
>
> You have jumped over the issue I wanted to address, at least, it looks
> like that to me. It seems like you are telling me why Linux libs need
> to be in different dirs, but I did say I understood that. You really
> do need to have them in different directories, so that the two
> different file types can more easily be administered both by users and
> by ldconfig. I am not arguing that, not for an instant, so please read
> this following text.
>
> I am complaining about mixing FreeBSD and non-FreeBSD libs, both of
> them in the /usr/local tree. I know that it can do this, but I am
> saying that this is an unnecessary complication, and that all Linux
> binaries and libraries, etc. should actually go into the /compat/linux
> tree instead. As far as possible, our ports tree should not contribute
For pure infrastructure ports (like linux-png, linux-gtk, ...) this is
already the case. It is "just" the ports which come with end-user
applications (or the other way around, ports of end-user applications
which come with libs) for which I haven't enforced such a rule.
> to the confusion. There are a large host of reasons why this is so,
> even some beyond the obvious 2, of needing to help users keep the
> separation, and to make keeping the ldconfig stuff separate. There is
> also an ugly trend in most linuxes to install everything into /usr, and
> not to have any /usr/local at all. This is very easily accomodated
> with /compat/linux, but it's a major PITA if Linux stuff must go into
> /usr/local. Trying to get the Linux software to give up this silly
> bias isn't even an issue, if it was installed into /compat/linux.
>
> I really like the ability to have different apps, ones that really do
> fall in different categories, to install in different areas. Among
> other things, this allows one to very easily do a chroot in
> /compat/linux. I have tried it, it really works fine, and lets you
A chroot into /compat/linux is not supported anymore. We have
fall-through cases from /compat/linux/XXX to /XXX where it makes sense
(e.g., some config files).
This is to make the user experience more pleasant (the linux part
behaves the same as the corresponding FreeBSD part, as the config is
the same file in the end). If you want to chroot into a linux
environment, you should use one of the linux_dist ports (can be
installed additionally, as it installs into a different location).
> have a really good level of Linux compatibility. We lose that totally
> if the Linux and FreeBSD stuff is mixed with a different subdir for
> eacy lousy app.
>
> Let me illustrate this further. A whole lot of apps take this tack:
> they create their own little subdir in /usr/local/lib, so that they can
> add even more rotten little paths both to the Linux executable path and
> the Ldconfig path. This sort of behavior is really crazy to do, but
> that's what all those ports authors do, those who must install their
> libraries, (their SYSV libs, understand) to /usr/local.
>
> Above and beyond this, all the applications, (and not just browsers,
> every single Linux app that uses stuff with libs installed into
> /usr/local) needs to have sh shims to kick them off, so that the
> location of the libraries, in their odd spots, can be crafted to work.
> All those little sh shims, all because some ports authors can't use
> /compat/linux. Isn't it obvious that this is poor behavior?
It is not as poor as the alternative (at least the alternative I know
about, feel free to come up with a better idea how to handle the
following).
My goal is that it is easy to start a linux program. If I install
e.g., acroread, I just want to type "acroread pdffile" withhout the
need to do something else. I don't need to specify the path to it
(/compat/linux/.../acroread), and I don't want to add
/compat/linux/XXX to my PATH. The last part is very important, as it
prevents a lot of foot shooting for endusers. A lot of people can use
e.g., acroread, they don't need to be smart to do this, and they don't
need to know a lot about unix to do it. But if those people add
/compat/linux/... to their path, hell can (and most probably will)
break lose. The users get a mixed environment and a lot of strange
situations will occur depending on where in their PATH they have the
linux paths. Those users will not say that they where too stupid /
without enough knowledge to use it, they will say FreeBSD is not
userfriendly.
To achieve this goal we have 2 possibilities, either we install
everything into LINUXBASE and install a wrapper in LOCALBASE, or we
install everything in a safe location in LOCALBASE. The first part
requires that the maintainers of the linux program play some tricks in
their port (plist and/or Makfile). If they fail to do this, it
increases the load of portmgr from time to time (build failures on the
build cluster). In the second case (install into a safe place in
LOCALBASE), portmgr is out of the loop, as if something goes wrong,
the port maintainer and/or emulation@ is asked for help, as it is a
bug of the port.
When I look at the quality of some linux ports (not maintained by
emulation@ and before I send improvement suggestions to the
maintainer), I think it is better to do it the way we do it currently
(installing into a safe place in LOCALBASE). This way it is easier to
create a linux port (it is already hard enough for some people to get
right as it is).
The current way is a compromise between ease of use for users /
creation of ports, and the perfect but harder solution. It's based
upon experience with updating the infrastructure ports owned by
emulation@ and helping users with problems (and having my own problems
with the linuxulator myself).
> I really wish that ports management would go on the record and make a
> definite ruling, that all linux images should install to the
> /compat/linux tree. If this would be the case, then nI would myself go
In case portmgr does something like this, the rule should include,
that end-user applications should contain a wrapper script in
LOCALBASE, which allows to start the ported application without the
need to add LINUXBASE/... to the PATH to prevent hell on earth (I
would say that it is forbidden to tell users in a port to add
LINUXBASE to the PATH, but I hope this is not necessary). Note: I
still prefer the current way of handling this. Feel free to improve
your proposal to keep the same ease of use/porting while getting the
benefit of the separation. I'm open for improvement suggestions.
> about fixing the horde of software that violates this. I said horde,
> and I sure meant it.
I don't object that you say "horde". I know about it, I touched 99% of
them at least once. :)
Bye,
Alexander.
--
In Hollywood, all marriages are happy. It's trying to live together
afterwards that causes the problems.
-- Shelley Winters
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
More information about the freebsd-hackers
mailing list