Open MurphyMc opened 3 years ago
IMO let's just rename create_thread
to Rogue_create_thread
, RogueThread_create_thread
, or roguethread_create_thread
. The third alternative matches the style of the other functions, but either of the first two are preferable only because I plan to someday allow a dev-specified namespace prefix like MyLib
instead of Rogue
(MyLibString__reversed
etc. - to accommodate DLLs and the like) and there will be less work to do if everything starts with Rogue
.
I'm fine with renaming them (seems like a good idea), but that alone won't fix the original problem.
The problem, to be more clear, is that the function is actually defined in the header. So if the header ever gets included twice, there are two versions of the function.
This can happen when you have some other random C++ file which includes the generated header (e.g., to call Rogue functions) -- it includes the header once, and the RogueC-generated C++ file does too. Two functions with the same name -- the linker doesn't like it (even though they happen to be identical functions, the linker doesn't know/care).
The first of my proposed fixes above works because then the create_thread() function is only actually defined in one place (the RogueC-generated C++ file). The second one fixes it because even though there's a separate version of the function every time the header is included, it's not visible outside of a given compilation unit, so the linker doesn't care (and in general, it won't actually be called from more than one compilation unit, so it should get stripped and only one should end up in the executable anyway).
If you compile with pthreads enabled and then use the generated header in another file (e.g., to interface with some hand-written C++), you get a link error because of multiple definitions of create_thread(), which comes from Thread.rogue: https://github.com/AbePralle/Rogue/blob/develop/Source/Libraries/Standard/Thread.rogue#L192
The problem is that Thread.rogue puts its create_thread() helper function into the header via a nativeHeader block.
Two possible fixes:
Whichever road we go, I think there may be another function or two that it should also be applied to.