I'm testing on FreeBSD 12.0 r332889 but I guess it could be reproduced on any version.
It also fails on 10.4. I got it to compile with USES= compiler:c++11-lang in the Makefile and with clang50. It does not compile with clang60. With clang69 a lot of errors like ./ref.h:22:15: note: expanded from macro 'null' :#define null (*(class null_ref *)0)15: note: expanded from macro 'null' #define null (*(class null_ref *)0) ^~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~ wmapp.cc:652:39: warning: binding dereferenced null pointer to reference has undefined behavior [-Wnull-dereference] if (TEST_GRADIENT(logoutPixbuf == null)) ^~~~ ./ref.h:22:15: note: expanded from macro 'null' #define null (*(class null_ref *)0) ^~~~~~~~~~~~~~~~~~~~ ./ypaint.h:36:30: note: expanded from macro 'TEST_GRADIENT' #define TEST_GRADIENT(Cond) (Cond) ^~~~ wmapp.cc:654:43: warning: binding dereferenced null pointer to reference has undefined behavior [-Wnull-dereference] if (TEST_GRADIENT(switchbackPixbuf == null)) ^~~~ ./ref.h:22:15: note: expanded from macro 'null' #define null (*(class null_ref *)0) ^~~~~~~~~~~~~~~~~~~~ ./ypaint.h:36:30: note: expanded from macro 'TEST_GRADIENT' #define TEST_GRADIENT(Cond) (Cond) ^~~~ wmapp.cc:656:41: warning: binding dereferenced null pointer to reference has undefined behavior [-Wnull-dereference] if (TEST_GRADIENT(menubackPixbuf == null)) ^~~~ ./ref.h:22:15: note: expanded from macro 'null' #define null (*(class null_ref *)0) ^~~~~~~~~~~~~~~~~~~~ ./ypaint.h:36:30: note: expanded from macro 'TEST_GRADIENT' #define TEST_GRADIENT(Cond) (Cond) ^~~~ wmapp.cc:658:40: warning: binding dereferenced null pointer to reference has undefined behavior [-Wnull-dereference] if (TEST_GRADIENT(menuselPixbuf == null)) ^~~~ ./ref.h:22:15: note: expanded from macro 'null' #define null (*(class null_ref *)0) ^~~~~~~~~~~~~~~~~~~~ ./ypaint.h:36:30: note: expanded from macro 'TEST_GRADIENT' #define TEST_GRADIENT(Cond) (Cond) ^~~~ wmapp.cc:660:40: warning: binding dereferenced null pointer to reference has undefined behavior [-Wnull-dereference] if (TEST_GRADIENT(menusepPixbuf == null)) ^~~~ ./ref.h:22:15: note: expanded from macro 'null' wmframe.cc#define null (*(class null_ref *)0) ^~~~~~~~~~~~~~~~~~~~ :./ypaint.h:36:30: note: expanded from macro 'TEST_GRADIENT' 2227#define TEST_GRADIENT(Cond) (Cond) ^~~~ wmapp.cc:664:41: warning: binding dereferenced null pointer to reference has undefined behavior [-Wnull-dereference] :21 if (TEST_GRADIENT(listbackPixbuf == null) && ^~~~ :./ref.h:22:15: note: expanded from macro 'null' #define null (*(class null_ref *)0)warning: binding dereferenced null pointer to reference has undefined behavior [-Wnull-dereference] WindowOption wo(null); ^~~~~~~~~~~~~~~~~~~~ ^~~~ ./ref.h:22:15: note: expanded from macro 'null' ./ypaint.h#define null (*(class null_ref *)0):36:30: note: expanded from macro 'TEST_GRADIENT' #define TEST_GRADIENT(Cond) (Cond) ^~~~ wmapp.cc:665:66: warning: binding dereferenced null pointer to reference has undefined behavior [-Wnull-dereference] (listbackPixmap = paths->loadPixmap(0, "listbg.xpm")) == null) ^~~~ ./ref.h:22:15: note: expanded from macro 'null' #define null (*(class null_ref *)0) ^~~~~~~~~~~~~~~~~~~~ wmapp.cc:668:43: warning: binding dereferenced null pointer to reference has undefined behavior [-Wnull-dereference] if (TEST_GRADIENT(dialogbackPixbuf == null) && ^~~~ ./ref.h:22:15: note: expanded from macro 'null' #define null (*(class null_ref *)0) ^~~~~~~~~~~~~~~~~~~~ ./ypaint.h:36:30: note: expanded from macro 'TEST_GRADIENT' #define TEST_GRADIENT(Cond) (Cond) ^~~~ wmapp.cc:669:70: warning: binding dereferenced null pointer to reference has undefined behavior
I does not tested functionality, I made only quick look into it.
The port builds fine on some release/architecture tuples: http://beefy5.nyi.freebsd.org/data/latest-per-pkg/icewm/1.3.8_3/103i386-default.log http://beefy6.nyi.freebsd.org/data/latest-per-pkg/icewm/1.3.8_3/103amd64-default.log http://beefy5.nyi.freebsd.org/data/latest-per-pkg/icewm/1.3.8_3/104i386-default.log http://beefy6.nyi.freebsd.org/data/latest-per-pkg/icewm/1.3.8_3/104amd64-default.log http://beefy10.nyi.freebsd.org/data/latest-per-pkg/icewm/1.3.8_3/111i386-default.log http://beefy9.nyi.freebsd.org/data/latest-per-pkg/icewm/1.3.8_3/111amd64-default.log
Created attachment 193026 [details] Force gnu++98 mode for icewm Try this patch, which sets the C++ language standard to gnu++98. Even though there are many warnings, icewm should compile just fine. For me, it also starts up and run, though I only tested it very lightly.
Created attachment 193027 [details] Fixes the compile errors on 12.0-CURRENT (amd64) Some fixes to the source to compile with the latest compiler on 12-CURRENT #8 r332738M: Thu Apr 19 04:00:22 CEST 2018 -> clang 6 I just compile tested it. Did see the other patch to the Makefile just a moment ago. I don't have a preference for this or that patch.
@Jan Thanks for stepping up on this while I was away! @All Please see bug #227951 , where I've squashed all the remaining errors on this. Thanks, again! --Chris
(In reply to Chris Hutchinson from comment #6) So what is fixed? The reference to another issue is recursive to this issue. And I don't see a commit in the icewm port since March. Please enlighten me. :-) Regards, Ronald.
(In reply to Ronald Klop from comment #7) > (In reply to Chris Hutchinson from comment #6) > > So what is fixed? > The reference to another issue is recursive to this issue. > And I don't see a commit in the icewm port since March. > > Please enlighten me. :-) > > Regards, > Ronald. Hey, Ronald! After checking the links in this thread/pr now, I'd have to say I'd be confused too. :-) I submitted a patch in bug #228317 that should explain it all. HTH ! --Chris
(In reply to Chris Hutchinson from comment #8) > (In reply to Ronald Klop from comment #7) > > (In reply to Chris Hutchinson from comment #6) > > > > So what is fixed? > > The reference to another issue is recursive to this issue. > > And I don't see a commit in the icewm port since March. > > > > Please enlighten me. :-) > > > > Regards, > > Ronald. > Hey, Ronald! After checking the links in this thread/pr now, > I'd have to say I'd be confused too. :-) > > I submitted a patch in bug #228317 that should explain it all. > > HTH ! > > > --Chris Oh, and of course bug #228317 will need to be committed before any good comes of it. ;-)