alternative multilib
 

I'm looking for any documented methods for constructing a multilib Slackware system that is NOT based on just installing a multilib package, but rather, a set of steps to do to take the file tree of a 32-bit system (already installed as pure 32-bit), and selectively copy files to a 64-bit system (already installed as pure 64-bit), and then (the important part), what else needs to be done to it. I am planning to work out the steps myself and compare to what others might be doing.

Alien Bob's steps already do this. His compat32 libs are repackaged Slackware 32bit binaries.

You need his compilers and glibc to run anything in 32bit or compile in 32bit as I believe a multilib glibc/compiler is not the same as trying to use two different compilers and two different sets of glibc... but I could be wrong.

If you don't care about compiling, you can try creating an glibc package from Slackware 32bit. Just make sure none of the files overlap with your existing 64bit system.

You can use 'explodepkg' to extract to a directory, make your changes and repackge it.

Which is what I want to avoid. But if he has instructions on how to set it up w/o using such packages, that would be of interest.

I should be able to run (not compile) things compiled and linked on a pure 32-bit system, with just the same glibc (runtime pieces) as is installed in a pure 32-bit system, even though the kernel is 64-bit. The big questions are path strategy and setting up /etc/ld.so.conf and such so that programs get the appropriate libs.

I'm not really interested in compiling under multilib. I have both 32-bit and 64-bit trees of full vanilla Slackware to chroot into and compile there.

Or copy?

My goal is to derive everything from either or both of the pure 32-bit tree and/or the pure 64-bit tree. The plan is to make a script that can access both of those trees and build a new third tree that is the multilib system. But, instead of copying the files (unless they need to be changed), I will hardlink them instead, to save space (including common caching).

OK you are contradicting your self... Good luck doing whatever it is you are trying to do. I'm out of suggestions.

I don't see any contradictions. I want this solution to be done out of the existing Slackware and Slackware64 mainline packages, not some recompiled pieces that come in new packages. My goal is only to allow packages compiled on either pure 64-bit or pure 32-bit with dynamic runtime linking to run in this environment, in lieu of doing a chroot into a pure 64-bit or pure 32-bit root tree. Being able to compile in this multilib or multibit (maybe this is a better term to use if it is functionally different than multilib) environment is not my goal.

Perhaps you need to think about what you want and try and explain it a bit more. I am not convinced that what you are suggesting would work as you would need to have two glibc and gcc files (one 32bit and one 64bit) and they would both be called from the same location.

I am also not sure that you fully understand what Alien Bob's multi-lib layer does. The gcc and glibc are cross-compiling versions of the programs. Not only does this allow you to cross-compile but allows you to run both 32bit and 64bit programs as any system calls by the 32 or 64 bit program will only find one version of the program and therefore the correct instructions.

The 32-compat library programs are just the .so elements extracted from the full program and renamed so that they can be installed/uninstalled easily. You could just install the full program but uninstalling could be a problem.

You can compile application packages in a pure 32 or pure 64 and they can then just be installed on a multi-lib system whether or not they are 32 or 64 bit.

So apart from the cross compiling glibc and gcc all of it is just straight from the 32 and 64 bit trees with a little re-naming to avoid potential problems.

If I have misunderstood you then ignore this, but it does seem to be an awful lot of work for the three or four 32-bit programs that are wanted on a 64-bit system, when an elegant and logical working system already exists.

samac

What two files? Are these libraries? As far as I can see, library files are in different locations.

If Alien Bob's method is not the same as what I want to do, then I don't see any reason to try to understand it, other than as a comparison of different ways.

I have no interest in cross compiling in this project. I specifically want to avoid that as part of keeping this simple. Even if I need to patch and rebuild something (such as maybe ld-linux.so ... but I don't think I do because the different versions of the linker look in different places for other libs), I would do that rebuild inside respective pure-32 or pure-64 systems (chroot into the appropriate tree) and do that. As far as I can see, dynamic executables use a different name for the ld-linux.so execute time linker, and that can sort out the paths from there (e.g. /lib vs. /lib64).

My objective isn't to make a package (except for packaging the script itself that composes the new tree), but to make a script that has access to two fully installed systems copied into complete file trees, one the 32-bit version, and the other the 64-bit version. It would just copy the .so files (and whatever else is needed) from either or both trees into the target tree.

That is the idea, although it may involve programs someone else compiled in some non-multilib environment.

Are you referring to packaging a toolchain that lets me make both 32-bit and 64-bit binaries in the multilib environment? If so, I'm not interested in that. Any compiling I would do would be purely native with respect to the entire environment, with one exception that the running kernel would be 64-bit.

Are you referring to gcc's execute time library? Shouldn't that be found by the same means other library .so files are found? Is it different?

It seems to me that it should be relatively little work, unless there is some "gotcha" that is so far untold.

Maybe all the difference between what Alien Bob did and what I want to do is a combination of:

1. He includes cross compiling because he targets making a system that stands entirely on its own. I won't because my system will have both pure-32 and pure-64 trees available.

2. He repackages the needed pieces orthogonally from other packages since that's the minimal way to get what is needed. I would hardlink the pieces (if they don't need to be modified) from the appropriate pure-32 or pure-64 trees.

