will a program written for x86 function on slackware64 if it is multilib enabled?
 

Been thinking about changing over to 64 bit, but I was just curious about whether or not I'll have to worry about incompatibility with a few 32bit-only applications I use, once I've set up multilib. I'll test it out in vbox when I get home but I wanted to check here to see if I could maybe get a solid yes/no/maybe answer.
thanks

Yes. That's what multilib is for.

thanks. I thought I remembered reading that there were certain cases that it had to actually be a 32 bit OS for certain programs to be able to run.

Last weekend I was upgrading Firefox and didn't initially realize I had downloaded the 32-bit version on my 64-bit machine. I did an upgradepkg, replacing my older 64-bit copy with the latest 32-bit version. I've got multilib setup, and 32-bit Firefox ran without any noticeable difference. I happened to take one more look at the package name and realized it wasn't x86_64, and replaced it just to keep my system clean.

quick question before I do this. are there any reasons a person should go with x86 slackware rather than multilib enabled slackware64?

and will the 32bit-only Adobe Flash Player plugin work in 64bit Firefox?

If you happen to have a 32-bit system, x86_64 will not work. So, first you'll need to have a system that's capable of running 64-bit.
Another reason people have posted about is that they don't want a multi-lib system. Frankly, I don't know why one would not want that, but that's just me I guess. There are 32-bit applications you cannot recompile yourself, and those are not going to stop me from running 64bit in general.

And to confirm: yes: multilib is just about that: running 32bit applications in a 64bit environment. Too bad: but the reverse won't work as easily. You'll need a layer in between (qemu for example) to emulate a 64bit processor...

so if a program is a precompiled .bin application built for 32bit, it won't work even on a 64bit multilib?

It WILL work on a multilib system. What Ramurd is saying is just that you need a multilib system if you are running 64bit and you still want to be able to run 32bit applications.

No, wrong interpretation!

In short: a program will run if it's libraries / dependencies are installed correctly. So if the base 32bit libraries are installed (which is what multilib does) other 32bit applications can be compiled and thus also run.

Read more carefully and look for the context: I replied on the question if there is any reason to keep running x86 versions rather than 64bit multi-libbed. So I quote myself here: That's about the reason to keep runnin x86: for keeping the system "clean" without the 32bit libraries as dependencies installed. I'll stretch that line a bit with a few extra words: There are 32-bit applications you cannot recompile yourself, which I still can run when you run multilib, so those are not stopping me from running 64bit in general.

Is it clear this way?

Yes if you use nspluginwrapper.

Why would this be a concern though, when there's a 64-bit Flash player plugin that works perfectly well? Just install the "square preview" release, either from Adobe's site, or via Alien Bob's package.

Please remember that is a 32bit "program" has dependencies, those must be 32bit as well ;)

example: "program A", which is only available in 32bit, depends on "program B" + "library 1" + " library 2"
On your brand new slackware64, you only have "library 2" installed, but it's the 64bit version...
... so, for "program A" to work, you have to compile the 32bit version of "program B" + "library 1" + " library 2"

You don't actually have to install all 32bit libraries. You only need enough to satisfy the dependencies of what 32bit programs you want to run (which might be a lot for some things like Firefox). Statically linked 32bit programs shouldn't have any issue.

One interesting question is: what do you get if you compile a C program on a multilib system?

A statically linked program should not have any issues, true. Since most programs are dynamically linked, I did not mention statically linked programs for brevity and keeping things a bit less complex, as there is theory and practice ;-)

What you get if you compile a program on a multilib system depends on how you setup the environment; By default you'd get 64bit programs; For example in Alien Bob's multilib packages (which I assume are the way most people setup their multilib system in Slackware at least) there's a script that sets your environment to point to the 32bit libraries, so that you'd get a 32 bit application.

I think there's more to it than that. But maybe gcc will just generate either 32-bit or 64-bit code based on the environment? What about the other tools? I can believe the linker could figure it out dynamically (and complain if there is an incompatible mix). Don't know about binutils.

But at this point, I'm doing duallib instead of multilib, so I have cleaner semantics.

don't have Alien Bob's multilib packages in front of me, but weren't the binutils there as well; Anyway: if you tell gcc to link against 32bit libraries and build a 32bit binary, the result will be a 32bit binary. If you make either of the two 64bit, you'll get errors;

And what would be the difference between duallib and multilib in your view?

