SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I believe you've got me mixed up with someone else ( #206 ).
But would you not say that Alien Bob's Multilib System provides a cross-compiler ?
I do because I use it that way to cross-compile Intel 32-bit programs on my Intel 64-bit system.
And as far as automatically installing Multilib ... even RedHat makes Multilib optional via the compatibility libraries ...
YMMV ...
-- kjh
yes, this -> these, typo, sorry, fixed it.
you where not meant , only those I have now on my ignore list, and you are not on it
PS: I would not call this cross compiling, because from multilib gcc , everything is native for the current host with the same compiler
a gross compiler is an extra compiler on an extra location and usually also has the prefix of the target system and a whole own sysroot where it's libraries are and this is not /
don't take this guy serious, he doesn't understand the difference between a cross compiler and a multilib compiler, but he manages to have the brain acrobatic to be against inclusion of multilib compiler in 64bit Slackware but he thinks that 'optional 64bit kernel for Slackware 32bit is a interesting suggestion for improvements.' #206
Excuse me, but I keep my statement, because I tested myself that and I seen the differences. I tested even your benchmark.
I confirm again that Slackware 32bit works fine and apparently faster with the kernels from Slackware64. And TBH, I am interested by this subject.
And I think this thread as being very interesting, showing so many interesting alternatives for how to make 32bit applications and how to run them with maximum efficiency.
Last edited by ZhaoLin1457; 07-08-2018 at 11:31 AM.
I fail to understand WHY someone will insists to build 32bit programs on a pure 64bit operating system.
People, there's a saying: "use the right tool for the right job."
I believe that the best way to build 32bit programs is obviously a 32bit operating system. Either ran on bare-metal, or in a LXC container, or a virtual machine. And there's always for you the Slackware 32bit.
And for running particular 32bit programs (specially those which heavily use integers) with max performance, there's always for you the variant of using 64bit kernels on Slackware 32bit.
But another saying is "for someone who has a hammer, everything looks like a nail"
Valid if the hardware was 'pure' 64-bit. Maybe. It is not. Otherwise you could not run 32-bit and 16-bit, even 8-bit?, on an Intel processor. Yet, you can. If so concerned with 64-bit OS purity why the hell are you not running pure 64-bit hardware?
don't take these guy serious, he doesn't understand the difference between a cross compiler and a multilib compiler, but he manages to have the brain acrobatic to be against inclusion of multilib compiler in 64bit Slackware but he thinks that 'optional 64bit kernel for Slackware 32bit is a interesting suggestion for improvements.' #206
Darth Vader is agains multilib, talks about alternatives that are all no alternatives, just to destroy any useful discussion
and jakep says my example, from which I said it is obvious that is is faster, is not an example for anything because it is obvious that such code is faster on 64 bit if compiled with32 bit, just to produce poison and make noise in this thread and be able to troll arround, togheter with Darth and ZahoLin
and I got friction points for the same post 2 times in a row, still don;t know why 2 times, but the trolls that mess up this and other threads with undoable or wrong techical info or pure nonsens and/or provocations are allowed to continue spread their mess in this place.
which is an other prove why multilib compiler should be available by default and not via a 3rd party repo, but of course just for those who understand what it is and wherefore it is used, and the persons who made the most noise in this thread, namely Darth Vader, jakep and ZhaoLin1457 are not in this group, they are trolls that want to destroy every topic and discussion here they don't understand.
sad to see to what this place became, no wonder that on Linus conferences and other places Linux devs and other people get a slightly grin on their face when the topic comes to Slackware
actually, this topic is final discussed, I think an admin should close this thread
You may have noticed that -m32 is short for Machine Architecture 32. To gcc it is cross-compiling, multilib and cross-compiling is the same thing and to say it is not is trying to play semantics.
You have yet to provide proof of faster execution speed. If you were right my point still stands, it would still be slower unless over 2 times faster than 64-bit. You fail to notice simple computing knowledge. Let me repeat. 64-bit has twice the bandwith, it processes twice the data, it is technically twice as fast, we are talking about a whole and not some specific detail.
Valid if the hardware was 'pure' 64-bit. Maybe. It is not. Otherwise you could not run 32-bit and 16-bit, even 8-bit?, on an Intel processor. Yet, you can. If so concerned with 64-bit OS purity why the hell are you not running pure 64-bit hardware?
Take easy, Cowboy!
The "pure 64bit" is not a thing about "purism", but it is just a term to describe the operating systems who has support only for execution of 64bit applications, i.e. a "single-architecture" in contrast with "multi-architecture" operating systems which has also support for running 64bit applications.
Rather, it is an architectural concept.
For example, 64bit Windows 7 is triple-architecture, running programs for 64bit, 32bit and 16bit. Yet, from what I know and I am not mistaken, Microsoft sells a Windows Server which is 'pure 64bit'
Even the old good Windows XP was double-architecture, running programs for 32bit and 16bit.
Those terms like 'pure 32bit', 'pure 64bit' or 'multi-architecture' are not specific to Linux. And in future probably well see also 'pure 128bit' and so on...
Last edited by Darth Vader; 07-08-2018 at 12:55 PM.
Compared with the 32bit kernels and their PAE, the 64bit kernels use so called "linear addressing", then they does not need to translate and re-translate memory locations, via a whatever table of chunks. Then they are a bit faster.
Perhaps you mean "long mode addressing"? Linear addressing would imply no logical memory mapping at all, which is needed for things like shared libraries, encapsulated process spaces, sysv IPC, CoW and other system features. The x86_64 logical memory model extends PAE from three table levels to four but is otherwise similar.
In all but the most pathological cases (and a few edge cases, like process initialization), the TLB effectively eliminates the performance penalty of looking up addresses in page tables. It is an O(1)-lookup cache of memory mappings, and the pipelined nature of modern systems and the use of tags in instruction caches means TLB hits usually don't even impose a single cycle of latency to memory lookups.
It will take close inspection to ascertain why the x86_64-compiled microbenchmarks outperform their 32-bit counterparts. Modern systems are hellishly complicated and the cause-and-effect relationships are often not obvious. Perhaps the eight new registers (r8-r16) only accessible in 64-bit mode have something to do with it?
I remember some architectures back in the 1990's supported a mixed-word-width architecture (64-bit data, 32-bit addresses) which gained a slight performance enhancement over 64-bit everything due to improved cache utilization (twice as many pointers fit in cache), but would be surprised if that still applied to modern systems.
Since you corrected me several times when I'd use KDE5 instead of Plasma 5, I figured I'd return the favor here. It is not SystemD, it is systemd, all lowercase.
Quote:
Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple.
In regards to this topic, I really don't have a big preference. I can definitely see why people would prefer to have a more official version of multilib that is either installed by default or is in extra/. However, I don't think it will ever be installed by default since Pat could've done that from the outset and decided against it and I doubt he'd change his mind almost a decade later. The reasons to use multilib are certainly fewer than they were when Slackware64 13.0 was first released, however, for many users, it is still a requirement to have multilib for a multitude of reasons (I still have need for it on my desktop for gaming, but my htpc and server are both pure 64bit).
If I have any say in the matter (and let's be honest, I don't), my preference would be to either leave it as it is or to move the multilib gcc and glibc to extra/ and keep all other compat32 packages either with Eric or require people to convert their own from the 32bit Slackware release. I think it is unreasonable to try and fit a complete multilib setup on a Slackware DVD (although, I've never checked).
However, I imagine having at least a portion of multilib was already discussed when it was decided Slackware was to be a pure 64bit distro, so all these 230+ posts probably won't change the current status of Slackware64 and multilib. That's just my
Agreed, all this trolling is going to change nothing and only is entertainment for bored people with too much time on their hands. All one needs is the src, and Eric provides helper scripts, to build glibc and other parts required. Maybe for the trolls, and those that want to play, I will collect of what is needed into one repo. Which is really a duplication of effort but I would like to build my own mulitlib libs for Steam anyways when Slackware64 15 is out, so...
In regards to this topic, I really don't have a big preference. I can definitely see why people would prefer to have a more official version of multilib that is either installed by default or is in extra/. However, I don't think it will ever be installed by default since Pat could've done that from the outset and decided against it and I doubt he'd change his mind almost a decade later. The reasons to use multilib are certainly fewer than they were when Slackware64 13.0 was first released, however, for many users, it is still a requirement to have multilib for a multitude of reasons (I still have need for it on my desktop for gaming, but my htpc and server are both pure 64bit).
If I have any say in the matter (and let's be honest, I don't), my preference would be to either leave it as it is or to move the multilib gcc and glibc to extra/ and keep all other compat32 packages either with Eric or require people to convert their own from the 32bit Slackware release. I think it is unreasonable to try and fit a complete multilib setup on a Slackware DVD (although, I've never checked).
However, I imagine having at least a portion of multilib was already discussed when it was decided Slackware was to be a pure 64bit distro, so all these 230+ posts probably won't change the current status of Slackware64 and multilib. That's just my
I see the ignore list is not perfect and I can still see what people quote. but at least I do not need to see the whole post of how some troll produce garbage with the only indention to create noise and trash and brings therefore even systemd into this thread that is about 'please include the multilib compiler into Slackware'.
I see the ignore list is not perfect and I can still see what people quote. but at least I do not need to see the whole post of how some troll produce garbage with the only indention to create noise and trash and brings therefore even systemd into this thread that is about 'please include the multilib compiler into Slackware'.
The quote was out of context. And looks like that someone is right when talks about the new trend of overrusing the words like "troll", "garbage", "trash", "noise", etc.
Permit me to quote the entire post and what reply to was:
Quote:
Originally Posted by kjhambrick
And as far as automatically installing Multilib ... even RedHat makes Multilib optional via the compatibility libraries ...
Quote:
Originally Posted by Darth Vader
Yeah, man! RedHat gives you Multilib optionally.
BUT, also it gives you the RPM package manager, and automatically dependencies tracking. It also, gives you LinuxPAM and Kerberos. And I kept best one for the last: SystemD
Did you really believe that Patrick Volkerding should to exactly what RedHat do?
Excuse me, but what I understand from this replies exchange is:
You cannot come with the RedHat doings as argument, because Patrick Volkerding vision is known to differ from RedHat on many other important points.
Last edited by ZhaoLin1457; 07-09-2018 at 01:50 PM.
Oh, ZhaoLin1457, btw, you also made it onto my ignore list. So please feel free to continue writing whatever nonsense you think you need let out to feel better
Distribution: Debian, Red Hat, Slackware, Fedora, Ubuntu
Posts: 13,602
Rep:
I explicitly asked for off topic and unconstructive posts to stop. Posts that do not follow this are now resulting in one day bans. Further violations will result in longer bans.
To be fair it was off topic as soon as it was created. Slackers tend to have a good idea whether the BDFL is going to include or not and after the topic was shut down in another thread this one started. May I suggest just deleting a thread started and trolled by people who got an answer to the question off-topic in another thread?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