With respect to #2 above, my script will be hardlinking virtually everything in the tree it builds from scratch (e.g. my script is started with the target tree being entirely non-existant, and as its end result, a complete aggregate tree is produced).

My question in this thread is seeking to find out what else might be needed as a head start. If something else is needed, like patching and rebuilding ld-linux.so to change its behavior a bit, I'm sure I will discover that. In worse cases I might have to back up and re-do some of the design. Knowing ahead of time about issues I could plan better from the start.

What you want to do is have statically linked packages rather than dynamically linked.

samac

What packages? I don't want to make any packages (except for one with this script for those who prefer getting scripts inside packages). Why would I need static linking? The objective is to be able to run dynamically linked programs from other places (I would not be the one doing the compile in most cases).

Obviously I have been unable to understand the concept that you are trying to explain. Best of luck with your project.

samac

It is going to be hard to help you if you are not willing to even check out someone else's work.

It seems to me while you don't care for the multilib gcc work AlienBob has already provided, you may want to read up on how he got there anyways (http://connie.slackware.com/~alien/m.../source/README) as it also mentions how slackware64 binutils is already multilib ready.

As far as I can tell, what you want is to have 3 separate trees: one pure slackware64, one pure 32-bit slackware, and a mixed tree to which you will copy things from the previous two.

In that case, try having the target tree be slackware64 and just copy files into the appropriate places (/lib /usr/lib) and see how it goes. If you want multiple copies of binaries into /usr/bin you will have to change names of the binaries or have something like a /usr/bin/32 directory.

I believe that if things are described in terms of other work that is done towards a different goal, it will end up focusing on the wrong things. That's too often the issue I have run into in the past. And when that happens, it adds to the work because now things have to be separated.

This document, which I have seen before (but didn't study it in detail), is all about making a dual architecture toolchain. None of it has anything to do with issues related to just running executable files that were built elsewhere. To me, this (what the document describes building) is not a multilib environment, but rather, a useful tool for a multilib environment (if you need to do compiles in it, which I would say "definitely yes" to if the multilib environment is the only environment). I would not call it "multilib" at all. Maybe a name like "multiarch toolchain" or "multiarch gcc" would be more appropriate in terms of meaning.

Actually, hardlinked instead of copied, when the contents is the same. Basically, this would involve stuff in /bin, /opt, /sbin, and /usr. With just the pure-32 and pure-64 trees, the stuff that differs between 32-bit and 64-bit (like executables and libraries) would not be hardlinked, but the multilib tree would have hardlinks extensively shared with the pure-64, and some with the pure-32 tree. And perhaps some things would have to be copied.

When I build the two pure environment trees, I start with copies of a complete install of Slackware and Slackware64 of some version. In this case, my script runs through both trees and looks for files named the same under both trees. If they are identical, the hard linking is done. If not, then the different files are left as is. For making the multilib tree, the starting logic is to just hardlink with the pure-64 tree for all files that exist in the pure-64 tree, and hardlink with the pure-32 tree for the rest. At that point the multilib tree has nothing new besides a bunch of new directories (even symlinks can be hardlinked). Now my big question while still in the planning stages of building the script that builds this tree is ... what else (besides the toolchain I don't need).

I suspect this is nearly all that needs to be done. Yeah, I could have both 32-bit and 64-bit executables with some name changing. But it would be simple enough to do it as /32/usr/bin/${PROGRAM} (based on /32 and /64 being where I have the two pure architecture trees).

I do think the "pure and hybrid trees" construct I plan to make will be quite useful, especially for cases where stuff that can run under either pure environment needs to be tested in each (you don't have that if all you have is the multilib). While executables don't fit that, things like scripts can be.

Now it might well be useful to also include Alien Bob's multiarch toolchain for the purpose of testing source packages you develop. You can test that your package ...

1. ... builds OK in a pure 32-bit environment
2. ... builds OK in a pure 64-bit environment
3. ... builds the intended default in a multilib with multiarch toolchain environment
4. ... builds the alternate arch OK in a multilib with multiarch toolchain environment
5. ... builds both architectures if intended in a multilib with multiarch toolchain environment

It's possible a Makefile or SlackBuild for some project might have bugs with respect to one of those environments.

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.

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?

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.

Just do a full install of slackware 32 to a separate root directory and chroot when you need to execute slackware32. If you don't install all your needed 32bit dependencies to another root directory and you don't repackage them to void conflicts with your existing 64bit system then you are going to have mixed 32bit and 64bit and more than likely something will fail eventually.

If you only want the minimum, then do this with all the packages that Alien Bob has converted (not recompiled he converted them from existing Slackware packages) as well as the glibc 32bit packages. Then you can chroot for any program that needs 32bit. Then if you ever get tired of it, you can just

and be done with it.


If you don't do a chroot tree, then you are going to have to use Alien Bob's method.

If you don't want to use ALL of Slackware 32bit's packages, then you are going to have to be selective. I recommend using the list of packages from Alien Bob's method as a guide line to installing the full Slackware 32bit packages as described above. Please note, that this method will keep an install log under the 32it chroot tree because you used ROOT= when executing installpkg.

I don't know if you can set up icons or execution scripts to do

I don't see why this wouldn't work, but I haven't tried it.

More than likely, you can not simply execute the 32bit binaries with just /path/to/32bit/root/usr/bin/program As everything will be linking to /usr/lib/ instead of /path/to/32bit/root/usr/lib... But I could be wrong, and there may be some other configures on the 64bit root file tree that would allow this.

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.

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.

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.

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. ;)

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 and #2 are already chroot environments.

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.

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.

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.

Yikes, disable compilation? It wouldn't be Slackware then.

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.

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

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".

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.

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

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.

Try this command: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.

Oh, please. Spare me the melodrama. Personally, I do NOT need Eric or anyone else. I'm quite capable of creating IA32 emulation libraries myself if needed. ;) Frankly, I don't have the time to commit to this process and Eric is finally realizing the futility of the current process of adding 32 bit compilation ability to Slackware64 as well. Again, most users do NOT need 32 bit compilation ability. Actually, if Eric really wants to help the community, he'll adopt a less intrusive and time-consuming process for HIMSELF and USERS by using his multilib creation privately and release IA32 emulation libraries publicly for distribution. No one is ungrateful for Eric's work. However, the time eventually comes when any process is up for review and this time has likely come for Eric. The current process simply won't work over time for several reasons which have already been stated. Actually, it'd take a group of members to continue the process started by Eric.

Don't speak for 'most users' as I would guess 'most users' actually need the stuff to compile wine and virtual box but that's just a guess. Just because you don't need these, doesn't mean other people don't.

@tpreizel: What you are saying is: I would rather see the IA32 emulation layer in Slackware. No need for the ability to compile 32 bit software. I can make the emulation layer. But I don't want to spend my time on it, so it would be better if Eric does it. Because of reasons that were stated where?I must admit that I am relative new to Slackware. Eric is not, he has done a lot of work for this distribution. What is your contribution, that you think you are the reviewer?
Melodrama? May be. But from whom?

I use Erics Multilib and have compiled several 32 bit packages (including firefox pre 64bit flash, skype and wine), I also do some android development and have to use several pre-compiled 32bit binaries so I have found his work on the subject immensely helpful, I lack the expertise to put together my own 32 bit emulation so having clear instructions on how to implement the multilib system has made my slackware experience far more complete, many thanks to you AlienBOB for all of your hard work for the slackware community, most of us appreciate it.

Ah, so you think you can read my mind? You are reading it wrong then.
You are a known Bluewhite64 fanboi. Bluwhite64 is a Slamd64 rip-off with some bits removed (the multilib capability). It pretends to be a pure 64bit OS but then at some point, the developer thought that he should add a "IA32 emulation" layer anyway, thereby refuting his claim to be a "pure 64bit Slackware".
That "IA32" layer is a crude hack, it needs a lot of work and it uses "lib32" library directory names, which is a non-standard way to mix 64bit with 64bit libraries on a single system. According to the Filesystem Hierarchy Standard (see http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64) the use of "lib32" should be left exclusively to 32bit libraries on the IA64 platform, whereas our AMD64 platform (the official name for the PC x86_64 platform) should use "lib" for 32bit libraries and "lib64" for 64bit libraries. This is what Slackware follows.

Tell me how it is intrusive, and time consuming?
Is it "intrusive" because you have to replace your 64bit glibc packages with multilib versions which I compiled for you?
It is a simple one-line "upgradepkg" command which you use for that.
And only if you want to be able to compile 32bit software, you can also upgrade your gcc packages to my multilib-capable versions which is also achieved through the same one-line command. It is not even mandatory. My multilib packagea are primarily meant to run 32bit software, and you get optional compilation for free.

If you actually want to run 32bit binaries on the 64bit Slackware OS, you need your C libraries to be aware of them. That is why you upgrade to my glibc packages. You also have to convert and install a subset of 32bit Slackware packages to provide the 32bit libraries your 32bit program requires. All this can be achieved easily using the scripts you install with my "compat32-tools" package. You do not have to recompile anything. You just have to re-package some of the 32bit Slackware packages. That is a process which takes minutes, not hours.

We are still talking about running 64bit Slackware here. You are aware, that from day one, slackware64 is created as a 64bit platform that can easily be extended to full multilib capabilities. If you want to run 32bit applications on 64bit Slackware, then the packages that I have been providing are a time-saving and easy road to multilib capability. If you are so intent on running 32bit applications but hate my work, then by all means, install the 32bit version of Slackware! You get both Slackware versions on the single DVD that you've surely bought in the Slackware Store!

No-one forces you to use Slackware64. No-one forces you to install my multilib packages. People like Skaperen want to find out for themselves if there are alternative ways of adding multilib capabilities. I like that, when someone wants to go beyond what's already available.

But what you show in your posts, tpreitzel, is pure spite and trolling, coming from a person who has gotten stuck in the use of a deprecated distro called Bluewhite64. Go ahead, "continue" the "process started by Eric". I would not want to infest my Slackware64 computer with broken-by-design ideas originating from Bluewhite64.

Eric

Eric --

Please allow me to express my sincere gratitide for your
multilib packages/

I use the features you built in to multilib every day.

I build C-programs on my slackware-64 system that have to
run on 32 and 64 bit systems. And because of MSys / MinGW
I can also compile the same programs for Windows Systems
on my Slackware-64 system with your multilib packages.

Please keep up your good work !

Thanks.

-- kjh

I am a satisfied user of the slackware(32) and slackware64, but I do not use multilib at all.

Maybe I'm a fundamentalist of PureARCH, BUT I do not think it's correct, someone to criticize, without evidence, the hard work of AlienBOB! :tisk:

If someone thinks he can do the job better than AlienBOB, he must show us his work to see if it's true!

Until then, I see just (some) trolling ... :hattip:

I'll tell you something... I do not use multilib myself, either :-)

I used to have it installed, but at the moment I do not have a need for it (there is no proprietary 32bit software on my computers now).

Eric

PS Darth Vader, what happened to Darkstar Linux? It seems that http://www.darkstarlinux.ro/ is waiting for content.

As Eric said in his post, you don't cross-compile only re-package from a 32bit slackware tree. Regarding stuff you don't use, you don't install the whole 32bit tree. The script massconvert32.sh re-packages only some packages that are considered essential libraries and are hardcoded in it. Even with this reduced set, you don't need to install every package if you are familiar with deps. I have only installed the packages that are needed by eagle and wine.

I tried the above command and again i only get wine binaries and other stuff i compiled myself and i wanted on /usr.

With opensource you have the freedom ofcourse to do your own thing and more so with slackware that doesn't get in your way. Even if it doesn't work the way you wanted, you'll still learn something.

Who forced you (or anyone for that matter) to use Eric's packages ? Since you are quite capable of doing the X thing, then feel free to do it.

[irony]
Shame to Eric for doing futile things and for choosing _himself_ how he helps the community. Let's shoot him.
[/irony]

If you actually _were_ ungrateful for Eric's work, what would you say then ? Of course every action is reviewed and judged. I personally review Eric's work as great and i appreciate he devotes his time to do it. Let time show if it will work or not.

+1,
Thank you AlienBob for all your effort. I use multilib for Wine and I very much appreciate that I'm able to compile my own packages thanks entirely to your multilib system.

Well, it was a very difficult period for us in recent years. Romania was not exactly a workers paradise in the last years. But slowly, things return to normal, as you see, I'm (somewhat) active here, and this happens in other places too. :)

About Darkstar Linux. As you know, Darkstar = Slackware + graphics tools and (automated) dependencies. The downside is that ALICE/YaLI (our suite of graphics tools) was written in Qt3 and is outdated today. Now we are working on porting of ALICE/YaLI into Qt4, with many improvements.

About our site. Well, the current version is fresh and still is not ready, we work in the unpublished manner at its structure and functionality (and I hate the image management used by Drupal!) :)

Finally, even we think that our graphical tools are not of interest to our upstream, yet we prepare two utilities that can work very well in (pure) Slackware. It's about pkgBuild, that is a rpmbuild-like package builder for Slackware, and CParted, which is similar in functionality to GParted, but ... is a pure console tool. :)

PS. I apologize to all for this off-topic post! :)

However he builds the multilib package is fine by me. I just have no need for using the cross-32 compiler since I will have a pure-32 environment. Others who need to build software that runs on 32-bit environments may want/need to use that.

Indeed. My home desktop and file server are running Slackware 12.0 (still) with my own init scripts having replaced all of the Slackware ones. It has worked fine over several versions. Slackware is an excellent starting point for virtually any goal one has.

Why my own init scripts? Just to see if I could.