LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
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-04-2011, 08:36 AM   #1
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Rep: Reputation: 115Reputation: 115
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.
 
Old 04-04-2011, 08:57 AM   #2
lumak
Member
 
Registered: Aug 2008
Location: Phoenix
Distribution: Arch
Posts: 799
Blog Entries: 32

Rep: Reputation: 109Reputation: 109
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.
 
Old 04-04-2011, 11:20 AM   #3
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: 115Reputation: 115
Quote:
Originally Posted by lumak View Post
Alien Bob's steps already do this. His compat32 libs are repackaged Slackware 32bit binaries.
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.

Quote:
Originally Posted by lumak View Post
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.
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.

Quote:
Originally Posted by lumak View Post
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.
Or copy?

Quote:
Originally Posted by lumak View Post
You can use 'explodepkg' to extract to a directory, make your changes and repackge it.
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).
 
Old 04-05-2011, 04:28 AM   #4
lumak
Member
 
Registered: Aug 2008
Location: Phoenix
Distribution: Arch
Posts: 799
Blog Entries: 32

Rep: Reputation: 109Reputation: 109
Quote:
Originally Posted by Lumak
Alien Bob's steps already do this. His compat32 libs are repackaged Slackware 32bit binaries.
Quote:
Originally Posted by Skaperen View Post
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.
...
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.

Last edited by lumak; 04-05-2011 at 04:30 AM.
 
Old 04-05-2011, 08:23 AM   #5
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: 115Reputation: 115
Quote:
Originally Posted by lumak View Post
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.
 
Old 04-05-2011, 10:02 AM   #6
samac
Senior Member
 
Registered: Mar 2004
Location: Westray, Orkney
Distribution: Slackware64-14.1 (multi-lib) KDE 4.11.4
Posts: 1,422

Rep: Reputation: 137Reputation: 137
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
 
1 members found this post helpful.
Old 04-05-2011, 10:58 AM   #7
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: 115Reputation: 115
Quote:
Originally Posted by samac View Post
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.
What two files? Are these libraries? As far as I can see, library files are in different locations.

Quote:
Originally Posted by samac View Post
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.
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).

Quote:
Originally Posted by samac View Post
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.
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.

Quote:
Originally Posted by samac View Post
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.
That is the idea, although it may involve programs someone else compiled in some non-multilib environment.

Quote:
Originally Posted by samac View Post
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.
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?

Quote:
Originally Posted by samac View Post
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.
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.
 
Old 04-05-2011, 11:15 AM   #8
samac
Senior Member
 
Registered: Mar 2004
Location: Westray, Orkney
Distribution: Slackware64-14.1 (multi-lib) KDE 4.11.4
Posts: 1,422

Rep: Reputation: 137Reputation: 137
What you want to do is have statically linked packages rather than dynamically linked.

samac
 
Old 04-05-2011, 12:52 PM   #9
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: 115Reputation: 115
Quote:
Originally Posted by samac View Post
What you want to do is have statically linked packages rather than dynamically linked.
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).
 
Old 04-05-2011, 01:00 PM   #10
samac
Senior Member
 
Registered: Mar 2004
Location: Westray, Orkney
Distribution: Slackware64-14.1 (multi-lib) KDE 4.11.4
Posts: 1,422

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

samac
 
Old 04-05-2011, 02:32 PM   #11
octoberblu3
Member
 
Registered: Oct 2005
Distribution: Slackware64-current
Posts: 67

Rep: Reputation: 22
Quote:
Originally Posted by Skaperen View Post
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.
It is going to be hard to help you if you are not willing to even check out someone else's work.

Quote:
I have no interest in cross compiling in this project. I specifically want to avoid that as part of keeping this simple.
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.
 
Old 04-05-2011, 03:35 PM   #12
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: 115Reputation: 115
Quote:
Originally Posted by octoberblu3 View Post
It is going to be hard to help you if you are not willing to even check out someone else's work.
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.

Quote:
Originally Posted by octoberblu3 View Post
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.
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.

Quote:
Originally Posted by octoberblu3 View Post
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.
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).

Quote:
Originally Posted by octoberblu3 View Post
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 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.
 
Old 04-05-2011, 04:22 PM   #13
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,521
Blog Entries: 2

Rep: Reputation: 4020Reputation: 4020Reputation: 4020Reputation: 4020Reputation: 4020Reputation: 4020Reputation: 4020Reputation: 4020Reputation: 4020Reputation: 4020Reputation: 4020
OK, I understand what you want to achieve. But I wonder why you want to achieve something like that.
Quote:
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
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.
 
Old 04-05-2011, 04:35 PM   #14
lumak
Member
 
Registered: Aug 2008
Location: Phoenix
Distribution: Arch
Posts: 799
Blog Entries: 32

Rep: Reputation: 109Reputation: 109
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.

Code:
ROOT=/path/to/32bit/root installpkg package-name-0.0.0-whatever.txz
chroot /path/to/32bit/root
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

Code:
rm -rf /path/to/new/root
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

Code:
chmod /path/to/32bit/root; ./usr/bin/program_name
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.
 
Old 04-05-2011, 09:01 PM   #15
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,477

Rep: Reputation: 415Reputation: 415Reputation: 415Reputation: 415Reputation: 415
Quote:
Originally Posted by Skaperen View Post
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.
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.
 
  


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 09:04 AM
[SOLVED] Broffice not compile on Slack64(multilib or no multilib);SlackBuild afreitascs Slackware 4 06-14-2010 07:16 AM
Multilib slack64 wingevil Slackware 6 02-21-2010 07:53 PM
Reversing Multilib mlangdn Slackware 3 02-05-2010 12:00 PM
Question about multilib ProtoformX Linux From Scratch 3 08-06-2009 04:02 AM


All times are GMT -5. The time now is 10:55 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