Compile errors with std::thread when compiling Linux native extension

Questions
1

Hi,

Hope someone can help. We are trying to Linux support for our native extension but we get a lot of compile errors to do with std::thread when compiling for Linux target. It compiles fine for both Windows and Mac and uses same code base for it native static library as it does for Windows and Mac.

Thanks,
Martin
Lead SDK Developer @ GameAnalytics

1 Like
2

Hi @mts!
What are the compile/link errors you get?

3

build errors
build errors1899Ă—723 214 KB

@Mathias_Westerdahl here you go: Had to take a screenshot (but maybe there is a smart way of copying this output as text but I don’t know it yet)

1 Like
4

27
271800Ă—943 380 KB

@Mathias_Westerdahl I am trying fix Linux support for our SDK but I get the above compile errors when I try to build, do you know what I could be doing wrong?

5

It says “undefined reference to…”
Do you include the correct libraries for x86_64-linux? Does it have the functions in it?

6

Yeah it works in the other SDKs we use it in, I think it would say “undefined symbols” if the functions would be missing in the static library. I think it might be related to this: https://stackoverflow.com/questions/37004976/undefined-reference-to-processstd-cxx11basic-string-when-compiling-a. I have compiled the static library with GCC 5 (also tried with clang), do you also use GCC 5 on the build server for Linux builds or what compiler do you use?

7

…also, when I see stuff like “cxx11” etc in combination with STL, I suspect some issues with mixing c runtime versions.

Yes, that might be one of the reasons. We use GCC 5.4 on the server currently (which should be compatible with 5.0).

Do you set the “-std=c++11” flag? (default is c++98 I think)

8

Yes I have set “-std=c++11” flag as well

2 Likes
9

Still not sure why this is an issue :confused:

Do you have a minimal main.cpp + command line I could try with this library? That way I can perhaps get to the issue faster.

Sidenote/question: For reasons exactly like this, have you considered not using STL? E.g. simply using const char* for the interface?

2 Likes
10

Yeah, I was thinking the same, I will add some methods to the library not using STL (const char* instead of std::string) and use them instead that should solve the problem.

1 Like
11

It works now with the suggestion of not using STL for Linux, Thanks :slight_smile:

1 Like
12

I’m happy it worked out for you!

Btw, do you have any numbers of library size before/after the STL/noSTL? I’m guessing the library shrank?

Also, wouldn’t this be the same benefit for your other platforms? I.e. what happens when the user wants your library and another 3rd party library with STL? (this is one of the reasons why we don’t use STL in Defold :slight_smile: )

1 Like
13

For now I have just created an interface in our public header file with functions not using STL, we still use STL underneath the hood. But I will let you know if I totally get rid of STL in our library :slight_smile:

2 Likes
14

I see!

But I will let you know if I totally get rid of STL in our library

Please do! I’m always interested in things like this :smiley:

2 Likes