Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Technical Debt: Linux doesn't build in C++17 #44

Open
greenfire27 opened this issue May 17, 2022 · 3 comments
Open

Technical Debt: Linux doesn't build in C++17 #44

greenfire27 opened this issue May 17, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@greenfire27
Copy link
Collaborator

C++17 is our target version of C++. Linux (using makefile) is currently at C++14.

@greenfire27 greenfire27 added the enhancement New feature or request label May 17, 2022
@elementc
Copy link
Contributor

elementc commented May 17, 2022

While writing #43, a fix for #42, I bumped us from -std=gnu++11 to -std=c++14.

I tried to go as far as -std=c++17, but came up short due to this build error:

make: *** [Torque2D.mk:130: Debug/2d/gui/guiSpriteCtrl.cc.o] Error 1
In file included from ../../source/assets/assetManager.h:31,
                 from ../../source/assets/assetPtr.h:27,
                 from ../../source/2d/assets/AnimationAsset.h:27,
                 from ../../source/2d/core/ImageFrameProviderCore.h:31,
                 from ../../source/2d/core/ImageFrameProvider.h:27,
                 from ../../source/2d/core/ImageFrameProvider.cc:23:
../../source/persistence/taml/taml.h:88:13: error: 'HashMap' does not name a type
   88 |     typedef HashMap<SimObjectId, TamlWriteNode*>    typeCompiledHash;
      |             ^~~~~~~
compilation terminated due to -Wfatal-errors.

Which is vaguely ironic since switching to HashMap from std::unordered_map was the fix for #42. Alas, there's some work to go to overcome this one.

For Linux builds, we control the C++ standard via these lines:

CFLAGS := -std=c++14 -MMD -I. -Wfatal-errors -Wunused -m32 -msse -march=i686 -pipe

CFLAGS := -std=c++14 -MMD -I. -Wfatal-errors -Wunused -m64 -msse -march=x86-64 -pipe

As mentioned on #45, following #31, the Makefile-backed Linux build on the development branch has been slightly overhauled, including building in a Docker container that provides somewhat-tighter controls of our toolchain. In this case, the Dockerfile in engine/compilers/Make-{32,64}bit/ pins an Ubuntu 20.04 build environment, and uses the distro-default build-essential packages.
This loosely pins us to the following build of GCC:

casey on WATERFALCON in ~ 
at 09:02:55 🍀 docker run -it torque2d-linux64-build-env
root@5998068a57ba:/# g++ --version
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

@nahkhiir
Copy link
Contributor

nahkhiir commented Apr 15, 2023

This issue is due to the header guard _HASHTABLE_H defined in hashTable.h.

That header guard is a reserved identifier in the gcc standard library (code here in gcc repository - line 31).

Renaming the header guard in hashTable.h allows a full build with -std=c++17.

For the revised name I added a trailing underscore i.e. _HASHTABLE_H_ which also brings this header guard into line with the Torque code style guidelines.

@nahkhiir
Copy link
Contributor

nahkhiir commented Apr 15, 2023

I have submitted a pull request for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants