I'm trying to build R14.1.2 on some vintage systems.
The build log for tqt3 is filled with this error. I searched the web and not being a programmer, do not fully understand what is required for remedy. The error seems to have something to do with c++11.
R14.0.12 built fine on these vintage systems. I am presuming something has since changed.
One system has gcc 5.5.0.
I accept this might be the end of the road for TDE on some vintage systems. That's fine, but please, no street preaching about unsupported systems. I'm trying to understand the error.
Thanks.
Try replacing nullptr with 0. Nullptr is a keyword for null pointer which traditionally was written as 0 before the more specific nullptr keyword appeared.
-- Philippe M.
-------- Αρχικό Μήνυμα -------- Την 18/5/24 10:49 μ.μ., Darrell Anderson via tde-devels ο/η devels@trinitydesktop.org έγραψε:
I'm trying to build R14.1.2 on some vintage systems.
The build log for tqt3 is filled with this error. I searched the web and not being a programmer, do not fully understand what is required for remedy. The error seems to have something to do with c++11.
R14.0.12 built fine on these vintage systems. I am presuming something has since changed.
One system has gcc 5.5.0.
I accept this might be the end of the road for TDE on some vintage systems. That's fine, but please, no street preaching about unsupported systems. I'm trying to understand the error.
Thanks. ____________________________________________________ tde-devels mailing list -- devels@trinitydesktop.org To unsubscribe send an email to devels-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydeskt...
On Monday 20 of May 2024 18:05:05 Darrell Anderson via tde-devels wrote:
On 5/20/24 8:43 AM, blu.256 wrote:
Try replacing nullptr with 0. Nullptr is a keyword for null pointer which traditionally was written as 0 before the more specific nullptr keyword appeared.
I resolved this problem by adding '-std=c++11'. ____________________________________________________
The current tde-cmake macros should ensure that C++11 is turned on automatically. Now tde-cmake is installed as a separate package. I suppose you have tde-cmake installed?
Cheers Slávek --
On 5/20/24 11:59 AM, Slávek Banko via tde-devels wrote:
On Monday 20 of May 2024 18:05:05 Darrell Anderson via tde-devels wrote:
On 5/20/24 8:43 AM, blu.256 wrote:
Try replacing nullptr with 0. Nullptr is a keyword for null pointer which traditionally was written as 0 before the more specific nullptr keyword appeared.
I resolved this problem by adding '-std=c++11'. ____________________________________________________
The current tde-cmake macros should ensure that C++11 is turned on automatically. Now tde-cmake is installed as a separate package. I suppose you have tde-cmake installed?
Yes, installed, but the failure was with tqt3, which does not use cmake. The failure happened only with vintage systems. While Slackware 14.2 64-bit is declared EOL, that happened only a few months ago. GCC version is 5.5.0. Possibly that plays a role, but that is why I asked some days ago about minimal build requirements.
With the '-std=c++11' addition, I now can build tqt3 on these older systems.
As you might remember, I like tinkering with vintage systems. I accept there is a point of diminishing returns with installing modern software, but I think TDE fills a void with people wanting to keep dual core systems alive, especially since TDE has roots in KDE 3.5 from 14 years ago. I have vintage systems running in the house. I never had issues compiling 14.0.12 on these systems, so something new was introduced since.
I am using build scripts that are not robust or well tested for anything outside the most recent Slackware versions. I am ever so slowly trying to write my own build scripts to accommodate a variety of systems and Slackware releases. But I am getting old and my brain no longer works as sharp as only a few years ago.
Perhaps some TDE veterans could review the wiki to provide more helpful build requirements. For example, I notice some of the build times are the same ones I wrote on vintage systems from 14 years ago. Those build times almost look embarrassing these days. I am willing to review such changes and play my old role of devil's advocate and persnickety tech writer. :)
On Monday 20 of May 2024 19:38:09 Darrell Anderson via tde-devels wrote:
Yes, installed, but the failure was with tqt3, which does not use cmake. The failure happened only with vintage systems. While Slackware 14.2 64-bit is declared EOL, that happened only a few months ago. GCC version is 5.5.0. Possibly that plays a role, but that is why I asked some days ago about minimal build requirements.
With the '-std=c++11' addition, I now can build tqt3 on these older systems.
As you might remember, I like tinkering with vintage systems. I accept there is a point of diminishing returns with installing modern software, but I think TDE fills a void with people wanting to keep dual core systems alive, especially since TDE has roots in KDE 3.5 from 14 years ago. I have vintage systems running in the house. I never had issues compiling 14.0.12 on these systems, so something new was introduced since.
Oh, clearly, for TQt as such, there is not forced C++ dialect, because it does not use either automake (common admin module) or CMake. In R14.0.12, C++11 dialect was set as default for both automake and CMake. Together with the release R14.1.0 there is allowed to use C++11 in code. Therefore, TQt >= R14.1.0 now requires to enforce C++11 dialect if an older compiler is used.
I am using build scripts that are not robust or well tested for anything outside the most recent Slackware versions. I am ever so slowly trying to write my own build scripts to accommodate a variety of systems and Slackware releases. But I am getting old and my brain no longer works as sharp as only a few years ago.
Perhaps some TDE veterans could review the wiki to provide more helpful build requirements. For example, I notice some of the build times are the same ones I wrote on vintage systems from 14 years ago. Those build times almost look embarrassing these days. I am willing to review such changes and play my old role of devil's advocate and persnickety tech writer. :)
Overall, the requirements have not changed too much. We always try to keep the code for compatibility with older versions, because we still provide packages for older versions of distribution.
Very good changes have occurred for build times, especially for CMake if used together with ninja-build. In this case, processors with multiple cores are very well used and building can be significantly faster than it used to be in the past.
Cheers
On 5/20/24 2:08 PM, Slávek Banko via tde-devels wrote:
Oh, clearly, for TQt as such, there is not forced C++ dialect, because it does not use either automake (common admin module) or CMake. In R14.0.12, C++11 dialect was set as default for both automake and CMake. Together with the release R14.1.0 there is allowed to use C++11 in code. Therefore, TQt >= R14.1.0 now requires to enforce C++11 dialect if an older compiler is used.
Basically then my remedy is correct?
I don't mind and I am not going to make mountains out of molehills, but information like this should be in the wiki. I don't know if I still have write access to the wiki, but at my stage of relearning TDE development I am more comfortable with suggesting changes rather than presuming and writing incorrect information.
Overall, the requirements have not changed too much. We always try to keep the code for compatibility with older versions, because we still provide packages for older versions of distribution.
And I'm thankful. Some people like tinkering with old cars or furniture. I like tinkering with old computers. I even have a 486 with 16 MB of RAM still running. :) Because TDE remains quite snappy and responsive (almost frighteningly fast), I have a natural tendency to try to keep TDE running on these vintage systems. I realize that perhaps someday there will be a point of no return, but I'd like to think that day has not yet arrived. Challenging for me is finding and learning which patches to back port.
Very good changes have occurred for build times, especially for CMake if used together with ninja-build. In this case, processors with multiple cores are very well used and building can be significantly faster than it used to be in the past.
Perhaps the wiki section about build times should be deleted?
-
blu.256 -
Darrell Anderson -
Slávek Banko