nobodino ( and worsel ) --

I follow worsel's Slackware from Scratch and X11 Thread because I find it interesting, especially the scripts that you and worsel have attached.

I've not actually tried the attached scripts myself, but AFAICT, it seems like Y'All have come a long way toward actually being able to rebuild Slackware from Scratch and from what I've read, you and worsel have been successful by testing one another's work and providing feedback

It also seems that if the OP were to redirect 'All the Energy Expended in this Thread' at actually rebuilding all the Slackware Packages from the Official SlackBuilds while documenting issues and resolutions and providing feedback as you and worsel have been doing, they would be a long way toward achieving their goal of being able to rebuild Slackware from the provided SlackBuild Tree.

Anyhow ... my $0.02 worth ... thank you for adding to THIS thread.

-- kjh

5 members found this post helpful.

to understand how many packages don't build properly, see the enclosed diff between slackware-current and SFS on 15/09/2017.
Not every package has been compiled, some need patches. I wasn't able to build very few of them, less than 5.

Attached Files

diff.txt (10.9 KB, 46 views)

2 members found this post helpful.

Except that is what I said, just sentence structure different. I stated that Pat and team, don't guarantee they will recompile.
What are we saying differently?

Those who don't support the team, usually end up on the bench, regardless of their talent. Attitude toward the game and contribution to the team are what make the difference in a winning team or a loosing team. Begin aware of your environment and what you have the power to change, and accepting what you can not change are the difference between enjoying life and thinking life is falling all around you. Just thought I'd add some more psychological aids to this conversation, since it clearly has gone off topic from the original post. BTW..Who's on first and Why is in left field. :-)

You said the team compiles everything at release time and that all sources will compile when a new release is made. Neither is true. It is not just new versions of the sources that may not compile, it is the versions from the -stable release as well.

1 members found this post helpful.

This is not a discussion about switching compilers, but about recompiling packages when gcc is patched to prevent (or at least minimize) the attack vectors for Spectre (and maybe Meltdown... I haven't kept up enough with it) and the releases that will come with that patching. To take advantage of those changes, programs need to be recompiled to use it. Once that gcc version makes it to Slackware, any newly compiled programs will have the benefit of minimal attack vectors, but any of the older ones are still vulnerable (to whatever degree they were vulnerable). The older binaries will still work, but they'll be vulnerable.

What you mention above would be my argument prior to the announcement of Meltdown and Spectre, but with this news, it is well-known that once gcc puts out newer versions that help protect against these threats, that programs will only be protected if they're recompiled. This could lead to the whole distribution being recompiled.

If that does end up happening, I believe that Pat is more than capable of fixing broken packages (as he has done countless times in the past) or finding alternatives if the older packages need to be removed. What I don't believe is that this is a reason to make sure Slackware packages can be recompiled at any given time, since what users do to their machines is on them. If they need a program recompiled, it's on them to figure out how to do it.

Keep in mind, the thing I was disagreeing with was this quote:

But it isn't a broken concept. The concept is that they package the sources as used to create the package. When they need to recreate the package, they'll do what needs to be done to compile it. Just because you don't agree with the concept doesn't mean it is broken.

Unless Pat is overriding the defaults (I didn't see it anywhere), gcc7 uses gnu++14, which is their dialect of -std=c++14. Slackware 14.2's gcc5 used gnu++98, which is their dialect of -std=c++98. According to the man pages for gcc in 14.2 and -current, both of these are the defaults of those gcc versions.

But in doing a quick check using my very limited knowledge on the matter, gcc -dM -E - < /dev/null | fgrep -i stdc_version for both 14.2 and -current show 201112L (although, I just extracted the gcc7 package onto my 14.2 install and ran the gcc-7.2.0 binary manually, so it's possible it pulled stuff from my installed gcc), which I think indicates both are using c++11 standards (feel free to correct me if I'm wrong). So, if that is the case, it's been used since at least 14.2 was released.

How? Because if Pat needs to recompile the packages for security reasons, if it won't compile, he'll find a way to get it to compile... like he's been doing for the past few decades.

Your "brought information" was calling Slackware broken, which it isn't. If/When Pat recompiles all of Slackware to deal with these issues, he will recompile all of Slackware. He doesn't need to start with a working source tree to do that. nobodino and worsel have proved that. What you want is designed to be left as an exercise to you... if you want to compile a program, it is up to you to get it to work.

As has been said many times by many people, Slackware is a binary distribution, not a source distribution. If you want to compile it from source, go for it, but be prepared to run into some roadblocks.

3 members found this post helpful.

the issue is that, for example, std::string has a copy on write implementation, what seems to be a good idea in the past but turned out to be problematic, especially in a world that since 10 years or so moves more and more to parallel and concurrent programming models.
Therefore the C++ standard specifies since 2011 that CoW is not a legal std::string implementation.
Slackware compiles with explicit setting the DO_USE_OLD_ABI_AND_NOT_THE_NEW_STANDARD_ON flag.
This flag will have to be added to each build script, and maybe later removed. Or build a compiler that says per standard we use the old non standard conform C++ ABI.
Some day this will need to be solved, and this meas, provide a standard conform compiler without special don't be standard flags, and recompile all C++ based packages.
You can not mix /binaries/libs compiled with old and new ABI.
Rebuild strategies are therefore very useful.

GNU docu to this, here: https://gcc.gnu.org/onlinedocs/libst..._dual_abi.html



see above

4 members found this post helpful.

http://ftp.osuosl.org/pub/slackware/...gcc.SlackBuild:
Cheers

5 members found this post helpful.

When constructive criticism is offered politely, it's been accepted in kind.

When nonconstructive criticism is offered rudely, it's often not received well. Doubly so when the critic has repeatedly harped on a subject and rejected civil discourse.

It's not criticism that is loathed, it's how it is delivered, and the critic's subsequent willingness to discuss issues fairly and intelligently (or lack thereof).

a4z has a considerable backlog of ill-will built up, so it doesn't surprise me that folks responded harshly.

6 members found this post helpful.

I neither started rude, nor posted any wrong info. Than the thread moved like so many others, where some criticism or different ideas go, religious arguments, personal allegations, and wrong technical info.
And I react on this, this is my backlog.
But too many people here are good in having a strong opinion, but when you respond to them in the same way they become sensible.
And, you could also have written: a4z has a backlog of providing technical information and fixing wrong info people spread here See above, for example, or this thread in general.
But you prefer to ignore the info I provide and focus on the noise, mostly created by others, around. Nice from you

I'll quote a line out of your first post...

Packages are not broken just because the source cannot build new packages. The package on the install media still works perfectly fine, whether or not you can use the source to create a new package. So, yes, you posted wrong info... and the fact you stated that it is broken so matter-of-factly does come across as rude.

1 members found this post helpful.

here we go again....,.

1 members found this post helpful.

it's not broken for you, but for me. I have technical reasons why, you an opinion, that I do not share.
I like technical discussion, some prefer nearly religious stand points. And Eric freaked out, just because.
:-)

1 members found this post helpful.

The package as developed by Pat and team is not broken. You can say it is as much as you want, but it works perfectly fine as intended. And that is a fact, not an opinion. If you need to recompile the package because it isn't to your liking, then that is on you and you need to find out how to get it to compile the way you want, including, if necessary, finding patches to ensure it compiles properly.

It isn't Pat and team's job to ensure you can run custom stock packages... but they do provide you a good starting point based on how they created their package.

I really wish Ford put the turn signal arm straight out from my steering wheel column rather than angled up on my vehicle, but just because I don't like it doesn't mean it is broken. It still works as Ford intended, even if I don't like it.

2 members found this post helpful.

Hmm, that isn't what I read in my post #65. What I read is just the opposite. I never said the team compiles "everything" at release time when a new release is made. I said the team compiles from the sources included in the DVD and that no guarantee is made that compiling at a later time will be successful.

Just for giggle, would you mind quoting the post I made that statement in? If I did make that statement then I guess I didn't proof it very well before posting, or didn't state my point very well.

But hey, Who's on first and Why is in left field. So this thread can go on in to extra innings and no winner will be declared since a rain delay is expected soon.

Cheers