Hi,

In this thread there were some concerns raised about multilib. In my own experience using multilib on three systems it is very easy to install and maintain (with slackpkg+). The only issues I have come up against are an occasional slackbuild.org slackbuild which tries to link the 32 bit libraries even if LDFLAGS is set. I have dealt with this by uninstalling the compat32 packages for the build and then reinstalling them. Other than that I have had no issues.

So I would like to pose the question: What issues/problems/inconveniences have others run into when using multilib?

Brian

What that happens, try setting LDFLAGS.

http://www.slackbuilds.org/faq/#multilib

EDIT: I still need to start reading posts before replying to them. Anyway, what were the SlackBuilds?

Same here. Happened to me with about half a dozen packages (on several hundred). Setting LDFLAGS always did the trick.

As a new Slackware convert, I found it difficult to find the documentation that shows how to use slackpkg+ to manage multilib. The page that comes to mind when I think back on installing multilib for the first time is this page. Nowhere does it mention anything about how to use the slackpkg+ extension.

I was managing my multilib installation with lftp and by watching the changelog, which wasn't all that difficult, just not automatic. I stumbled upon AlienBob's blog post only after I installed multilib manually. Which was an immense help in configuring the slackpkg+ extension.

Further details of my difficulty are documented in this LQ thread.

I think it would be helpful for future converts/new Linux users if slackpkg+ functionality was fully documented on docs.slackware.com on a separate wiki page, and linked to from this section of the documentation.

I realize that if I had installed slackpkg+ and read the README, I would have had all my questions answered. As a new Slackware user I did not know the best way to do things so it took me a bit longer. If it was all documented more clearly it would have saved me some time.

Searching the Slackware wiki yielded these additional pages that have some, but little, information on slackpkg+:

• http://docs.slackware.com/studioware:slackpkg_sbopkg
• http://docs.slackware.com/slackwareackage_management_hands_on#managing_slackware_packages_with_slackpkg (#2 on the list)

One big inconvenience is building 32-bit libraries and then converting them to -compat32 packages. I've found that I really need a separate 32-bit installation to do it, and that trying to build them with 32dev.sh doesn't always work.

I avoided the 32-bit problem by setting a USE flag on my SlackBuilds.

ARCH=x86_64 ./<package_name>.SlackBuild

However, modern SlackBuilds do have a mechanism to auto-detect the system being used and set the environment appropriately.

32dev.sh isn't meant to work in all situations. The reason is, dependencies within the system aren't always met for 32-bit as they are with 64-bit.

This is why AlienBOB gave use the converter package to download the standard i486 packages as needed and convert them to x86_64-compat32 packages. It's not always foolproof, but it does work.

The Multilib we have is honestly a minimal set to get it working, and then allow you to expand it on your own as needed. It does take work, but it can be done. I think the only SBo package I couldn't get to build was the emulator Gens. I solved that problem quickly by using the MESS emulator.

As I recall the thread, or my participation in it, this wasn't the impression intended. I didn't mean to suggest multilib was problematic per se. The person whose post I found compelling also seemed only to be suggesting, all else being equal, singlelib is more desirable than multilib. My question was whether, given the choice, it would make more sense to use a plain 32 Slackware over mixing in my particular case. It sounded that way to me hearing from the people using 32 bit, but there's lots I don't know (e.g. no one's sounded in on whether Linux takes advantage of x64's better architecture to make pages either executable or writable but not both, as OpenBSD has).

I've read over the multilib instructions and am still considering that option whenever I get around to trying to install squeak and/or pharo. I'd likely lean towards not using slackpkg+ but manually installing the mixed glibc and gcc and whatever few other packages the smalltalk VMs might need. The appeal of slackware for me right now is to do things myself until that gets boring so I've abstained from slackpkg+ so far. Even slackpkg I only used once to catch up on security updates on my initial, late 14.1 install. Later in my slackware career maybe I'll accept more gifts of what Larry Wall calls vicarious suffering, but now I'm fetishizing my own suffering. (I've even started using vi keybindings in emacs using viper for god's sake, so don't pay attention to me.)

So a lot of it's just purist/hobbiest/aesthetic considerations. That libraries go in lib64 still annoys me. Not as much as how it looks on Windows with 64 bit binaries in system32 and 32 bit binaries in SysWoW64 or whatever it's called. No doubt this is unfair given the direction of the arrow of time... so sue me I'm irrational.

SysWOW64 actually is labeled correctly.

It is supposed to read out as: System_Windows32-on-Windows64.

the FAQ mentions the problem

I think we had the topic the multilib in official will possible not happen one,
but mention it from time to time and see if something changes can not hurt
=>Slackware 64 should come with multilib included

You can also move /usr/lib to /usr/lib_ and compile the program that breaks due to multilib, and move it back once it compiled. Might be faster than uninstalling all compat32 packages. I did that for libmp3splt, since LDFLAGS did not work either.

I am curious... Why does Slackware64 install the libraries to /usr/lib64 and not /usr/lib? I do not remember what the reason behind this was.

According to the wiki:

So it's due to FHS?

1 members found this post helpful.

thank you!

If there were a poll I'd hope another option listed would be to
gradually phase out even multilib readiness over time (like in 10 years
or something). Someday the need to run 32 bit only programs should go
away. At that time the 64 on the end of lib will be a blemish.

Still I do not see, for example /libarmv7l and /usr/libarmv7l in my ARM installations...

I other hand, I miss something, or the Linux tree shall be agnostic for ARCH, and eventually, a secondary thing/enhancement shall go in its directories?

Is not logical to have x86_64 libs in /lib and /usr/lib, and whatever arch-compat in /lib32 /usr/lib32 or even /lib16 /usr/lib16 and for the hard fans of Z80 even /lib8 and /usr/lib8 ?