LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
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 05-21-2009, 08:15 PM   #166
Shingoshi
Member
 
Registered: Oct 2006
Location: Cochise County, Arizona
Distribution: Gentoo-AMD64 / Slackware64-Current
Posts: 474
Blog Entries: 28

Rep: Reputation: 34
If you have to resort to profanity, let me join you!!


Quote:
Originally Posted by Franklin View Post
WTF is this supposed to mean exactly? What support am I going to lose? Will I suddenly lose the ability to ask intelligent questions?
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)=>

Last edited by Shingoshi; 05-21-2009 at 08:18 PM.
 
Old 05-21-2009, 08:21 PM   #167
Franklin
Senior Member
 
Registered: Oct 2002
Distribution: Slackware, WinXP, Windows 7
Posts: 1,253

Rep: Reputation: 55
Quote:
Originally Posted by Shingoshi View Post
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".

Last edited by Franklin; 05-21-2009 at 08:23 PM.
 
Old 05-21-2009, 08:26 PM   #168
Shingoshi
Member
 
Registered: Oct 2006
Location: Cochise County, Arizona
Distribution: Gentoo-AMD64 / Slackware64-Current
Posts: 474
Blog Entries: 28

Rep: Reputation: 34
Quote:
Originally Posted by Franklin View Post
BULLSH@T!
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)=>

Last edited by Shingoshi; 05-21-2009 at 08:46 PM.
 
Old 05-21-2009, 09:11 PM   #169
Franklin
Senior Member
 
Registered: Oct 2002
Distribution: Slackware, WinXP, Windows 7
Posts: 1,253

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

 
Old 05-21-2009, 09:41 PM   #170
Shingoshi
Member
 
Registered: Oct 2006
Location: Cochise County, Arizona
Distribution: Gentoo-AMD64 / Slackware64-Current
Posts: 474
Blog Entries: 28

Rep: Reputation: 34
Quote:
Originally Posted by Franklin View Post
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.
Quote:
So I guess Slamd64 libraries are the product of Slackware64 contributors.
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)=>
 
Old 05-22-2009, 03:22 AM   #171
Nylex
LQ Addict
 
Registered: Jul 2003
Location: London, UK
Distribution: Slackware
Posts: 7,464

Rep: Reputation: Disabled
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.
 
Old 05-22-2009, 03:35 AM   #172
rvdboom
Member
 
Registered: Jul 2007
Distribution: Slackware
Posts: 186

Rep: Reputation: 23
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.
 
Old 05-22-2009, 03:42 AM   #173
Shingoshi
Member
 
Registered: Oct 2006
Location: Cochise County, Arizona
Distribution: Gentoo-AMD64 / Slackware64-Current
Posts: 474
Blog Entries: 28

Rep: Reputation: 34
What was your installation procedure?

Quote:
Originally Posted by rvdboom View Post
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
 
Old 05-22-2009, 04:14 AM   #174
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.1
Posts: 7,139
Blog Entries: 52

Rep: Reputation: Disabled
Quote:
Originally Posted by Shingoshi View Post
Wait until the release of Slackware64-13.0!!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?
 
Old 05-22-2009, 04:33 AM   #175
Nylex
LQ Addict
 
Registered: Jul 2003
Location: London, UK
Distribution: Slackware
Posts: 7,464

Rep: Reputation: Disabled
Quote:
Originally Posted by rvdboom View Post
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.
Do you use RPMs much then? I'm just curious, as I've never really found a need for them, personally.
 
Old 05-22-2009, 05:05 AM   #176
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
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.
 
Old 05-22-2009, 05:14 AM   #177
samac
Senior Member
 
Registered: Mar 2004
Location: Westray, Orkney
Distribution: Linux Mint 17.1
Posts: 1,424

Rep: Reputation: 137Reputation: 137
Quote:
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
 
Old 05-22-2009, 08:43 AM   #178
piete
Member
 
Registered: Apr 2005
Location: Havant, Hampshire, UK
Distribution: Slamd64, Slackware, PS2Linux
Posts: 465

Rep: Reputation: 44
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!
 
Old 05-22-2009, 08:43 AM   #179
sahko
Senior Member
 
Registered: Sep 2008
Distribution: Slackware
Posts: 1,041

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

Last edited by sahko; 05-22-2009 at 08:44 AM.
 
Old 05-22-2009, 08:56 AM   #180
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

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


Reply

Tags
slackware, torrent


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
LXer: Common Public Licence superseded by Eclipse Public Licence LXer Syndicated Linux News 0 04-18-2009 04:10 AM
slackware current question on the current kernels davimint Slackware 3 06-03-2007 08:39 AM
LXer: A Public Market for Public Music LXer Syndicated Linux News 0 03-30-2007 08:16 AM
LXer: Public Venture, Public Content LXer Syndicated Linux News 0 06-22-2006 09:54 PM
To anyone=(To go public or not to go public that is the question...) hotrodowner Linux - General 10 06-25-2002 10:19 AM


All times are GMT -5. The time now is 01:58 AM.

Main Menu
Advertisement
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