cosmos72 / twin

Text mode window environment. A "retro" program for embedded or remote systems, that doubles as X11 terminal and text-mode equivalent of VNC server
Other
651 stars 38 forks source link

Compile error using (intentionally old) g++ 4.9.2 #77

Closed cosmos72 closed 1 year ago

cosmos72 commented 1 year ago

@jafcobend reported the following in issue #75:

Since G++ is the only compiler I've ever used that can spit out 3,000 lines of error for a missed bit of punctuation I will cut the error short and only include the top of the report from my c++11 enabled compiler (gcc v4.9.2):

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../include -I../../include -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 err.lo -MD -MP -MF .deps/err.Tpo -c err.cpp  -fPIC -DPIC -o .libs/err.o
In file included from ../../include/stl/chars.h:12:0,
                 from err.cpp:14:
../../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 err.cpp:14:0:
../../include/stl/chars.h: In member function ‘Chars Chars::view(size_t, size_t) const’:
../../include/stl/chars.h:45:46: warning: declaration of ‘end’ shadows a member of 'this' [-Wshadow]
   Chars view(size_t start, size_t end) const {
                                              ^
err.cpp: At global scope:
err.cpp:30:7: error: no matching function for call to ‘Chars::Chars()’
 Chars Errstr;
       ^
err.cpp:30:7: note: candidates are:
In file included from err.cpp:14:0:
../../include/stl/chars.h:18:15: note: template<long unsigned int N> constexpr Chars::Chars(const char (&)[N])
   using Base::Base; // export base class constructors
               ^
../../include/stl/chars.h:18:15: note:   template argument deduction/substitution failed:
err.cpp:30:7: note:   candidate expects 1 argument, 0 provided
 Chars Errstr;
       ^
In file included from err.cpp:14:0:
../../include/stl/chars.h:18:15: note: constexpr Chars::Chars(const char*, size_t)
   using Base::Base; // export base class constructors
               ^
../../include/stl/chars.h:18:15: note:   candidate expects 2 arguments, 0 provided
../../include/stl/chars.h:18:15: note: Chars::Chars(const Span<char>&)
../../include/stl/chars.h:18:15: note:   candidate expects 1 argument, 0 provided
../../include/stl/chars.h:18:15: note: Chars::Chars(const Vector<char>&)
../../include/stl/chars.h:18:15: note:   candidate expects 1 argument, 0 provided
../../include/stl/chars.h:21:13: note: constexpr Chars::Chars(const Base&)
   constexpr Chars(const Base &chars) : Base(chars) {

Note the -std=c++11 to enable that version.

cosmos72 commented 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.

cosmos72 commented 1 year ago

@jafcobend can you check if commit db405449f2b64d84f154451dcf9fb4c1be272e61 fixes this issue? Thanks :)

jafcobend commented 1 year ago

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.

cosmos72 commented 1 year ago

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?

jafcobend commented 1 year ago

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);
                                                                            ^
cosmos72 commented 1 year ago

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.

jafcobend commented 1 year ago

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.

jafcobend commented 1 year ago

@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.

cosmos72 commented 1 year ago

@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

jafcobend commented 1 year ago

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: 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...

Mirppc commented 1 year ago

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: 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 :)

jafcobend commented 1 year ago

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).

cosmos72 commented 1 year ago

Thanks :) We're getting near - the errors in dl.cpp should be fixed in commit d4d599ccf5b17df32acaed944755a2364534efba

jafcobend commented 1 year ago

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. :-/

cosmos72 commented 1 year ago

Good! Then I'll close this issue. If you find runtime bugs, feel free to open a new issue (or issues) describing them.

jafcobend commented 1 year ago

Thanks! Will do.