FTBFS on Ubuntu 13.04 (use of deleted function ‘void std::unique_ptr<_Tp [], _Dp>::reset(_Up))

[Hans Joachim Desserud]

[ 16%] Building CXX object src/CMakeFiles/widelands_all.dir/graphic/render/gl_surface_screen.cc.o
/home/user/widelands/src/graphic/render/gl_surface_screen.cc: In member function ‘virtual void GLSurfaceScreen::unlock(Surface::UnlockMode)’:
/home/user/widelands/src/graphic/render/gl_surface_screen.cc:75:18: error: use of deleted function ‘void std::unique_ptr<_Tp [], _Dp>::reset(_Up) [with _Up = int; _Tp = unsigned char; _Dp = std::default_delete<unsigned char []>]’
In file included from /usr/include/c++/4.7/memory:86:0,
                 from /home/user/widelands/src/graphic/render/gl_surface.h:23,
                 from /home/user/widelands/src/graphic/render/gl_surface_screen.h:22,
                 from /home/user/widelands/src/graphic/render/gl_surface_screen.cc:23:
/usr/include/c++/4.7/bits/unique_ptr.h:404:7: error: declared here
make[2]: *** [src/CMakeFiles/widelands_all.dir/graphic/render/gl_surface_screen.cc.o] Error 1
make[1]: *** [src/CMakeFiles/widelands_all.dir/all] Error 2
make: *** [all] Error 2

Failed when I updated it. Cleared and tried to build from scratch, but still the same error.

bzr r6662, GCC 4.7, Ubuntu 13.04.

(Interesting to see it break in a recent release :p )

[SirVer (sirver)]

Strange - this should definitely work. Or I misunderstand something completely.

Here is the docs: http://en.cppreference.com/w/cpp/memory/unique_ptr/reset

someone got an idea?

[Tino (tino79)]

Does not compile here, too:

[ 0%] Building CXX object src/CMakeFiles/widelands_all.dir/graphic/render/gl_su
rface_texture.cc.obj
c:/data/bzr/widelands/trunk/src/graphic/render/gl_surface_texture.cc: In member
function 'virtual void GLSurfaceTexture::unlock(Surface::UnlockMode)':
c:/data/bzr/widelands/trunk/src/graphic/render/gl_surface_texture.cc:231:18: err
or: use of deleted function 'void std::unique_ptr<_Tp [], _Dp>::reset(_Up) [with
 _Up = int; _Tp = unsigned char; _Dp = std::default_delete<unsigned char []>]'
In file included from c:\bin\mingw32\bin\../lib/gcc/mingw32/4.7.2/include/c++/me
mory:86:0,
                 from c:/data/bzr/widelands/trunk/src/graphic/graphic.h:24,
                 from c:/data/bzr/widelands/trunk/src/graphic/render/gl_surface_
texture.cc:22:
c:\bin\mingw32\bin\../lib/gcc/mingw32/4.7.2/include/c++/bits/unique_ptr.h:404:7:
 error: declared here
make[3]: *** [src/CMakeFiles/widelands_all.dir/graphic/render/gl_surface_texture
.cc.obj] Error 1
make[2]: *** [src/CMakeFiles/widelands_all.dir/all] Error 2
make[1]: *** [src/CMakeFiles/widelands.dir/rule] Error 2
make: *** [widelands] Error 2

[Teppo Mäenpää (kxq)]

One needs to replace "0" with nullptr. There are two instances. Then it goes away, at least in Wheezy.

Take a look at ~widelands-dev/widelands/feature-militarysite-soldier-selection/6597

(it fixes another minor bug, too, but that should be safe to merge)

[Teppo Mäenpää (kxq)]

Clarifying myself: feature-militarysite-soldier-selection/6597 fixes this bug and another minor militarysite related bug for which there are no reports yet. There should not be other changes between trunk/6662 and the above mentioned branch.

[Hans Joachim Desserud (hjd)]

