non-multilib 64bit system

Message

aaronf0 · Post by **aaronf0** » Sun Oct 07, 2007 1:38 am

sorry if this is borderline OCD, but i have a pure 64 bit server (no multilib), but there seems to be a strange dependence on the existence of /lib64. what the hell? anyone know how to fix this? portage seems to be forcing the programs to be linked against /lib64, and constantly re-arranging root so force the usage of /lib64. can this be turned off with a libdir=..? any other solutions?

Sadako · Post by **Sadako** » Sun Oct 07, 2007 1:45 am

I'm actually using an amd64 system with no /lib64, but it takes a bit of work to set up, and it means that you won't be able to use any third party binaries (well, not unless you're handy with a hex editor

).

If you really want this I can try outlining the steps I used, however it'll mean recompiling everything on your sysetm, and I would only suggest doing it on a new install.

aaronf0 · Post by **aaronf0** » Sun Oct 07, 2007 3:08 am

well, currently its a non-booting new install, and i was just about to recompile everything anyway (already chrooted+screened), so ill give it a go.

apparently it needs /lib64 to be present for chroot to work though, so that might present some problems? right not its just a symlink to /lib, but portage has a tendancy to flip them...

Sadako · Post by **Sadako** » Sun Oct 07, 2007 6:25 pm

Sorry, meant to get back to you before now, but sleep was a higher priority.

Anyway, before you get started, just realise if you intend to use java or any third party binary this will probably turn out to be more trouble than it's worth.

Having said that, the only package that failed to compile for me was openoffice, which had /usr/lib64 hardcoded for some lib (libjpeg I think).
After taking a look at it and seeing how convoluted the build process is, I just gave up on it as I prefer abiword anyway.
That was with 2.1 (I think), so it might not be an issue anymore.

Before starting, read through everything that follows.
Also, I'll be assuming that you're fairly comfortable with user-defined portage overlays.

That fact that you are doing this in a chroot will make this much easier, I'd imagine you could do it on a live system with busybox, but I've never tried it.

First, remove the /lib/ symlink, then move/rename /lib64/ to /lib/, then create a /lib64 symlink to /lib/.
Do the same thing for /usr/lib64.
You'll be able to get rid of the symlinks when everything is working.

Okay, to get portage to link to libraries in /lib/ rather tha /lib64/ is actually ridiculously simple, just add LIBDIR_amd64="lib" and SYMLINK_LIB="no" to override the defaults according to your profile (use `emerge -v --info` to see what they are currently).

Now select some small, inconsequential app you already have installed (such as xclock).
Run ldd on it, and you should see that all the libs it's linked to are found in lib64 directories.
Re-emerge it, check it again, and you should find that all but one of the libraries are now found in lib.

That one, however, is the tricky part.
"/lib64/ld-linux-x86-64.so.2"
Damn you.

With gcc 3.4, in order to get it to use "/lib/ld-linux-x86-64.so.2" I was able to simply edit the spec files, however this doesn't seem to work wth gcc 4.1.

Actually, it does work, for everything except gcc itself!

I managed to get this working with gcc 4.1.2 by applying a tiny little patch, made available here (thx to the bunderbot).
(This actually works out a lot cleaner than modifying the specs, I currently have 17 options with gcc-config -l

)

Copy the gcc directory from /usr/portage to your overlay, get rid of all the versions other than 4.1.2, and copy the patch to the files directory, then add the following to the end of the src_unpack function in the gcc ebuild;

Code: Select all

epatch "${FILESDIR}"/linker.patch

Followed by `ebuild gcc-4.1*.ebuild manifest`, of course.

Now try building gcc, and run ldd on it's binaries to see if it worked (`quickpkg gcc` would probably be a good idea first), and if everything seems in order you can try an `emerge -e system` (read the note at the end about perl first though).

I'd recommend two `emerge -e system`, followed by an `emerge -e world`, but I may be being overcautious.

Now, run some simple tests on the binaries, for example `ldd /bin/* | grep -B 10 lib64`.
Repeat the same for /usr/bin, and everywear else you want (/lib, /usr/lib, the gcc directories, things in /opt, etc).

If satisfied, you can now remove the lib64 symlinks, and you can always recreate them if necessary (via busybox if required).
In fact, creating that symlink is all you need to get third party binaries working, which you can fix at your leisure if you choose to do so.

About perl; both dev-lang/perl and sys-devel/libperl apply a patch to get them to use lib64, simply copy them to an overlay and comment out/delete the lines where "epatch ${FILESDIR}/${P}-lib64.patch" is applied.
Do this before `emerge -e system`, and check to make sure no cruft is left behind afterwards.
You do need to be careful about updating gcc and the perl packages though, in fact it may be a good idea to mask any packages higher than what you have installed (I didn't bother, as I always keep an eye on exactly what portage will emerge/upgrade).

As a final note, I'm not actually recommending anybody to do this, I'm just telling you how to do so if it's what you desire.
If you do this, do not even think about filing bug reports or anything unless you are absolutely sure this is not the cause.

Having said all that, I've been using this on my desktop system for over a year now, and the openoffice thing is the only problem I've encountered thus far.

I've been thinking about adding this to the Docs, Tips & Tricks section for a while, but I didn't really think anyone else would be interested.
I'll be doing a new install in the next couple of weeks, so I'll probably document what I do properly then and add it (although it'll probably just be a cut'n'paste of what I have here).

Good luck with this if you try it.

aaronf0 · Post by **aaronf0** » Sun Oct 07, 2007 7:04 pm

yay thanks. gonna try it this afternoon/tommorow

this is on a server, so i would rather avoid having 3rd party binaries being ran, i hate java, and refuse to waste my time installing openoffice (im an abiword fan too). and i also watch my portage updates carefully, so perl/gcc or anything else shouldnt be a problem.

thanks for the guide.

aaronf0 · Post by **aaronf0** » Sun Oct 07, 2007 9:34 pm

well, im 2/3s of the way through the first system, and i must say this is going pretty well. is there any reason the no-multilib profile doesnt do this by default? especially on hardened, this only seems like a security hole...

aaronf0 · Post by **aaronf0** » Mon Oct 08, 2007 2:09 pm

well, it appears to have worked flawlessly. the only hitch i had was with postfix (looked like some form of a symlink) but that went away when i recompiled it after removing the /lib64 and /usr/lib64 symlinks. thanks for the guide.

Sadako · Post by **Sadako** » Mon Oct 08, 2007 2:23 pm

I'm very glad it worked for you (and that I'm no longer the only person silly enough to do this

).

aaronf0 wrote:well, im 2/3s of the way through the first system, and i must say this is going pretty well. is there any reason the no-multilib profile doesnt do this by default? especially on hardened, this only seems like a security hole...

As pretty much all third party amd64 binaries use lib64, the standard profiles really have to use lib64 directories, and this would be a lot of additional work for the hardened team with no real benefits (it's mostly just a cosmetic thing).

I don't really see how this could be a security issue...

i92guboj · Post by **i92guboj** » Mon Oct 08, 2007 4:59 pm

Hopeless wrote:I'm very glad it worked for you (and that I'm no longer the only person silly enough to do this ).

aaronf0 wrote:well, im 2/3s of the way through the first system, and i must say this is going pretty well. is there any reason the no-multilib profile doesnt do this by default? especially on hardened, this only seems like a security hole...
As pretty much all third party amd64 binaries use lib64, the standard profiles really have to use lib64 directories, and this would be a lot of additional work for the hardened team with no real benefits (it's mostly just a cosmetic thing).

I don't really see how this could be a security issue...

I can't see how it a directory called "lib" is any more secure than other called "lib64". By the way, on amd64 /lib is just a symlink to /amd64. And yes, it is a purely cosmetic issue which just doesn't worth any single minute of the gentoo developers. At least, not while there are more important things to do or care about.

Just my humble opinion.

Sadako · Post by **Sadako** » Mon Oct 08, 2007 5:05 pm

i92guboj wrote:
Hopeless wrote:I'm very glad it worked for you (and that I'm no longer the only person silly enough to do this ).

aaronf0 wrote:well, im 2/3s of the way through the first system, and i must say this is going pretty well. is there any reason the no-multilib profile doesnt do this by default? especially on hardened, this only seems like a security hole...
As pretty much all third party amd64 binaries use lib64, the standard profiles really have to use lib64 directories, and this would be a lot of additional work for the hardened team with no real benefits (it's mostly just a cosmetic thing).

I don't really see how this could be a security issue...
I can't see how it a directory called "lib" is any more secure than other called "lib64". By the way, on amd64 /lib is just a symlink to /amd64. And yes, it is a purely cosmetic issue which just doesn't worth any single minute of the gentoo developers. At least, not while there are more important things to do or care about.

Just my humble opinion.

Who was that directed at?

I completely agree with everything you just said (in fact it's pretty much what I was trying to say in my previous post).

i92guboj · Post by **i92guboj** » Mon Oct 08, 2007 5:12 pm

Hopeless wrote: <...snip...>
Who was that directed at?

I completely agree with everything you just said (in fact it's pretty much what I was trying to say in my previous post).

To the original poster, of course. I was just reiterating what you already said

Sadako · Post by **Sadako** » Mon Oct 08, 2007 5:25 pm

i92guboj wrote:
Hopeless wrote: <...snip...>
Who was that directed at?

I completely agree with everything you just said (in fact it's pretty much what I was trying to say in my previous post).
To the original poster, of course. I was just reiterating what you already said

Oh, well that's okay then.

I'm just not used to people actually agreeing with me is all.

aaronf0 · Post by **aaronf0** » Mon Oct 08, 2007 8:37 pm

dunno. i just see symlinks in / as a bad thing. also if portage can swap /lib and /lib64 at will, that is rather troublesome...

i92guboj · Post by **i92guboj** » Mon Oct 08, 2007 9:15 pm

aaronf0 wrote:dunno. i just see symlinks in / as a bad thing. also if portage can swap /lib and /lib64 at will, that is rather troublesome...

If you think so, then the symlink concept as a whole is troublesome for you. Since symlinks are created for this very same purpose: give any file as many different names as you want.

A symlink is as troublesome as its destination is. In that regard, it is not a good idea to have symlinks on / (for that regards -and specially-, in any system folder that is in the global path, like /bin or /usr/bin) pointing to stuff that is in any $HOME dir of a given user. Since that user can change the destination of the symlink. That is not a security hole, that is a direct door to death. But in this case we are talking about a symlink to anything that is only writable by the administrator. So, the symlink is secure.

EDIT: Some clarification.