ftbfs with gcc 4.7 if not including <unistd.h>

Bug #976551 reported by Hans Joachim Desserud on 2012-04-08
This bug affects 3 people
Affects Status Importance Assigned to Milestone

Bug Description

Mentioned by some unknown hero earlier today on IRC:
12:25 widelands_8 i needed to place #include <unistd.h> in main.cc , when compiling v 17.1 under archlinux

Since I couldn't remember running into any problem like this I first attempted to build build17 rc1, then latest development version on Arch. And yes, I was unable to compile wl from scratch without including the library mentioned. (See below for error message)

Since it's not that long since I compiled wl from scratch on it, I think this is a problem which appeared recently. My suspiscion/shot in the dark is whether this could be related to Arch recently upgrading to gcc 4.7, but I'm not aware of any other distros which have packaged this yet, so it is bit hard to test.

Note that updates from previously compiled versions worked fine, but not building from scratch. In case this should be sorted out for multiple platforms, I'm targetting this for build17.

Hans Joachim Desserud (hjd) wrote :

Error messages from make when trying to build wl.

Jens Beyer (qcumber-some) wrote :

If you search for "unistd.h gcc4.7" you'll find plenty of patches of other software which are called "fix for gcc4.7" and add a set of includes and defines which contain unisdt.h.

So your suspection is quite on-the-spot, I think :-)

Hans Joachim Desserud (hjd) wrote :

Looks like I was right. I've since been able to track down the following quote from the changelog [1]: "Avoid polluting the global namespace and do not include <unistd.h>.".

While not critical, I'd prefer to see this fixed before build 17 is released. Gcc 4.7 is already in Arch, and I assume other distros will upgrade shortly (definitely before build 18 is out at least). Patching of various packages in Debian has started already [2].

That said, I am still not sure whether including unistd.h could have any side effects, so if c++ people who actually knows this wants to wait, then I'm ok with that. However, the alternative is likely that widelands at some point will break in the development version of all distros and the maintainers will spend time tracking it down and patching it. If we end up not including a fix, we should probably include instructions for how to fix widelands for gcc 4.7 in a section for maintainers in the release notes or something.

[1] http://gcc.gnu.org/gcc-4.7/changes.html
[2] http://blog.pault.ag/post/21083720029/gcc-4-7-patchathon

tags: removed: arch
summary: - ftbfs if not including <unistd.h> in main.cc on Arch
+ ftbfs with gcc 4.7 if not including <unistd.h>

It seems that including unistd.h is very minor - but with c++ you can
never know. This patch will not see any testing and I am not prepared to
run another rc for this.

So no, this will not go into b17. The distros will need to hotpatch this
if it is a problem. It should go right after b17 of course.

Hans Joachim Desserud (hjd) wrote :

"with c++ you can never know."
As I mentioned above, fair enough. Though I still think we should mention this for maintainers in a section of the release notes. No need for x number of people to waste their time debugging an issue when we know the cause/fix.

Changed in widelands:
milestone: build-17 → build18-rc1

Noted. I'll add an appropriate section to the release notes for b17.

Changed in widelands:
status: New → Triaged
Nasenbaer (nasenbaer) wrote :

I pushed the #include in rev. 6376 - should be enough time until Build18 to see if this has any negative outcomes. ;)

Changed in widelands:
status: Triaged → Fix Committed
SirVer (sirver) wrote :

Released in build-18 rc1.

Changed in widelands:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments