Skip to content

build: Fix undefined pthread reference.#440

Merged
chrissie-c merged 1 commit intoClusterLabs:masterfrom
orbea:pthread
Mar 17, 2021
Merged

build: Fix undefined pthread reference.#440
chrissie-c merged 1 commit intoClusterLabs:masterfrom
orbea:pthread

Conversation

@orbea
Copy link
Copy Markdown
Contributor

@orbea orbea commented Mar 16, 2021

When using slibtool (https://github.com/midipix-project/slibtool) instead of GNU libtool the build fails with undefined references to pthread.

/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: bmcpt.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /lib64/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

This works with GNU libtool because it silently filters out -no-undefined while slibtool does not.

This can be easily fixed by added $(PTHREAD_CFLAGS) and $(PTHREAD_LIBS) where applicable.

Also see this downstream issue: https://bugs.gentoo.org/775605

@knet-ci-bot
Copy link
Copy Markdown

Can one of the admins verify this patch?

@fabbione
Copy link
Copy Markdown
Member

ok to test

@fabbione
Copy link
Copy Markdown
Member

@orbea is slibtool the default on gentoo? if so it might be worth adding Gentoo to the CI nodes pool.

@orbea
Copy link
Copy Markdown
Contributor Author

orbea commented Mar 17, 2021

is slibtool the default on gentoo?

No, its currently being worked one for future integration. Whether it becomes the default or remains just an option in the future I am not sure. This issue tracks current slibtool issues found in gentoo:

https://bugs.gentoo.org/765709

Most, but not all issues are the result of GNU libtool silently hiding bugs for so long...

@fabbione
Copy link
Copy Markdown
Member

retest this please
(due to CI network hickup)

@fabbione
Copy link
Copy Markdown
Member

@orbea thanks for the pointer. slibtools seems to be available in different distributions so perhaps we can just enable a build with it to avoid regression in future.

@chrissie-c chrissie-c merged commit 9e1e3a2 into ClusterLabs:master Mar 17, 2021
@chrissie-c
Copy link
Copy Markdown
Contributor

Looks good, thanks for that patch, and to Fabio for reviewing.

@jnpkrn
Copy link
Copy Markdown
Contributor

jnpkrn commented Mar 17, 2021

Most, but not all issues are the result of GNU libtool silently hiding
bugs for so long...

Ah, cannot but to relate to this, especially since downstreams tend to
add fuel to the fire with diverging = less predictable tweaks.
I remeber we have met this before, looks like it was at this occasion:
20246f5#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R624-R634

(perhaps also related: #323 (comment))

@orbea orbea deleted the pthread branch March 17, 2021 14:06
kraj pushed a commit to YoeDistro/meta-openembedded that referenced this pull request Nov 22, 2021
The most important fix in this release is that we no longer log errors inside
the signal handler in loop_poll.c
This could cause an application hang in some circumstances.

Changelog is as follows:
doxygen2man: print structure descriptions
(ClusterLabs/libqb#443)

Fix pthread returns
(ClusterLabs/libqb#444)

poll: Don't log in a signal handler
(ClusterLabs/libqb#447)

Bump library version for v2.0.4

Implement heap based timer list
(ClusterLabs/libqb#439)

build: Fix undefined pthread reference.
(ClusterLabs/libqb#440)

Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants