Date: Wed, 05 Dec 2007 12:21:23 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Chuck Robey <chuckr@chuckr.org> Cc: Yuri <yuri@rawbw.com>, freebsd-hackers@freebsd.org Subject: Re: Linux executable picks up FreeBSD library over linux one and breaks Message-ID: <20071205122123.phwu6uh7jksgcwk8@webmail.leidinger.net> In-Reply-To: <47544B5A.9080903@chuckr.org> References: <1196470143.4750af7f6accf@webmail.rawbw.com> <4752F825.8020505@chuckr.org> <20071203144159.irjelm2c0c8o8csw@webmail.leidinger.net> <47544B5A.9080903@chuckr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Chuck Robey <chuckr@chuckr.org> (from Mon, 03 Dec 2007 =20 13:30:50 -0500): > Alexander Leidinger wrote: >> Quoting Chuck Robey <chuckr@chuckr.org> (from Sun, 02 Dec 2007 =20 >> 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 =20 >> /usr/local/lib/<linux_port_specific_directory>, then it is a big =20 >> error. But if it is in a subdirectory where no FreeBSD lib resides, =20 >> it is ok (the linux browser sets LD_LIBRARY_PATH in the start =20 >> script to the right path). >> >> Have a look how the native browser works, the private libs are not =20 >> in ldconfig either and the browser start script sets the library =20 >> path for the browser binary. At least it did this the last time I =20 >> 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 =20 put the libs in a non-standard path (this is independent from the OS). =20 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 =20 program(-suites) decide to put their libs into a non-standard =20 directory. The other one is that you should not mix libs from linux =20 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 =20 depending on the search order of the libs directories and the location =20 of the libs. The big goal is, that an user should not have the need to put =20 /compat/linux/... into his path to start a linux program. We can do =20 this by putting those linux programs into LOCALBASE (easy, if they =20 don't install libs or hide the libs in special dirs), or by putting =20 them into LINUXBASE and add a wrapper script to LOCALBASE (not as =20 easy, as you have to have more knowledge about pkg-plist in the ports =20 to get the port to do the right thing). For pure infrastructure ports (which just have linux libs), I enforce =20 the rule that they have to be in LINUXBASE as soon as I encounter a =20 port which violates this rule. For application programs I go the =20 relaxed way: fix the problem in case there's one and I get aware of it. > I just don't see any reason for such a obviously pathological thing to > occur. Just because it's possible to fix it, program by program, by > implementing wrapper scripts, you aren't going to tell me that's some > sort of elegant fix, so the fact that doing such a thing is justified? I don't think that wrapper scripts are elegant in general, but our =20 linuxulator is a special environment and if you want that other people =20 with "normal" knowledge (read: no ports committer... and even _some_ =20 ports committers would have to learn some new things to get it right) =20 are able to produce a linux port (there are already some special rules =20 to take care about with linux ports, several of them we managed to =20 cover behind some easy knobs), you have to come up with a compromise. Feel free to propose other solutions, but before you propose anything, =20 I suggest you try to write a port which implements your solution to =20 get an idea how complex it is in reality. Bye, Alexander. --=20 I've always made it a solemn practice to never drink anything stronger than tequila before breakfast. =09=09-- R. Nesson 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?20071205122123.phwu6uh7jksgcwk8>