LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 04-06-2011, 05:39 AM   #16
tpreitzel
Member
 
Registered: Aug 2007
Posts: 253

Rep: Reputation: 28

Personally, I'd just like to see ia32 emulation libraries a la Bluewhite64. The vast majority of users of Slackware64 do NOT need the ability to compile 32 bit programs, just a means of running them. Although Eric's solution is more complete, it's also unnecessarily complex for the majority of users.

Last edited by tpreitzel; 04-06-2011 at 05:41 AM.
 
Old 04-06-2011, 07:11 AM   #17
markush
Senior Member
 
Registered: Apr 2007
Location: Germany
Distribution: Slackware
Posts: 3,974

Rep: Reputation: 849Reputation: 849Reputation: 849Reputation: 849Reputation: 849Reputation: 849Reputation: 849
Quote:
Originally Posted by tpreitzel View Post
...Although Eric's solution is more complete, it's also unnecessarily complex for the majority of users.
Well, I don't think that it is too complex, at least not for the normal Slackware-user. But other 64-bit distributions come with multilib as the default, which is more convenient.

Markus
 
Old 04-06-2011, 07:29 AM   #18
tpreitzel
Member
 
Registered: Aug 2007
Posts: 253

Rep: Reputation: 28
Quote:
Originally Posted by markush View Post
Well, I don't think that it is too complex, at least not for the normal Slackware-user. But other 64-bit distributions come with multilib as the default, which is more convenient.

Markus
Furthermore, Eric's approach is also inconsistent as it uses 32 bit software during boot and places SOME 32 bit binaries in /usr/bin instead of /usr/bin/32. With current "standards", it's probably best to simply restrict libraries, i.e. 32 bit or 64 bit, to separate directories while leaving everything else as a mixture of both 64 bit and 32 bit programs. Try stripping a 32 bit WINE package for compatibility and place the binaries in /usr/bin/32 instead of /usr/bin and notice the placement of the SHARE directories. Oops, that's right, there aren't any SHARE directories. Granted, the 32 bit WINE program is a special case which affects ALL 64 bit systems.

Last edited by tpreitzel; 04-06-2011 at 08:12 AM.
 
0 members found this post helpful.
Old 04-06-2011, 08:15 AM   #19
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,334

Rep: Reputation: Disabled
Quote:
Originally Posted by tpreitzel View Post
Personally, I'd just like to see ia32 emulation libraries a la Bluewhite64. The vast majority of users of Slackware64 do NOT need the ability to compile 32 bit programs, just a means of running them. Although Eric's solution is more complete, it's also unnecessarily complex for the majority of users.
Quote:
Originally Posted by tpreitzel View Post
Furthermore, Eric's approach is also inconsistent
You just go back to your beloved Bluewhite64 then, fanboi.
Or make a better implementation instead of dumping your shit on me.
At least Skaperen does a honest attempt to find an alternative approach that works better for him.

You know, it eats up a lot of my own free time to keep multilib packages up to date for Slackware64 users, and if all I get is the whining from types like you, then this is where I say "I quit and thanks for all the fish".

Slackware64 is a 64bit pure OS. Period. It was possible to add a multilib subsystem for a while, but I have better things to do. Good luck with it.

Eric
 
1 members found this post helpful.
Old 04-06-2011, 08:20 AM   #20
tpreitzel
Member
 
Registered: Aug 2007
Posts: 253

Rep: Reputation: 28
Quote:
Originally Posted by Alien Bob View Post
You just go back to your beloved Bluewhite64 then, fanboi.
Or make a better implementation instead of dumping your shit on me.
At least Skaperen does a honest attempt to find an alternative approach that works better for him.

You know, it eats up a lot of my own free time to keep multilib packages up to date for Slackware64 users, and if all I get is the whining from types like you, then this is where I say "I quit and thanks for all the fish".

Slackware64 is a 64bit pure OS. Period. It was possible to add a multilib subsystem for a while, but I have better things to do. Good luck with it.

Eric
Eric,

Nobody is disputing the work involved. Actually, it's TOO much work for the return. Simply use IA32 emulation libraries and disallow compilation and most of the work will disappear. Again, most users do NOT need to compile 32 bit programs on a 64 bit system. Finally, over time, I'm moving away from Linux entirely unless the developers of the kernel switch to a micro-kernel.