I can verify this issue is resolved on Ubuntu 13.04. However, now that bug 1204612 has been fixed, 10.04 runs into a FTBFS issue which looks suspiciously familiar:
[ 1%] Building CXX object src/CMakeFiles/widelands_all.dir/graphic/render/gl_surface_texture.cc.o
/usr/include/c++/4.4/bits/unique_ptr.h: In member function ‘virtual void GLSurfaceTexture::unlock(Surface::UnlockMode)’:
/usr/include/c++/4.4/bits/unique_ptr.h:350: error: deleted function ‘void std::unique_ptr<_Tp [], _Tp_Deleter>::reset(_Up) [with _Up = int, _Tp = uint8_t, _Tp_Deleter = std::default_delete<uint8_t []>]’
/home/ubuntu/widelands/src/graphic/render/gl_surface_texture.cc:231: error: used here
make[2]: *** [src/CMakeFiles/widelands_all.dir/graphic/render/gl_surface_texture.cc.o] Error 1
make[1]: *** [src/CMakeFiles/widelands_all.dir/all] Error 2
make: *** [all] Error 2

r6666. (12.04 and later releases seem to be fine, though (https://launchpad.net/~widelands-dev/+archive/widelands-daily/+packages))

[SirVer (sirver)]

Strange - this is precisely what Tino fixed. Can you verify that it is still in current trunk?

If yes, then my theory is that here the -Dnullptr=NULL hack is used - because the gcc version is low enough or so? but NULL is type int, while here really a nullptr type is needed. Can you try without the -Dnullptr=NULL hack?

[Jens Beyer (qcumber-some)]

I tried it in my new lucid test system.

Yes, -Dnullptr=NULL is used, as it is gcc 4.4
If you remove -Dnullptr=NULL, the compile error changes to "nullptr was not declared in this scope", as expected.

[SirVer (sirver)]

well, you can go bonkers and try:
-Dnullptr="reinterpret_cast<void*>(NULL)"

maybe that will help :).

[Jens Beyer (qcumber-some)]

invalid conversion from void* to int* in wlapplication.h:172...

[Teppo Mäenpää (kxq)]

To me this sound like if there were no bugs in widelands, but simple a too-old-compiler issue with Ubuntu 10.04.

If so, then what would you think if we just made a ubuntu-lts-compatibility branch, where the problematic parts could be hacked so that the code somehow compiles? This approach would allow more dirty hacks to be used, as the target would not be program develompment but just to get a final release for a soon-obsolete OS version.

Canonical has actually stopped supporting the desktop version of Ubuntu 10.04 LTS already, so I would guess that Widelands does not have to support it forever either?

I would like that you senior guys make all decisions here, but please consider the above.

Server-side of Ubuntu 10.04 is supported till 2015 I think.

[Jens Beyer (qcumber-some)]

For the time being, I stopped Launchpad from building lucid packages to avoid sending whine mails every day... the last published lucid package should remain there, I think.

[SirVer (sirver)]

I have a hard time addressing how much backwards support we should or should not offer for Widelands. Having support for a Linux version that is no longer supported on the desktop seems too much to me, but I have no idea how linux users use their systems these days.

Jens, if not supporting Lucid server is acceptable, can we not set this to fix committed? Why should we provide more support than canonical themselves?

[SirVer (sirver)]

And you could try with - c casts are more permissive:
-Dnullptr="((void*)NULL)"

[Jens Beyer (qcumber-some)]

Same problem as in comment #9.

I can not decide on if we should support backwards compatibility for Lucid or not.

In earlier times, widelands tried to keep "low profile" on the requirements, for playing and for building.

We seem to have left this track now, at least partially, widelands still needs very low system resources (except RAM), but we are now on OpenGL as default and need C++11 to build. I guess, dropping support for an unsupported system is then only a logical decision....

[Jens Beyer (qcumber-some)]

Additional thoughts... The LTS systems are primarily targetting people which don't want (or can not) update to latest developments. The former should probably be mostly companies (which widelands does not target), the latter probably mostly due to exotic hardware (which will probably have problems with the updated requirements anyway - additionally, you can not really support everyone, especially not if those people are anonymous - of course, we would try to support if they ask for it).

[Teppo Mäenpää (kxq)]

When I first grabbed widelands, the latest release (then 16) did not compile on Debian Stable (then Lenny), and I found it annoying. Supporting older releases has some value. Of course a project like Widelands do not have to support anything, and I think it would be silly if we would start retreating from c++11 just because of an old version of a Linux distribution.

From my point of view, I would consider making a special branch of widelands tree and hard-code some NULL's in place of the nullptr's or whatever it takes, to make the newest thing to compile it in Ubuntu 10.04LTS. If hacking like that was successful and the needed modifications were such that the branch would still be release-quality, and network-play-wise compatible with trunk, I would then hint about the 10.04 downgrade patch to whoever makes Ubuntu releases of build 18 and after that drop 10.04. However:

- I do not have Ubuntu 10.04 LTS installed anywhere. If the installation media is still available, I could consider setting up a virtual machine but that would still be some work. It sounds that some of you have all this done already.

- Would you senior guys make the decisions? I do not really know what kind of people run ubuntu LTS and whether this would be worth the trouble.

[Hans Joachim Desserud (hjd)]

(Quotes are marked with the comment they reference, though some parts reply to other comments not explicitly mentioned)

In short, I think it would be acceptable to drop support for 10.04 now that the Desktop version has reached end of life [1]. While I to some degree would like to keep it (in the spirit that Widelands should build and run on anything), I don't think we should break our backs with efforts to support an older system when a clear upgrade path and currently supported systems are available. Especially since I expect there would only be a few users which would really benefit from this. I have no numbers to back this up, but I would assume most people run LTS releases have made the move to 12.04 already. (For future reference, note that 12.04 will have five years support also for Desktop releases.)

"The LTS systems are primarily targetting people which don't want (or can not) update to latest developments. The former should probably be mostly companies (which widelands does not target), the latter probably mostly due to exotic hardware" (#15)

Ok, in case someone reading this doesn't know; Ubuntu has a new release every sixth months, and every second year they have a Long Term Supported release (ie. every fourth release). There was recently some discussion regarding the normal (in-between) releases, ranging from how to deal with the overhead of supporting multiple releases in parallell to suggestions regarding doing a rolling release. One of the results was that the support period of normal releases was reduced from 18 to 9 months, in order to free up resources to focus more on the LTS. And while I agree that companies are an obvious target of the LTS releases, they are also intended for regular users who want to use their systems and not necessarily upgrade everything every six months. I'm also getting the impression that the normal releases might be shifting towards being somewhat more targetted towards developers/enthusiasts/etc.

My goal as mentioned above would be that Widelands can build and run anywhere. The version packaged in various distros (not limited to Ubuntu) is usually not upgraded in existing releases, but rather the new version is added to the development release, and eventually ends up in the hands of users when they upgrade. A backport can be requested though, which was done to get build17 available in 12.04 even though it was released too late for the deadline to be packaged in the official archive.

I realize it might sound contradictory to talk about LTS release with stable, proven, older software and still wanting to run the latest version of Widelands. Being a game, though, it makes sense that the majority who wants to play online will be running the latest release, so if you are stuck with an older one from the package archive of your operating system, you will have less people to play with. The version available in 10.04's package archive is build14, and I seriously doubt you would find many to play against. (You would also be missing out on tons of new features, graphic and bug fixes.) In these cases, users may either build Widelands themselves or use a service such as the stable release PPA to play the...

[SirVer (sirver)]

OOOOkay, long post incoming. I suggest a way forward way down at the end.

> In earlier times, widelands tried to keep "low profile" on the requirements, for playing and for building.
> We seem to have left this track now, at least partially, widelands still needs very low system resources (except RAM), but we are now on OpenGL as default and need C++11 to build. I guess, dropping support for an unsupported system is then only a logical decision....
I see this very differently :). Widelands used to need a lot of CPU power, so you needed a very beefy system to play it on larger map. the move to opengl (which is present in every device I own, some of which are older than 5 years) reduced the need to have a beefy computer - a simple one with opengl will do. Same for RAM: we always needed tons of it and in my last computer, running widelands took 25% ram (~1gig). Now with all the work we did for RAM usage, it only takes ~ 750 MB - this is a mere 5% of my current machine (which has more RAM too). So I feel that Widelands even got more usable on 'older' devices and we effectively dropped the requirements between b17 and b18. But they did change of course.

> From my point of view, I would consider making a special branch of widelands
I would advise against this. Keeping two branches in sync and compiling when you have to constantly apply new patching to the second one is a lot of work, not fun and error prone. I think not supporting is a better choice here - but if you want to do this, I will not stand in your way of course :).

