Linux executable picks up FreeBSD library over linux one and breaks

[Chuck Robey]

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 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 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?


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 
about fixing the horde of software that violates this.  I said horde, 
and I sure meant it.