Last edited by tpreitzel; 04-06-2011 at 08:26 AM.
 
0 members found this post helpful.
Old 04-06-2011, 08:54 AM   #21
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,623
Blog Entries: 2

Rep: Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078
Quote:
Originally Posted by tpreitzel View Post
Eric,

Nobody is disputing the work involved. Actually, it's TOO much work for the return. Simply use IA32 emulation libraries and disallow compilation and most of the work will disappear. Again, most users do NOT need to compile 32 bit programs on a 64 bit system. Finally, over time, I'm moving away from Linux entirely unless the developers of the kernel switch to a micro-kernel.
Actually, don't you think it would be better to do some of the work for yourself, instead of demanding the work from others? May be you should change somewhat earlier to an OS where you are spoon-fed with pre-built solutions.

Eric is doing a great job with his work on multilib, before criticizing him you should come up with a working solution for yourself.
 
1 members found this post helpful.
Old 04-06-2011, 09:17 AM   #22
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 116Reputation: 116
Quote:
Originally Posted by TobiSGD View Post
OK, I understand what you want to achieve. But I wonder why you want to achieve something like that.
1. Can be tested with a simple 32 bit chroot in a 64 bit environment.
2. Can be tested in that same 64 bit environment.
3-5. Needs a multilib-environment anyways.
#1 and #2 are already chroot environments.

Quote:
Originally Posted by TobiSGD View Post
So wouldn't it be simpler to set up a 64 bit system, a 32 bit chroot (or a native install) and a multib environment? May be only one of them on a physical machine, the rest virtual?
That is what I am doing. Basically I will end up with 3 directory trees. At boot time I can select which tree will be the init root and once running I can chroot into the other two. I already have that running now with just the two pure environments.

Quote:
Originally Posted by TobiSGD View Post
Don't get me wrong, I think it would be a somewhat fascinating experiment to get that working. I just don't see the advantages of this new type of install over the "normal" ones, that are even simpler to set up.
It seems what you think is "another way" to do it is what I am doing, except that I am doing it where both (now) and all three (next) will be peer directory trees. Whichever I boot into leaves the others for chroot usage.

FYI ... I currently have a kernel patch that lets me specify a boot parameter of rootdir=/some/path which sets up / to be the specified directory on the partition specified via root=device. If you just mount the filesystem I built in the usual way, you'd see two directories (besides "lost+found"), named "root32" and "root64". Within those directories is everything you would get from an install of Slackware-${VERSION} and Slackware64-${VERSION}. My plan is to add a third to be named "rootml".

I could do all this by merely copying the root tree from the installation staging area. To reduce space used in the filesystem, and to enhance file caching in RAM, all files that have peer names (e.g. where "ls -l ${MOUNTPOINT}/root{32,64}/${FULLPATHNAME}" would show both files) and are identical in content are made hardlinks of each other. While executables would not be identical, the no-arch files would be, as well as some other files in the arch-specific packages. I already have this done with the two pure environments. Adding the multilib environment should be, with maybe a small few exceptions, entirely hardlinked to either the 64-bit environment (mostly) or the 32-bit environment (the compatibility parts). So I should see a filesystem space utilization attributable to just all the additional directories.

BTW, I am depricating that kernel patch I made to implement rootdir= and will be developing it as an early user space init program that takes rootdir= from the parameters and does the necessary pivoting and mount binding. This is in keeping with Linus' direction of kernel development.
 
Old 04-06-2011, 09:21 AM   #23
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 116Reputation: 116
Quote:
Originally Posted by Richard Cranium View Post
That would be fine, assuming that neither of the file trees changed. How do you intend to handle library upgrades? They do happen, as you are well aware.
That's why I will be making a script that generates the multilib tree from the 32-bit and 64-bit full trees. After doing upgrades in both 32-bit and 64-bit, I will run this script which will re-link the hardlinks in the multilib tree to be shared with the new files in the other trees.
 
Old 04-06-2011, 09:21 AM   #24
chrisretusn
Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware
Posts: 491

Rep: Reputation: Disabled
Quote:
Originally Posted by tpreitzel View Post
Simply use IA32 emulation libraries and disallow compilation and most of the work will disappear. Again, most users do NOT need to compile 32 bit programs on a 64 bit system.
Yikes, disable compilation? It wouldn't be Slackware then.
 
Old 04-06-2011, 09:26 AM   #25
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,623
Blog Entries: 2

Rep: Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078Reputation: 4078
As I said before, I can see what you are doing, but I don't understand why you are doing it. What is the actual advantage of your system over a simple 64 bit install with a 32 bit chroot, and if needed a multilib-chroot (besides some saved space)? This way you don't need all the linking and the kernel/userspace-patch. By the way, is that patching really needed? Wouldn't it be simpler to use different partitions? I think size shouldn't matter in times of harddisks in terabyte-sizes.
 
Old 04-06-2011, 09:31 AM   #26
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 116Reputation: 116
Quote:
Originally Posted by tpreitzel View Post
Personally, I'd just like to see ia32 emulation libraries a la Bluewhite64. The vast majority of users of Slackware64 do NOT need the ability to compile 32 bit programs, just a means of running them. Although Eric's solution is more complete, it's also unnecessarily complex for the majority of users.
I'd generally agree. For users that only do compiles (whether of downloaded code, or code they develop), compiling for 64-bit should be all they need. But, there might be rare cases where some source code just won't work in 64-bit. Then one or the other approach would be needed to do a 32-bit compile. Eric's approach would be fine for most users since they would not need a multiroot sysyetm. For me, and perhaps some other developers, having the multiroot system provides a means to do native compiling as well as testing. One extra aspect of my setup with include a 32-bit kernel that only mounts the 32-bit environment, just to test for any kernel version dependencies. That would require a reboot whereas all the other test environments only need a chroot under the 64-bit kernel. This would just be another kernel in the /boot partition, and another config entry for LILO and/or GRUB and/or whatever else someone might use. So my boot menu might be:

Linux 2.6.37.5 x86_64 with SlackwareML-13.37
Linux 2.6.37.5 x86_64 with Slackware64-13.37
Linux 2.6.37.5 x86_64 with Slackware-13.37
Linux 2.6.37.5 x86 with Slackware-13.37
Rescue Mode
Memory Test
 
Old 04-06-2011, 09:37 AM   #27
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 116Reputation: 116
Quote:
Originally Posted by Alien Bob View Post
At least Skaperen does a honest attempt to find an alternative approach that works better for him.
Actually, I'm thinking that it would be a good idea to also have your multilib in its own tree as another environment to have handy. I'd suspect most of it would be hard linkable to its peer file in one of the other trees. The cross toolchain would be the primary exception.

To avoid confusion, maybe I should find another term, instead of "multilib", to make reference to the way I'm building my tree. Maybe "combolib".
 
Old 04-06-2011, 09:52 AM   #28
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 116Reputation: 116
Quote:
Originally Posted by TobiSGD View Post
As I said before, I can see what you are doing, but I don't understand why you are doing it. What is the actual advantage of your system over a simple 64 bit install with a 32 bit chroot, and if needed a multilib-chroot (besides some saved space)? This way you don't need all the linking and the kernel/userspace-patch. By the way, is that patching really needed? Wouldn't it be simpler to use different partitions? I think size shouldn't matter in times of harddisks in terabyte-sizes.
It's not an issue of taking up space on the hard drive. But there is the issue of caching in RAM.

Separate partitions won't allow hard linking the files. Files that are not hard linked will appear to the kernel to simply be separate files. When the kernel caches any file contents in RAM, the unlinked files, when accessed separately (such as when I am running a test suite in 32-bit and a test suite in 64-bit concurrently) would be redundantly cached. If they are hard linked, then the separate accesses to these files are accesses to the same inode and this the same data blocks, and one cache copy in RAM suffices.

I'm also intending to make bootable backups on DVD and/or memory sticks and/or memory cards. I haven't decided on the specific details for this aspect, yet.

A recent install of Slackware{,64}-current from a few days ago netted a 32-bit root tree of 5304751 blocks, and a 64-bit root tree of 5491169 blocks, having a combined size of 10795920 blocks. After running my script that just hard links peer named files that have the same contents, the space usage went down to 7668316 blocks. And this is without the KDEI section.

Last edited by Skaperen; 04-06-2011 at 09:53 AM.
 
