undefined reference to pthread_create

[BloodWorkXGaming]

Very likely this is a user error, but I am not sure and out of ideas how to resolve it.

(.text.startup.main+0xb8): undefined reference to 'pthread_create(_thread**, pthread_attr_t const*, void* (*)(void*), void*)'

I am in XMMC memory model and trying to use pthread instead of cogrun as that apperently only works in lmm mode. (if there are other ways around that limitation I am open to new ideas.)

Cmake file:

cmake_minimum_required(VERSION 3.3)
find_package(PropWare REQUIRED)

project(SoPro C CXX SPIN2DAT)

SET(CMAKE_BUILD_FLAGS "-ffunction-sections -pedantic -Wall -Wextra")
# SET(CMAKE_C_FLAGS "${CMAKE_BUILD_FLAGS}")
# SET(CMAKE_CXX_FLAGS ${CMAKE_C_FLAGS})

set(BOARD activityboard)
set(MODEL xmmc)


create_simple_executable(${PROJECT_NAME}
        main.cpp
....
)

Thanks for all the help.

[DavidZemon]

Have you tried PropWare::Runnable? I think it is XMMC-compatible, but won't swear to it.

However, if you want/need to use pthread, add this underneath create_simple_executable(...):

target_link_libraries(${PROJECT_NAME} pthread)

Also, the -ffunction-sections and -Wall are redundant with what PropWare already sets for you. I just added documentation for the function/data sections via #149. The documentation will show up here once it finishes building.

And, not that I have any examples or am using it in PropWare yet, but I recently learned about add_compile_options() which is much easier than setting CMAKE_<LANG>_FLAGS. Try this instead:

add_compile_options(-pedantic -Wextra)

[BloodWorkXGaming]

Thanks for the tip with the compile options.

I tested it with Runnable in XMMC mode, and it also returns -1 there. As I've read in XMMC mode there can only ever be one cog running at the same time as only one can read from the sdcard at once, is that true? Any other alternatives? Or to go back one step any other ideas to combat memory/programm size issues besides xmmc?

I added the link library line in the CMake, however it still shows the same error as above when trying to use pthread.

Edit:
To add to that, I found this old example:
https://github.com/parallaxinc/propgcc/blob/master/demos/multi-cog-xmmc/multi-cog-demo.c
Which also doesn't work when compiling in xmmc mode.

[DavidZemon]

Can you upload your project, or email it to me if its confidential? Or a link if it's opensource, of course. I'll have to tinker with it to see why linking against pthread isn't working.

[BloodWorkXGaming]

Thank you very much!
I've created a private fork on github (https://github.com/BloodWorkXGaming/SoProFork/invitations) and invited you as it is hosted on a gitlab on our university servers.
The current latest commit is the test with the old example in xmmc mode, pthreads is currently not implemented, but was in one of the previous commits.

Do you prefer another way of communication instead of this issue (email, etc) or is it fine this way?

Thanks for all the help so for.
Have to go for like 2-3 hours, so no need to hurry :)

[BloodWorkXGaming]

After further testing I still wasn't able to compile it with pthreads nor am I able to start a cog in xmmc mode even on a different machine and after updating to the dev branch.

[DavidZemon]

FYI: Haven't forgotten about you, but today filled up and I don't suspect I'll have any time tomorrow either. Look for a response Friday maybe?

[BloodWorkXGaming]

Yee, No worries about that, thank you for your help :)

[BloodWorkXGaming]

Okay, after even more research and scanning through a ton of header files, I was able to find a way how to start a cog in XMMC mode:

if you add the line #define __PROPELLER_USE_XMM__ at the top of the main file before any include it suddenly works with cogrun!

Still haven't found a way to link pthread, however that is less important now with the ability to run cogs normally.

So to help any other people that want to run cogs in XMMC mode and prevent them from ages of searching, are you able to document it somewhere? Or even better, when using the normal makefile to build it, would it be possible to add that as a Marco via the commandline? (I think -D or something is the option, not sure about that tho)

Edit: To expand on this: I sometimes get the warning warning: "__PROPELLER_USE_XMM__" redefined [enabled by default], so it seems to get auto added already.
Another thing to do is to add EXTRA_STACK_BYTES onto every stack of every cog, as the required stack for XMM seems insanely large?

[DavidZemon]

That's very interesting. The compiler should add that automatically. But yes, I can absolutely add that to the command line automatically for you

[BloodWorkXGaming]

Okay, I just tested it again, without the line and it apperently works as well (no idea why it didn't before).
I just had to add a extra while(1); loop at the bottom to make the prints still appear. (had that in earlier testing as well tho.)

[BloodWorkXGaming]

Okay, so I thiiiink I found the final problem....
It has to do with simpleide and propgcc conflicting somehow.

It was working on my PC at home where no simpleide is installed, however when I just tried it on my Laptop, where simpleide is installed, it suddenly didn't work anymore (as well as EXTRA_STACK_BYTES not being present)

Now after uninstalling simpleide and setting the path variable for propware it suddenly works.

[DavidZemon]

Ohh, I'm fairly certain the PropGCC shipped with CLion completely stripped out all XMM* support. That would explain that problem at least.

And yes, I saw the EXTRA_STACK_BYTES warning as well but didn't think that you might not have seen it.

So this conversation has gotten pretty long and I'm not sure if I have any action items. Are you completely set now? Is there any changes you'd like to see made, or documentation that you'd like updated?

[BloodWorkXGaming]

If you mean simpleide with clion, then ye, that would explain veeeery much!

there is a tiny problem that I have to fix by copy pasting the simple libraries and add the EXTRA_STACK_BYTES so that the cogs are able to start up properly, but not sure how much you can do about that.
And everything kinda works, besides getting servo360 to run in xmm mode, wasn't able to figure out why tho. I am able to get the servos to run with the normal non 360 library (atleast the servo_set command works).

And on the documentation side of things, maybe adding somewhere that simpleide is not supported and the stuff with atleast EXTRA_STACK_BYTES bytes being present is required.

[BloodWorkXGaming]

Hey, it's me again, running in the same problem this issue was originally created for.
apperently linking to the standart libraries doesnt fully work.

I'm getting the same errors for the atomic library
```(.text._ZN9Labyrinth3runEv+0x21): undefined reference to ___atomic_flag_for_address' (.text._ZN9Labyrinth3runEv+0xbc): undefined reference to ___atomic_flag_wait_explicit'
(.text._ZN9Labyrinth3runEv+0xc5): undefined reference to `_atomic_flag_clear_explicit'

Is there any flag I have to enable to include the cpp standart libraries?

[DavidZemon]

Yep, but that should be a different problem from pthread btw

target_link_libraries(my_target PUBLIC stdc++)

Beware of code size though. There's a reason this isn't even an exposed option lol

[BloodWorkXGaming]

Ah, awesome, thanks for the info :) David Zemon <[email protected]> schrieb am Do., 31. Jan. 2019, 13:30:

…

Yep, but that should be a different problem from pthread btw target_link_libraries(my_target PUBLIC stdc++) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#148 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHwpZibQhOCwYtcBIMUz_YlmpVRageRaks5vIuHsgaJpZM4aDIF_> .