FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
264 views 8 comments
by anonymous
Hi all,

I also asked this in the OpenWRT forum as I'm a bit unsure where it is best to ask ... sorry for cross-posting.

After finally being able to build the Firmware (Teltonika RUT955 box) with the RUT OS. I also managed to get a Go application cross compiled using the toolchain and sdk I have on my machine. I solved all of the linking and compilation problems and it's dynamically linked and finding all of the required libs. However I am unable to run the application.

All I'm getting is an error:
can't resolve symbol 'pthread_attr_getstacksize'

From what I can see in the sources of the firmware, the function is declared in the pthread.h and implemented in libpthread/linuxthreads/attr.c however as "__pthread_attr_getstacksize" followed by a call of: weak_alias (__pthread_attr_getstacksize, pthread_attr_getstacksize)
Could it be, that this macro isn't declared in my case and therefore the declaration and implementation aren't linked together?

I'd greatly appreciate help with this as I'm completely stuck at the moment.

Chris

1 Answer

0 votes
by anonymous
Hello,

It looks like the compiled in version is linuxthreads.old instead of linuxthread / ntpl, and this one doesn't have pthread_get_stacksize(). Why is another question, the build depends on LINUXTHREADS_OLD / LINUXTHREADS_NEW and there is nothing obvious in make menuconfig.

Regards,
Best answer
by anonymous
So ... how can I make it use the linuxthread/ntpl? ... I also had a look and I couldn't find any config to select that.

However I did read here: https://uclibc.uclibc.narkive.com/r5ykNxQ5/linuxthreads-new-should-select-uclibc-has-realtime

"LINUXTHREADS_NEW does not build correctly without also selecting
UCLIBC_HAS_REALTIME since function nanosleep will be undefined"

So perhaps enabling the realtime option enables the linuxthreads.new?
by anonymous

From toolchain/uClibc/config-0.9.33.2/common :

# LINUXTHREADS_NEW is not set
# LINUXTHREADS_OLD is not set
# UCLIBC_HAS_BACKTRACE is not set
UCLIBC_HAS_THREADS_NATIVE=y

You can try to change that to :

LINUXTHREADS_NEW=y
# LINUXTHREADS_OLD is not set
# UCLIBC_HAS_BACKTRACE is not set
# UCLIBC_HAS_THREADS_NATIVE is not set

and make clean && make

It would probably be a good idea to make a backup first ...

Regards,

 
by anonymous
Aaah ... so I simply can't change that from the "make menuconfig" side, but would have to patch the uClibc config?
by anonymous
Yes, edit it.
by anonymous
So I copied the libpthread.so.0 from the reouter and inspected it with 'readelf' ... from the symbols it lists it should be the "nptl" or the "new" version. I would assume it's the "nptl" version from the default settings. But in this case it should generally also have the pthread_attr_getstacksize function defined. Strangely it doesn't. It defines all sorts of symbols starting with double-underscores which the "old" doesn't have.

But I'lll give the "new" a try.
by anonymous
When build with this configuration, libpthread-0.9.33.2.so has __pthread_attr_getstatcksize(), however the alias appears to be missing.
by anonymous
And I'm currently struggling to compile ... I'll reset my local repo completely and start from scratch ... But you say it wouldn't have worked anyway? That would of course be an explanation why It doesn't work with "nptl" as this too should generally have the symbol defined but also with an alias (But a hard one instead of a weak alias in "new")

Cause I'm pretty sure it's not using the "old".

[UPDATE]

When I started from scratch, using the "new" thread lib I didn't manage to build all modules. So I ran the "nptl" version on the clean SDK. With this my application seems to be working. So I have to figure out what's different in my stripped down build.
by anonymous
staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/lib/staging_dir/libpthread-0.9.33.2.so (the non-stripped version) contains both the symbol and its alias, but the stripped one is missing the alias and has a corrupt header as can be seen with objdump.

A bug in one of the tools ?