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.
For gods sake! We start again with "let's add multilib" ????
At least let's wait the usual 2 years!
And NO, you can't have a multi-architecture (the real name of "multilib") GLIBC without an multi-architecture compiler.
stop trolling everywhere , i not request , i ask only.
Im not interesting in multilib , but i think ,if this package can ship with that enabled, then probably , no need "overlaping" , original packages with 3th repo packages , like alien. (with all the respects for Eric)
And , for your infomation , YES , you can have multilib, without gcc multilib , glibc is the part neede for "exec" 32bit apps , if no go build nothing, then no need gcc-32.
But i repeat , i post for "curiosity" , cause im not sure if this build option is new , or exist in other glibc releases... and what this option does.
Last edited by USUARIONUEVO; 08-02-2018 at 07:36 PM.
Is trolling to be annoyed by the forever returning struggle with multilib?
BTW, you asked, (again) I responded: you need a multi-architecture compiler to build a multi-architecture glibc. Nothing new from what I know since 20 years ago.
Last edited by Darth Vader; 08-02-2018 at 10:43 PM.
Is trolling to be annoyed by the forever returning struggle with multilib?
BTW, you asked, (again) I responded: you need a multi-architecture compiler to build a multi-architecture glibc. Nothing new from what I know since 20 years ago.
Quoted me , please, quoted my "request" to add multilib.
I see you can read , then please, understand what are you reading, and flame late, if can.
"
You are here only requesting "your interesting" updates, and flame when other user do the same...in forums ,that users are called trolls.
I never request multilib , no use wine here , i prefer ever pure 64 systems , 32 bits are in death process, slow, but in process ..
I comment one option from glibc compiling time, thinking if this can benefit or not, as example building glibc ,in a 64bit system , and making the same package to 32 bits , without start another vm , with the 32bit slackware system , thats all.
I never say "please enable that on glibc", i only comment cause im not sure if some benefit comes with this option.
Last edited by USUARIONUEVO; 08-03-2018 at 09:44 PM.
Man, this option enables right on that "multilib" feature at build time on GLIBC. I hope I was clear enough previously.
BUT, this is not enough. You need also a "multilib" compiler to build a "multilib" GLIBC, like I said already two times.
We use to name a particular feature "multilib" but its real name is "multi-architecture" aka "multi-arch" in contrast with the "single architecture" (or "pure 32bit" and "pure 64bit") which is what Patrick Volkerding do today.
Excuse me and my biasing, BUT you asked these details right on the Requests Thread, hence I suspected you of intentions about requesting it later. Later yourself accepted that you look for a way to build a "multilib" GLIBC with a pure 64bit compiler.
However even if you asked in a separate thread, I am afraid that my response happened to be the same. Because is not about flaming, but a fact:
a pure 64bit compiler (like one from Slackware64) cannot generate 32bit binaries (excluding the standalone ones, like the kernel), that's WHY you need a "multilib" one for building a "multilib" GLIBC.
Last edited by Darth Vader; 08-04-2018 at 12:17 AM.
There was added improvements for the situation when Glamor is used together with the TearFree option, and I tested that update since several days already, with perfect success.
Last edited by Darth Vader; 08-04-2018 at 12:16 AM.
At the earliest when we will see "release candidate" in the ChangeLog, in several months. And Slackware 15 will be released, as usual, when Patrick Volkerding will think it's ready, whatever will be this thread's state then.
Well I just figured out why I hosed my system the last time I tried to make a chroot. It's because I did "installpkg --root=/path/to/chroot" and not "installpkg --root /path/to/chroot".
Having installpkg work with the first syntax would be nice.
Is it desirable to have code in rc.S to only delete /etc/mtab if it is a file and not if it is a symlink to /proc/self/mounts ?
Code:
# Any /etc/mtab that exists here is old, so we start with a new one:
if [ ! -L /etc/mtab ]; then
/bin/rm -f /etc/mtab{,~,.tmp} && /bin/touch /etc/mtab
fi
I have changed rc.S like seen above and it works fine in my case but i do not know if it is enough or there are corner cases like nfs mounts and stuff.
I asked about it again 10-15 months ago and some users wanted /etc/mtab as a file due to nfs or something (i don't remember) but maybe they changed their minds since then. Is it desirable by anyone else ? Is it the right time or it is too close to 15.0 for such a change ?
Well I just figured out why I hosed my system the last time I tried to make a chroot. It's because I did "installpkg --root=/path/to/chroot" and not "installpkg --root /path/to/chroot".
Having installpkg work with the first syntax would be nice.
I use other sysntax here ..
Code:
ROOT=/path/to/chroot installpkg /path-to-pkg
Last edited by USUARIONUEVO; 08-05-2018 at 02:17 PM.
This has probably been suggested some time in the past but searching on the forums hasn't given me any results so here goes:
Splitting the L series into a bunch of other L-* series? e.g. l-audio, l-x11 or even (since some have been talking about it), l-kde (and other such things) amongst other similar stuff?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