[SirVer (sirver)]

sorry, hit the post comment button by accident :(.

> Would you senior guys make the decisions? I do not really know what kind of people run ubuntu LTS and whether this would be worth the trouble.
The decision must be found together. The term "senior" feels also strong for Widelands - the people that make decisions are the ones that are currently working on the game. The more you work on the game, the higher your impact in decision making (roughly :)).

> (in the spirit that Widelands should build and run on anything)
I feel moving to c++11 will actually help here - even though it might not feel like it right now. For example I recently learned that we are using POSIX methods which are actually not available for Windows (it is just by luck that mingw implements them and that Visual Studio provides compatible functions). The same goes for the c++ standard: we never explicitly stated which standard we used, but we mixed and matched pretty freely between them. For the future, I would love if we could just say: We support c++ 11.

----
Summary: I read a strong agreement in this thread that we can drop support for lucid now, but should keep support for 12.04 as this will be around for a while. I think this is a reasonable choice. This means that we will introduce the cool and fancy new c++ features significantly more slowly than I wished, but some of the more valuable stuff we already have now.

Setting to fixed committed then. Jens, could you delete the lucid build receipts?

[Jens Beyer (qcumber-some)]

There is already no lucid build anymore. The last package built for lucid (bzr6655) is still around on the ppa - should I remove this or keep it around?