Old 04-06-2011, 12:12 PM   #29
imitheos
Member
 
Registered: May 2005
Location: Greece
Posts: 374

Rep: Reputation: 55
Quote:
Originally Posted by tpreitzel View Post
Personally, I'd just like to see ia32 emulation libraries a la Bluewhite64. The vast majority of users of Slackware64 do NOT need the ability to compile 32 bit programs, just a means of running them. Although Eric's solution is more complete, it's also unnecessarily complex for the majority of users.
Eric's approach works for every Slackware64 user so what is wrong with it ? For example, i compile wine. If someone doesn't need to compile 32bit binaries, then he won't do it. How is it more complex ? Why should we change something that works for everyone with something that works for "the vast majority" ?

Quote:
Originally Posted by tpreitzel View Post
Furthermore, Eric's approach is also inconsistent as it uses 32 bit software during boot and places SOME 32 bit binaries in /usr/bin instead of /usr/bin/32.

Code:
grep "bin/" *compat32* | grep -v 32/
I don't have all the 32bit packages installed but i ran the following command on the packages i have. It greps for bin/ and then ignores the lines that have 32/. If what you say is true, shouldn't it show me binaries on /usr/bin ? I don't get any though. The part about using 32bit during boot, i didn't get it at all.

I don't get what Skaperen wants to do and why the current multilib is inadequate to him.
 
1 members found this post helpful.
Old 04-06-2011, 05:54 PM   #30
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 116Reputation: 116
Quote:
Originally Posted by imitheos View Post
Eric's approach works for every Slackware64 user so what is wrong with it ? For example, i compile wine. If someone doesn't need to compile 32bit binaries, then he won't do it. How is it more complex ? Why should we change something that works for everyone with something that works for "the vast majority" ?
I guess he wants "multilib-lite", a name I just coined to refer to a multilib environment like Eric's, but without any compile feature, or maybe just 64-bit only compiling. If enough people want that, maybe Eric would split it out. If I fell into the group wanting Eric's multilib (and I am looking over the crumbling edge), I wouldn't care. Space is not an issue, so if cross compiling to 32-bit is included, so what. When I install Slackware, I install everything (except KDEI when I'm just doing test installs, so it maybe goes a little faster). There's lots of stuff I don't ever use. I could leave those things out. But the effort to keep track of it would overwhelm the advantages of just keeping life simple. So I would not be in the group that would like to see Eric split the package out. For just building an ordinary Slackware system that is basically 64-bit but can run 32-bit programs, too, Eric's multilib, complete with a cross compiler I might never use, would be just fine.

I'm only interested in the more elaborate environment I've proposed to gain selective pure environments. It may well even work out to install Eric's setup in lieu of my own, then let a script retroactively look for matching files to hard link from three trees.

Quote:
Originally Posted by imitheos View Post
Code:
grep "bin/" *compat32* | grep -v 32/
I don't have all the 32bit packages installed but i ran the following command on the packages i have. It greps for bin/ and then ignores the lines that have 32/. If what you say is true, shouldn't it show me binaries on /usr/bin ? I don't get any though. The part about using 32bit during boot, i didn't get it at all.
Try this command:
Code:
find {,/usr}/{,s}bin -type f -exec file '{}' ';' | fgrep executable | fgrep dynamically | fgrep 32-bit
Quote:
Originally Posted by imitheos View Post
I don't get what Skaperen wants to do and why the current multilib is inadequate to him.
Eric's multilib duplicates things I would have already (the ability to compile for each target), but might not actually match files I have in place. It might be worth using, anyway. It might be a worthy test target just because people are using it. I've been convinced to check it out and see, while still doing my own thing, anyway.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
upgrading slackware64 13.1 multilib to slackware64 -current multilib Cultist Slackware 4 03-12-2011 10:04 AM
[SOLVED] Broffice not compile on Slack64(multilib or no multilib);SlackBuild afreitascs Slackware 4 06-14-2010 08:16 AM
Multilib slack64 wingevil Slackware 6 02-21-2010 08:53 PM
Reversing Multilib mlangdn Slackware 3 02-05-2010 01:00 PM
Question about multilib ProtoformX Linux From Scratch 3 08-06-2009 05:02 AM


All times are GMT -5. The time now is 11:16 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration