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: Std Library and Linux #45

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

Technical Debt: Std Library and Linux #45

greenfire27 opened this issue May 17, 2022 · 2 comments
Labels
bug Something isn't working

Comments

@greenfire27
Copy link
Collaborator

Some standard library containers do not work on Linux platform (ex, std:unordered_map)

@greenfire27 greenfire27 added the bug Something isn't working label May 17, 2022
@elementc
Copy link
Contributor

I observed this while writing #43 which is a fix for #42.

On 43, we fixed the following compilation error which occurred when 128750d added a std::unordered_map to GuiControlProfile:

make: *** [Torque2D.mk:130: Debug/2d/controllers/core/PickingSceneController.cc.o] Error 1
In file included from /usr/include/c++/9/unordered_map:47,
                 from ../../source/gui/guiTypes.h:63,
                 from ../../source/gui/guiControl.h:42,
                 from ../../source/2d/core/ImageFrameProviderCore.h:51,
                 from ../../source/2d/core/ImageFrameProvider.h:27,
                 from ../../source/2d/core/SpriteBatchItem.h:27,
                 from ../../source/2d/core/SpriteBatch.h:27,
                 from ../../source/2d/core/SpriteBatchQuery.cc:26:
/usr/include/c++/9/bits/unordered_map.h:40:37: error: '_Hashtable_traits' in namespace 'std::__detail' does not name a template type

On #43 we papered over the issue by replacing the offending std::unordered_map with the Torque-internal HashMap which is a drop-in replacement. However, it's silly to not be able to use perfectly good container types from the standard library, and likely will drive off users who will want to be able to use the C++ constructs they know and love.

On this ticket, we should definitely investigate and fix this issue.

Would-be investigators will note that, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants
@elementc @greenfire27 and others