[dershrimp (dershrimp)]

I am using lucid. Upgrade to 12.04 makes all processes quite slow. So I "downgraded" again like half a year ago. I do not have any speed problems playing widelands on all maps (small, large, lots of players, few players) neither again cpu nor LAN or via internet. I would be very grateful to have the possibility to play versions > 6655 and participate in the 2013 tournament. Cheers.

[Jens Beyer (qcumber-some)]

Just to add that I tried it and failed... The llvm/clang package on lucid also seems to be out of date and does not like some of the c++11 statements in the code. I can't name them now but I could, if someone is interested. So, using clang as substitute for lucid also does not seem to work (though I would think it would be good if hjd or someone else with a lucid system could check that too, 4 eyes is better than 2).

[SirVer (sirver)]

> There is already no lucid build anymore. The last package built for lucid (bzr6655) is still around on the ppa - should I remove this or keep it around?

I'd say kill it. For people still using it it will fail more verbosely then and we hear from them.

dershrimp, lucid is no longer supported on the desktop. You are using an obsolete system from canonicals point of view. That's a bad idea: no security updates, no feature updates and more and more software will not run on this anymore. I am sorry, updating seems like a good idea to me.

[dershrimp (dershrimp)]

SirVer, I found a way to do it. Changed the OS to Xubuntu. There I can use 12.04 without problems.

[Hans Joachim Desserud (hjd)]

>So, using clang as substitute for lucid also does not seem to work (though I would think it would be good if hjd or someone else with a lucid system could check that too, 4 eyes is better than 2).

Fwiw, clang on lucid fails horribly for me too.

[SirVer (sirver)]

Released in build-18 rc1.