64-bit kernel, 32-bit userspace?
Originally started here: http://www.linuxquestions.org/questi...73#post3444973
The gist of it being "What happens if I throw in a 64-bit kernel with slackware stock 32 bit userspace applications?" I've started a new thread here because this is not related to the original post, really. Quote:
The reason for compatibility libraries (which are no more than stock slack libraries) is one of separation*. Not everyone needs them, so it makes sense to separate them out so those who do use them can install them, and those who don't ... don't. However, if you want a LotR (one glibc to rule them all ... ) approach to toolchains in your slack, then you probably need to investigate biarch glibc: http://devpit.org/wiki/Gnu_Toolchain...Building_GLIBC http://ozlabs.org/pipermail/linuxppc...ry/000852.html The general theory being a biarch compiler backed up by a biarch glibc (and binutils) can produce two binaries at the flick of a switch. I question how necessary having a biarch toolchain is, when considering the amount of effort to generate one vs using two separate (and already prebuilt) toolchains; it's not like you'd have cause to suddenly swap architecture mid-build. Is it? My head is hurting just contemplating the mess that would make! Quote:
This may mean dismantling the makefiles and ensuring there is a clean separation between module and application. It could be as easy as `ARCH=x86_64 make module && ARCH=i386 make application` but I doubt it. You've said that a 64 bit kernel is better than PAE (http://kerneltrap.org/node/2450) for memory addressing, but does your 32 bit userspace not throttle (at least in part) you because your apps don't understand a bigger memory space? I'm thinking of place and route operations or mathematical simulation. If you have a lot of smaller apps, there may be some benefit to be had. The one final question I have: in this mix of 32 bit and 64 bit stuff, what should be reported by uname? - Piete. * I am not a slamd64 contributor or Fred. In my mind, c/ is used to separate things sensibly. I have in the past gotten things wrong, so if there is an official stance on the whys and wherefores of c/ ... it's not being made by me. |
Quote:
Quote:
Quote:
Anyway, my :twocents:. |
You're perfectly correct of course, you're still going to end up with two sets of libraries. Apologies for the confusion.
|
piete: Thank you so much!!
I really appreciate seeing that others have more than a passing interest in this subject. I'm glad that you went back and posted the link to this thread in my original comments. Thank you friend!
I just signed up for membership on the first link. I will now take time to look at the rest of this. Thanks friend! Xavian-Anderson Macpherson Shingoshi Ok. Additionally, I've thought it best to simply build everything from this point forward as 64-bit. There's a good reason for this, in that Slackware already has most if not all that it needs. Slamd64 on the other hand doesn't. So encouraging users to build 64-bit applications should be the priority. As I've said elsewhere, I think only those applications that won't for any reason run as 64-bit, should be built as 32-bit. This will however mean that I install the rest of Slamd64. That's the point of concern that I've had with this. If I can do that without any compromise to my Slackware system, then there's no problem. |
Ok. Maybe this sums up the dilemma...
With having nothing but 32-bit packages installed, you also only have 32-bit libraries also. So when you go to build new applications (from your Slackware system), they're looking for libraries in /usr/lib64 or /lib64 (because that's where uname tells the build to look), except you don't have anything there. So the builds fail, even though you have the libraries installed. They're just not the right versions in the right place. So you need a means to build the packages against the 32-bit libraries (and maybe create 64-bit packages from those, if that's you highest priority). Because once you have as large a database of (3600+) packages installed as I do, the whole point is to use those packages, even for building others, not just to run the binaries. So there's the problem that hasn't yet been answered. I realized that I needed to write this after just having another package fail to build. In the report, I then saw it was looking in /usr/lib64.
So, now that hopefully my question is clearer, please explain how to resolve this. Thank you, Xavian-Anderson Macpherson. ps. With Gentoo, this process would all be handled automatically, by doing an "emerge system" (for the toolchain), and then an "emerge world" (for the packages in their proper order). |
Quote:
But since Slackware is not available in 64bit, and Gentoo supports it, comparing the two is pointless. Eric |
The reality about moving from one to another...
Quote:
Just try it with a test installation of Slackware. If you have no or very few packages on your system except what's from Slackware, Slamd64 will install just fine. In fact, it will install just fine anyway. It's just that's you'll have to recompile all of your old packages which Slamd64 doesn't have. That's my case now with having so many packages from Slacky.eu, which has a phenomenally larger database than Slackware proper. As mentioned above, I have 3600 packages installed. So I'm facing a big undertaking in switching this time around. Xavian-Anderson Macpherson Shingoshi |
Quote:
1. Treat your system as a pure 64-bit system, and treat every build you do as a cross-compile. 2. Hack uname to return x86 instead of x86_64. I've seen 2. used in reverse in a 32-bit chroot environment on x86_64. Basically you build a shell script, chmod it and install it over the uname binary, to return the values you want it to and fool any programs that call it to use the result to determine the architecture. For 1. this means having one of: a) x86_64/x86 biarch toolchain ii) x86_64->x86 cross toolchain 3) x86 native toolchain I confess to not knowing the current state of the slamd64 toolchain, however for this explanation, let's assume it's native x86_64, so the first two options aren't available. Since slackware's toolchain is native x86, in my mind it makes the most sense to use that one to build your userspace apps. It should just be enough to ensure that your x86 toolchain binaries are ahead in the path of the x86_64 binaries, and then that's it, job done. Pass the necessary ARCH options to the new sources so they know (or are fooled enough not to care) about the arch and voila. I could go on and on, but back to you :) - Piete |
Quote:
Quote:
Anyway, my :twocents:. Quote:
|
Quote:
|
I was speaking in the context of compile process...
Quote:
I'm waiting for the author of my build tool (src2pkg) to update it to handle this situation. This would be good, because it will clear the way for others to pursue the same path, and have cross-compilation capacity (in various environments) immediately available. And about Gentoo. You missed my point. The point was that Gentoo has an automated build process. Quote:
Hopefully, this clears things up Xavian-Anderson Macpherson Shingoshi |
Quote:
Use the linux32 utility. This changes the kernel personality so that for all subprocesses, the kernel reports itself as i386 - including an unpatched uname, and binaries that use syscalls/other methods to work out the current architecture. |
Quote:
|
If we set aside all the issues related to cross-compiling...
What packages from Slamd64 are needed to be added to Slackware along with the 64-bit kernel, that will allow a user to run 64-bit applications? We only need those packages listed that are absolutely necessary for 64-bit operations.
Whatever that set of packages are, that's the set that should comprise the meta-slamd64 package for Slackware users to install, to upgrade to Slamd64. This would be the same as an absolute minimal install for Slamd64. So, taking a guess: aaa_base aaa_elflibs aaa_terminfo (?) glibc (the whole set, with compat as well) Xavian-Anderson Macpherson Shingoshi |
Here's an interesting thing to be aware of...
1 Attachment(s)
When running a 64-kernel on a 32-bit system, you may find that Firefox complains about the type of FlashPlayer you have installed. I've had it work as often as not. But a simple solution may simply be to install this package, and run "linux32 firefox" when you start Firefox. The linux32 supplied by Slamd64 is a 64-bit application, and won't work on a 32-bit system.
Change the extension from .txt to .tlz, to install with pkgtools-tukaani. Xavian-Anderson Macpherson Shingoshi |
All times are GMT -5. The time now is 10:39 PM. |