I didn't realize this was the case in GCC. I know commercial compilers are notorious for having extended stuff in it. So if you want portable code, you don't use that stuff. I guess using GCC's extended syntax is quite common then. Even one deprecated kernel module, speedstep-centrino, is apparently using GCC's extended syntax as it won't compile under Slackware 14.1 and 4.0.5 kernel.

https://gcc.gnu.org/onlinedocs/gcc-5...l#C-Extensions
Linux kernel developer like some of them, that's way clang did not work out of the box, while standard complaint code does

c++ has also some extensiosn
https://gcc.gnu.org/onlinedocs/gcc-5...02b-Extensions

of course msvc does also a lot of non standard stuff that's why it is sometime so hard to port windows code to Linux, even if there is no special hardware thing involved


ad your speedstep-centrino, I am not sure that really the extensions are the reason, could be it used internal kenrelstuff that has changes, because usually gcc is very consistent

Im am very surprising by all above declarations...

There are different distributions being able to be self compiled from A .. Z. And beeing distributed as well 32 as 64 bit in all forms: binaries as well as sources to compile and only to do that! For me, Slackware was know as THE probably main sources supplyers yet at the time were not already present! Divers distributions are proud to say that they are derivates of Slackware! someone includes Slack in only minimal changed form to show that in the own distributions name! And Slackware did a long time help other to easily accede to Linux (for ex. within an IBM-DOS-system!).

If I understand now what I read above, were Slackware only a polluter of the environment as Slackware did sollicitate the user to burn absolutely not needed CD landing never used to domestic garbage! It can not be true...

Please read this actual message on the forum of an other distribution distributed to install through 3 different ways

- compiling all an not necessary using the own distribution entirely from sources: only bash has to be absolutely the same, some options of bash are tricky, in some kind of computer aided compilation / half automatic compilation

- installing a base in a chroot starting in an existent linux (same condition concerning bash)

- installing using with a mini-ISO (about the same as the base for those not having the chance to offer an adequate bash) from Web and binaries from the site

claming now:

Yes, you are reading right: ONE mann produces since years one as complete distribution (a second mann did elaborate the binaries for the more or less complete KDE), often alone ...

... and you advise against attempting to do only a small part of the same work seriously?

@oui:

I fail to understand what your post brings to the discussion.

Let's remind the conclusions so far:

• Technically it is possible to build Slackware from scratch. This has already been done.
• Doing that for each incoming stable release is something that the Slackware team doesn't intend to do, because that has no clear benefit that would worth the time needed.

Furthermore your comparison with saravane is not convincing at all.

• You just copied a post you have found here
• But actually the distribution came from LFS and BLFS with the help of a team as stated there.
• The maintainer, tnut, doesn't claim to rebuild everything from scratch as far as I know.

Not at all. On the contrary many of us thanked and congratulated nobodino.

So, what is your point?

2 members found this post helpful.

I just compiled some old serial port radio control programs and they both work. The programs are amfm from 2007 and pcfm from 1998. amfm works flawlessly while pcfm does work, but generates these error messages on the console:

Its possible that the errors are happening due to me running it in it's source directory rather than having it installed normally. pcfm also has a GUI frontend that is written in Tcl/Tk that works flawlessly. I did have to make some minor changes as it was looking for some old version of things. This does drive your point home.

I was actually thinking of the old Borland C/C++ compilers for DOS. LOL.

Could be. If I ever need it in Slackware 14.1, I'll look into it. For now I don't so I just removed it. The Laptop I use with Slackware 13.37 does need speedstep-centrino, so I'll just keep it at 13.37 for the time being.

As for the main discussion of this thread, I've considered compiling the whole Slackware source. So far I have only compiled certain things for various reasons. Maybe I'll do it sometime for the heck of it.

Just a quick, "mindless" answer, correct me if I miss the point but... Beware not to confuse C standard, GCC (compilers) extensions AND C standard library, which are 3 different things. Yes the cstdlib is tightly coupled with the compiler, but also tightly coupled with the target platform... And there are chances that the ioctl error is because of a bad standard library, not at all a "syntax" problem...

Cheers

Garry.

that the Slackware team doesn't intend to do it is obviously correct:

but I think the second part of your sentence is part of the discussion here, because for some of us of course it has some clear benefit to be able to rebuilt a distribution.

so I think the correct formulation could also be
(and this includes as many speculation as you have written)
Doing that for each incoming stable release is something that the Slackware team doesn't intend to do, because they keep on doing it the way they do it since ever, base on a time where compiling was an expensive job.

(this is no speculation)
So Slackware ships a distribution with binaries that are impossible to reproduce without going back in time.

(this is, not only, my opinion)
So basically Slackare ships source that can not be build to the binary it runs and this is clear buggy.

There is no contradiction. The Slackware team not rebuilding everything all the time does not prevent us from rebuilding everything if we so choose.

There is clear benefit to being able to build a bridge from scratch, but that doesn't mean we should tear down all bridges and rebuild them every weekend. It is better to keep known-good bridges intact, and build a new bridge only when needed.

1 members found this post helpful.

ok, so what it the tc
I am sure you did understand what I was talking aobut and that and are just playing a troll

well, ok, welcome to the club of experts that try to bring an impropper Allegorie, now you show us that you did not understand what we where talking about, sory for thinking you are just a troll

@a4z: I am sure that you can do better than just calling trolls people who disagree with you.

Also, as you have already stated your opinion many times I am afraid that posting it again won't significantly enhance our understanding of it.

Have a good day.

1 members found this post helpful.

@a4z: I understood what you were saying, but what you were saying was simply incorrect.

I understand you don't believe rebuilding packages introduces risk, but leaping from this to "Slackware devs avoid recompilations because once upon a time compiling was expensive, and they are stuck in their ways" is not a valid train of reasoning.

ok, you missed bringing a technical reasons for the advantage of the Slackware way which is not opinion based or brought with some non fitting story.
very possible simply because there is non, there is the habit to do so as it is and this is just as Slackware does it, without any advantages (but with the fact that some packages might be binary only and might not compile as they are shipped, which is at least one disadvantage that is provable)
that's it, not more and less, and every statement that comes without any prove but with stupid stories it trolling or showing hard core ignorance.
and sorry Didier, possible I could do better, but people that sell their opinions as fact and spread therefore rumors, what you btw also did, steal sometimes my nerves

Very disappointed again in one or two people here, because they mix their own beliefs with Slackware's way of doing things and decide that the distro should yield.

Once again. Slackware ships the source which was used to compile that package. No more and no less. Slackware is a "binary" distro, not a "source" distro. There is no requirement that the shipped sources must be able to recompile the package at any given time in future. It is a nice topic if you are looking for a hobby: recompile Slackware from scratch. But it has no relevance to the distro.

4 members found this post helpful.

Yes, Eric, we know, but everyone is entitled to have an opinion, and at least sharing ideas, even if they are against the grain, so to speak, can be intriguing, enlightening, and educational even to old farts like us who think we know everything. New ways of thinking may find better ways to meld into ways and means. Better to have ideas that are fluid than stagnant.

So, building a distribution from scratch would be a new way of thinking? Eureka!

Thanks James, you made my late evening

PS I am listening the piano sonata D. 850 from Franz Schubert played by Alfred Brendel. I especially like the scherzo. In general I like the scherzos...