Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
EDuke32
EDuke32
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 91
    • Issues 91
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 9
    • Merge Requests 9
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Richard Gobeille
  • EDuke32EDuke32
  • Issues
  • #134

Closed
Open
Opened Oct 31, 2020 by Dino Bollinger@Doom64hunterContributor

Engine: Cannot compile 32 bit builds when std::string is used as a template argument

As we know, Synthesis currently fails to link the 32 bit builds because of a bug related to std::string inside template arguments. As of r9273, std::string is currently only used for the localization mapping inside screentext.cpp, namely as a template argument to std::unordered_map.

This issue only seems to occur in the eduke32 codebase. If I write a separate C++ program and compile it with g++ on MinGW32 (for instance using the example found here) no such error occurs.

If I remove the code that is currently causing the issue, and insert a very simple example of a template argument with std::string into the eduke32 codebase, such as the following:

#include <string>

void dummy_test()
{
    std::string str = "Hello World";
    size_t str_hash = std::hash<std::string>{}(str);
}

Then the linker returns the following error: stdstring_linker_error.txt

The linker error does not occur in debug builds, and it also does not occur for release 64 bit builds. While it is certainly possible to simply not use std::string at all, it would still be worth figuring out why exactly this error suddenly started occurring, and why it is not present outside of the codebase. The error only started appearing with the build compiled on 2020.09.22, whereas the offending code has existed for much longer.

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: terminx/eduke32#134