Closed cosmos72 closed 1 year ago
My initial reply, stil in #75, was:
the significant line is
err.cpp:30:7: error: no matching function for call to ‘Chars::Chars()’
and fixing it should be easy, as Chars is supposed to have a default constructor. It means that your g++ 4.9.2 did not fully understand this fragment:
class Chars : public View<char> { typedef View<char> Base; public: using Base::Base; // export base class constructors // ... };
I will rewrite it and manually list all the constructors, without the
using Base::Base
shortcut.
@jafcobend can you check if commit db405449f2b64d84f154451dcf9fb4c1be272e61 fixes this issue? Thanks :)
Well... that took a bit of work. M$ broke GitHub... but that normally wouldn't be an issue for me since I normally clone with the newer devices, merge and then build from my internal git servers. But trying to clone direct from github with an older OS failed. Anyhow... I got around that.
I first tried building from the current "master" (4b62722). Then I rolled back to the commit you specifically asked about. Both did the same thing. It compiles all the way back to deb7, but not 5. 5 does not like the move semantics:
../../include/stl/fwd.h:23: error: expected ‘,’ or ‘...’ before ‘&&’ token
../../include/stl/fwd.h: In function ‘T& lvalue(T)’:
../../include/stl/fwd.h:24: error: ‘val’ was not declared in this scope
../../include/stl/fwd.h: At global scope:
../../include/stl/fwd.h:27: error: expected ‘,’ or ‘...’ before ‘&&’ token
../../include/stl/fwd.h: In function ‘const T& lvalue(T)’:
../../include/stl/fwd.h:28: error: ‘val’ was not declared in this scope
[ ... ]
That is GCC v4.3.2. I haven't followed C++ history closely but I think the move semantics were a c++11 thing. But probably some half step between c++98 and c++11? Since deb7 can compile it and it doesn't support c++11.
Yes, move semantics is a C++11 feature, and the first g++ version that fully supports C++11 is 4.8.1.
So no wonder that g++ 4.3.2 fails to compile current master branch - it still requires several C++11 features, including move semantics. I will work to remove them in the next week(s).
What I am more interested in, is whether your g++ 4.9.2 can now compile the master branch, and from what you wrote it seems so - correct?
With V.4.9.2 (Deb8) it fails to compile. Here's the top of the error output, ending on what I believe is the relevant part:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../include -I../../include -I../../server -g -O2 -std=c++11 -fomit-frame-pointer -fno-strict-aliasing -pipe -Wall -Wshadow -Wno-uninitialized -Wno-unused -Wundef -Wcast-qual -Wcast-align -Wpointer-arith -Wwrite-strings -MT libhw_X11_la-hw_X11.lo -MD -MP -MF .deps/libhw_X11_la-hw_X11.Tpo -c hw_X11.cpp -fPIC -DPIC -o .libs/libhw_X11_la-hw_X11.o
In file included from ../../include/stl/span.h:12:0,
from ../../include/stl/vector.h:12,
from ../../include/stl/string.h:12,
from ../../server/stl_types.h:5,
from ../../server/obj/display_hw.h:19,
from ../../server/twin.h:51,
from hw_X11.cpp:16:
../../include/stl/view.h: In member function ‘View<T> View<T>::view(size_t, size_t) const’:
../../include/stl/view.h:128:45: warning: declaration of ‘end’ shadows a member of 'this' [-Wshadow]
View view(size_t start, size_t end) const {
^
In file included from ../../include/stl/vector.h:12:0,
from ../../include/stl/string.h:12,
from ../../server/stl_types.h:5,
from ../../server/obj/display_hw.h:19,
from ../../server/twin.h:51,
from hw_X11.cpp:16:
../../include/stl/span.h: In member function ‘Span<T> Span<T>::span(size_t, size_t)’:
../../include/stl/span.h:89:42: warning: declaration of ‘end’ shadows a member of 'this' [-Wshadow]
Span<T> span(size_t start, size_t end) {
^
In file included from ../../include/stl/string.h:13:0,
from ../../server/stl_types.h:5,
from ../../server/obj/display_hw.h:19,
from ../../server/twin.h:51,
from hw_X11.cpp:16:
../../include/stl/utf8.h: In constructor ‘Utf8::Utf8(trune)’:
../../include/stl/utf8.h:45:29: warning: declaration of ‘rune’ shadows a member of 'this' [-Wshadow]
explicit Utf8(trune rune) {
^
In file included from ../../include/stl/fmt.h:13:0,
from ../../include/stl/string.h:14,
from ../../server/stl_types.h:5,
from ../../server/obj/display_hw.h:19,
from ../../server/twin.h:51,
from hw_X11.cpp:16:
../../include/stl/chars.h: In member function ‘Chars Chars::view(size_t, size_t) const’:
../../include/stl/chars.h:56:46: warning: declaration of ‘end’ shadows a member of 'this' [-Wshadow]
Chars view(size_t start, size_t end) const {
^
In file included from hw_X11.cpp:58:0:
hw_x/common.cpp: In function ‘bool X11_InitHW()’:
hw_x/common.cpp:454:76: error: cannot pass objects of non-trivially-copyable type ‘class String’ through ‘...’
printk(" X11_InitHW() failed to open display " SS "\n", HW->Name);
^
Thanks for the report :)
hw_x/common.cpp:454:76: error: cannot pass objects of non-trivially-copyable type ‘class String’ through ‘...’
printk(" X11_InitHW() failed to open display " SS "\n", HW->Name);
^
The compiler is right in rejecting that line, I'll fix it. Strange that newer compilers don't complain.
LOL! Unless its an M$ compiler they usually are right. Even then the compiler makes the rules... so you can't argue with them. :))
It is interesting the newer compilers are letting the feature leak in. Are you specifying the c++11 standard at compile time? I'm just curious if they are letting the new features in when told not to.
@cosmos72 I wanted to post an amusing side-effect of running TWIN. I'm posting this comment here because its slightly related and I have no other way to share this with you.
One of my long running console programs that is currently being run in TWIN is a simple "toy" that reads /proc/stat
and outputs the 8 LSbs of the total CPU usage counter on 8 LEDs on a panel. I've been wondering why this always gets really slow when I move my program from a VNC served session to a TWIN one. I was going to look into this slowness when it hit me! ::ouch:: Its NOT slow! Its FAST!
The display is moving slower because the CPU counter is turning slower. Its turning slower because TWIN is WAY less overhead! Ie. faster! :-D I watched it to prove I could count off each bit in the count. And sure enough it goes slowly through a 0-255 count and then starts again. Headless VNC is much busier!
Its a shame your sticking with C++11. These devices won't be able to run any of the new code. But I think the version I'm currently running is fully functional. Although there may be something odd with SIGHUP... I need to look into that.
@jafcobend no way I will feel ashamed for using C++11 until now, sorry ;) It made code much easier to write.
Anyway, I have removed all C++11 features in commit 1e9863223b1b192b2a1fb889ef76ec923bba1a5e, and now all .cpp files successfully compile with -std=c++98
- at least using recent g++ versions.
Can you try compiling current, unmodified master (1e9863223b1b192b2a1fb889ef76ec923bba1a5e) with g++ version 4.9.2, and possibly with other old C++ compilers, and post the results?
Thanks
Hey I get it!! I honestly do. As I stated in my other post:
IMO C++11 is the minimum that C++ should be.
Meaning: that the C++11 standard starts to really pull the language together and it begins to almost work. C++11 should be v1.0. But it wasn't.
The problem is "reality": older hardware < C++11. This is just a sad fact. Across my hobbies and all my professional clients' servers I only have a couple of machines that can compile C++11. And some of my personal gizmos I have no intention of getting rid of, like my PocketCHIP: .
Well... at least not until smoke starts seeping out of it. ;-) And as you stated I'm locked in by: only one kernel available and the company died. I do have a couple of spare brains for it.
In short, for me C++11 isn't an option for TWIN. I must keep it alive prior to C++11. ;-) And C++98 is way better at object oriented stuff then 'C'. :))
Tests coming right up...
Hey I get it!! I honestly do. As I stated in my other post:
IMO C++11 is the minimum that C++ should be.
Meaning: that the C++11 standard starts to really pull the language together and it begins to almost work. C++11 should be v1.0. But it wasn't.
The problem is "reality": older hardware < C++11. This is just a sad fact. Across my hobbies and all my professional clients' servers I only have a couple of machines that can compile C++11. And some of my personal gizmos I have no intention of getting rid of, like my PocketCHIP: .
Well... at least not until smoke starts seeping out of it. ;-) And as you stated I'm locked in by: only one kernel available and the company died. I do have a couple of spare brains for it.
In short, for me C++11 isn't an option for TWIN. I must keep it alive prior to C++11. ;-) And C++98 is way better at object oriented stuff then 'C'. :))
Tests coming right up...
Ahhh that makes sense now. I was a backer for that and still have one of my chips. I had twin running on it but i compiled it on my Odroid XU4 and transfered it over. Doing a Make -j 8 on a 2ghz processor verses make -j 1 on a 800mhz processor.
Also i have a similar kernel limitation on my Odroid U2 since that is now EOL, though i was able to get ARRRCCCHHH on it, it has some graphical issues. I havent compiled TWIN on that.
Thanks for posting and testing :)
The results are:
=== g++ v4.3.x (Deb5), 4.6.x (Deb7), 4.9.x (Deb8)
dl.cpp: In function ‘Chars DlCode2Name(uldat)’:
dl.cpp:116:12: error: could not convert ‘(const char*)"term"’ from ‘const char*’ to ‘Chars’
dl.cpp:118:12: error: could not convert ‘(const char*)"socket"’ from ‘const char*’ to ‘Chars’
dl.cpp:120:12: error: could not convert ‘(const char*)"rcparse"’ from ‘const char*’ to ‘Chars’
It does compile on v8.3.0 (Deb10).
Thanks :)
We're getting near - the errors in dl.cpp
should be fixed in commit d4d599ccf5b17df32acaed944755a2364534efba
And we're done! All 5 compile/arch versions compiled without a problem... I wonder if they run? I'll have to test that later.
-j8
on a 2GHz processor would be preferable to native compiles on the CHIP. But it was 1GHz. :-) The Raspberry 2b was 700ish GHz. That's the slowest SBC I've toyed with. The amusing thing: the CHIP out compiles my RISC-V 64bit @ 1.2GHz 10:1! Talk about painful compile times! =-O And until I acquire something better than the Allwinner D1 there is no hope for speeding it up. :-/
Good! Then I'll close this issue. If you find runtime bugs, feel free to open a new issue (or issues) describing them.
Thanks! Will do.
@jafcobend reported the following in issue #75: