It means whenever someone asks what they think is an intelligent question (as many others have done in the past), they will likely be met with "your system isn't supported. So yes! That's exactly what it means. Because no one in the development team has yet given specific advice about what to do or in what order to do it in.

Every Slackware64 32-bit user will be in no-mans land. They will neither have a true Slackware64, nor Slamd64 system. Now Slackware64 may (or not) be a little more understanding of your situation. But Slamd64 won't appreciate having to give advice on how to make your Slackware64 system work. I've already faced that very same thing. They could and would be completely justified to tell you, "you should have installed Slamd64!

That's WTF I'm talking about!!
Shingoshi
>=(o_O)=>

BULLSH@T!

The only time people get pissed is when someone wastes their time complaining about a "bug" that turns out to be due to someone running a "custom kernel" or making some other change to the stock system "AND NOT STATING THAT UP FRONT".

All I've EVER seen anyone say is "please reproduce this on a clean system using the generic kernel before reporting as a bug".

And what exactly is it about having Slamd64 libraries on a Slackware64 system, that qualifies as a CLEAN system? What! Are you supposed to uninstall the very Slamd64 libraries you've installed, just so you can report that bug doesn't happen without them?

This really is FUNNY!!
Shingoshi
>=(o_O)=>

Again. Slowly this time...

1. What support are you talking about? This isn't Novell or RedHat.

2. If you think this forum is the "support", then what is stopping you from asking an intelligent question about a unique situation in the correct forum with perhaps many other people who, at that time, would be looking for the same answers?

3. If you expect any of the contributors to fall all over themselves dissecting a problem that has nothing to to with the product they produced, then I believe your expectations are out of line.

4. Getting your panties in a bunch about a release that isn't even in RC status is a bit over the top.

5. Any legitimate issues you may have are completely drowned out by this unrelenting rant.

I would suggest that you take a break from this discussion and return to it when you actually "have a meal to complain about". For what it's worth, you sound more like someone with an axe to grind than someone with anything of value to say and, unfortunately, that's probably not the case.

I'm done. Have a nice day.

It's already been established (by samac) that the Slamd64 libraries are working just fine. There should be no concern about the long-term.

Shingoshi
>=(o_O)=>

I haven't read the entire thread, but I'm also glad that the Slackware team have decided to go 64-bit, even though I don't really need it. I suppose it was inevitable, really, but still . Thanks to the entire team for all their hard work on this (and Slackware in general). I may give it a go before 13.0 is released, but we'll see.

After some work, I finally managed to upgrade my system from Slack32 to Slack64 but did not make it without a CD. :-)
Overall, it looks good, I have some painting issues in KDE, but as I use the SVN snapshot 4.2.87 I compiled myself, it's difficult to know if it's related to being 64 bits or if it's a current KDE issue.
But I've come by a real problem here : the rpm package seems compiled against a libnss3 lib, which is not part of Slackware. So rpm and especially rpm2tgz doesn't work for me here.
The 32bits version is not linked to libnss3 either.

Did you start the upgrade from the cd? Or did you attempt to try it first by following the recommend steps posted above? Did you install your 64-bit kernel first or not? Please try and outline the steps you took and in what order.

Shingoshi

I still regard myself as a relative newbie, but I think that is the most sensible thing you've written. Why should anyone take notice of or follow your ideas and procedures when they are contradicted and criticised by Eric, Robby, and others?

Do you use RPMs much then? I'm just curious, as I've never really found a need for them, personally.

So I have a question, what's the difference between installing the slamd64 compatibility libs and just using the slackware libs in slackware64 ? I heard that slamd64 used many of the slackware packages to make the compatibility libs ... so what exactly is the difference if anyone knows.

A useful question, I would also like to know a bit more about this. I have always thought that they have been compiled on a 64 bit machine/OS to run 32 bit programs, but I am sure that there is much more to it than that. I suppose the best people to ask would be Alien Bob or Fred Emmott.

samac

Short answer: none.

Long rambling answer:
There's actually much less to it than that. The "compatibility" part of compat-libraries are to supported binaries of a different architecture.

x86 / x86_64 is quite an interesting case. Although I have heard others speak about the change from 8 to 16 to 32 bit processors, I can't (off hand) name another processor that maintains backward compatibility at the instruction set level, which is what x86_64 does with x86.

Firstly, if you do not have that backward compatibility enabled in the kernel, consider your system 64 bit and forget all this biarch crazy talk. If you do have that option enabled, then you have a biarch system.

From an application level, let's say you install 32 bit gimp. Well, if you go to gimp and you ldd the binary, you'll get a stack of information about what it's linked against, but more importantly, about where it's looking for those libraries.

So gimp demands libpingo, libz, libgmodule (I'm just reading off from my own version here ... ) and so on and so forth.

During compilation, someone told gimp that it needed those things and that it should always go looking for them at run time (dynamic linking). All those .so files are shared objects - think of them as little pieces of code that applications can use like ... borrowing a lawnmower from your neighbour. So that bit of code doesn't reside inside your program (gimp), it resides in the shed (/usr/lib et al). You could upgrade that program, which would be like your neighbour getting a new lawnmower. You get to use the new one now instead of the old one (there are some cases this can't work ... for the analogy, your neighbour bought a lawnmower that uses a different plug socket, so you can't use it).

Code compiled as 32 bit is fundamentally incompatible with code compiled as 64 bit. Once you realise that, the rest is easy.

So now in order to use your copy of gimp, you need to satisfy it's dependencies at a 32-bit level. It is expecting those libraries, so run off and install them.

Bosh. Job done. Your 32 bit gimp will now work just fine.

In this case, you should be able to install slackware application-level libraries to satisfy any 32-bit dependencies you have and things will Just Work (tm).

This is also true of glibc (I should say now that I have not tested this!), you'll notice that glibc has a bunch of shared object files that are located in /usr/lib. These are just more pieces of code that can be used by other programs. Communal code, you could say.

So that's the overall idea, so long as you're satisfying the deps for the program (ldd is now your best friend), there is no problem, and the notion of compatibility libraries is rather moot.

The reason we have any discussion of compat packages at all is because there are, frankly, a lot of items that you don't need. All of your heavy lifting is done by the 64-bit binaries and packages you've got, so any package that is x86 or 32-bit can probably be trimmed right down so it only includes what you need to support the binary you're trying to run.

Off the top of my head, ldconfig from glibc is a binary, which means installing glibc-solibs x86 would clobber your nice 64-bit ldconfig. Man pages are another potential issue, you'd find a lot of doubling up and clobbering.

That's from an application/user level. When we get into compilation, there are some other pitfalls to be aware of. My experience has been that compiling 32-bit code is best done in a 32-bit chroot environment (and better done in an emulator where you have a read only image!). I can hear people complaining about having to have 2 systems installed, but honestly, when your wierdly written program tries to link against a 64 bit library and the 4 hour build dies with a linker error, you'll know what I mean. Fundamentally, the world is at a stage where there are very few reasons to be building 32 bit software in parallel with your 64 bit pieces. And if you are doing that regularly, you're likely a developer and already have best-practice methods worked out for yourself. I would postulate that most users who are au fait with slackbuilds but don't necessarily care about the compilation details, will find that not having "compatibility libraries" a bonus, because there's less to go wrong.

64 bit flash was a huge stopping point that has, thankfully, gone away. Wine is the other point, but really ... why bother building wine when you can pull a package that Just Works (tm)?

- Piete.

Disclaimer: my advice is worth exactly as much as you paid for it. Back up everything first and do read around about what exactly it means to be biarch!

Thanks to Pat and the rest of the Slackware Team for making it happen. And especially Alien_Bob for this one.
I agree with Shingoshi on one thing. Slackware 13 seems much more closer now, with all these changes in -current.
First xz, now x86_64 and a much more stable KDE4. I guess its up to the x86_64 port to be proven stable enough for the new release to see the light.

Thanks for the long answer, you've answered my question, and you're right I've had it happen that I've been compiling a large program for say half on hour or so and then ... linker error trying to link against 32-bit libs in /usr/lib ... now that really sucks. So maybe I should just use a chroot, it's a lot cleaner. I guess I'll have to find a guide to doing that properly cuz I've never done it before. And you're right that I usually don't need any 32-bit programs ... but I do play Window$ only games once in a while and may need wine.