My duallib setup is simply two clearly obvious environments. It gives a high degree of certainty that the tool chain is operating as desired. It's basically two separate root trees, each having one library set appropriate for it. Use chroot to enter the one desired. This way you know what you get, and don't have to depend on packages to properly build Makefiles that properly pass options to get gcc to generate the correct code.

A few points on that:

32bit libraries are to be installed in lib/
64bit libraries are to be installed in lib64/

If you tell gcc that your library path is lib/ then you get 32bit libraries, otherwise 64bit.

If you installed the packages Alien Bob created, you'd have /etc/profile.d/32dev.sh and /etc/profile.d/32dev.csh from the compat32-tools package.
If you compile in that 32bit environment, you get 32bit applications. Otherwise you get 64bit applications, unless explicitly stated that you run and compile against 32bit libraries. So, in fact, due to FHS there is a distinct separation between 32bit and 64bit environments, at least as far as libraries go. And otherwise, Alien Bob made sure that it is very well possible to have the binaries separated, so you'd be sure you have a 32bit or a 64bit binary.

And if you still wonder what the result of your file is, 64 or 32 bit: you can run "file <filename>", with that you can see what you got. I don't see your problem.

All that 32-bit vs. 64-bit libraries determine is which libraries your code is linked to. It still doesn't specify what code the compiler generates. There are compiler options for that. You can end up with a mix. The "file" command cannot sort that out.

Complicate this with the fact that not all distributions use the same library naming scheme. Some, for example, put the native libraries in /lib and the alternates in one of /lib32 or /lib64 and symlink the other. If you want to make dynamically linked binaries for all Linux distributions, you are in for some surprises.

Multilib is a hack.

Now the big question is this. You have some source package that was downloaded. You have a multilib setup. You want to build this source package in both 32-bit form (so you get binary stuff that runs on machines that are 32-bit only) and in 64-bit form (so you get maximum capability on machines that can run 64-bit). Reading the instructions for the package, which claims it has been successfully compiled on dozens of different platforms and architectures, it just says to do "./Configure && make && make install" while logged in as root, and it will work and generate code for the host architecture. Will you get 32-bit code or 64-bit code (notice carefully that I am not asking what library will be linked) when you do this?

There are a number of source packages that do make an effort to be cross compile capable. Often they are packages that need to know (e.g. binutils). Packages like gcc are especially tricky, as you could be running on architecture A, building a binary of gcc intended to run on architecture B to produce code for architecture C. But most packages are not so helpful. There is no provision in their build systems to specify an architecture directly. You have to work around that somehow. There are multiple ways to do that. I've done many of them. But what I have always found to be the most reliable is to entire avoid any form of cross compiling or cross linking entirely, and build everything natively. When building a system for a new architecture, cross compiling and cross linking is unavoidable to start with. But once the new system is built for the target architecture, the next thing to do is rebuild the whole system yet again, natively on itself. Repeat until two passes have no differences.

While 32-bit and 64-bit for any architecture class might be considered by some as the same architecture, they are still, technically, different. You might have a single compiler binary that can build for either. You might have both sets of libraries. You might have a CPU that can run either set of instructions. And you might end up producing results with a mix that you would not be able to see.

I've worked on multiple architectures for years. At the very minimum, testing in pure environments is essential to be sure your compiled and linked results are correct for that environment. So you need to have those environments, anyway. You might as well use them for building, too. In cases where the environment is simulated (for example using QEMU emulating an ARM CPU), that might be an expensive way to build, and be desirable to avoid. But for 32-bit and 64-bit, on a machine that can handle both, that argument does not apply. Doing builds on a duallib/dualroot system by means of chroot into the desired environment gives the greatest confidence level that the build is correct for that environment.

The only reason I've had to avoid 64-bit Linux has been support for "Fake hardware RAID". Slackware current now supports Intel Matrix Storage Manager fake RAID. So, it is only non-Intel RAID with a mixture of operating systems (Windows / Linux) where one might want to stick with 32-bit Linux and the "dmraid" program. I have seen 64-bit packages of "dmraid" but I haven't seen one for Slackware yet. I was not able to figure out how to build a 64-bit "dmraid" from sources, if that is even possible.

I successfully installed Slackware 64-bit on my Intel fake hardware RAID using "mdadm". After installing Alien Bob's multilib packages I've had no problem running 32-bit applications including WINE 32-bit.

32-bit applications that require kernel modules or come with drivers might not work with multilib. For those applications it's necessary to get the 64-bit versions of the modules or drivers that interact with the 64-bit kernel.

What is this "fake hardware RAID"? How does this differ from software RAID?