Bug 23163

Summary: configure of libpthread-stubs can't detect stubs on NetBSD
Product: XCB Reporter: AOSASA Shigeru <lrr>
Component: MiscAssignee: xcb mailing list dummy <xcb>
Status: RESOLVED MOVED QA Contact: xcb mailing list dummy <xcb>
Severity: normal    
Priority: medium Keywords: patch
Version: unspecified   
Hardware: Other   
OS: NetBSD   
Whiteboard:
i915 platform: i915 features:
Attachments: add support for NetBSD
find stubs with AC_CHECK_FUNCS and AC_TRY_LINK
find stubs with AC_TRY_LINK
find stubs with AC_TRY_LINK

Description AOSASA Shigeru 2009-08-05 14:23:08 UTC
Created attachment 28382 [details] [review]
add support for NetBSD

NetBSD has pthread stubs,
but configure script of libpthread-stubs can't detect them.
because pthread stubs of NetBSD have non-standard names.

for example, '__libc_thr_self' is stub of pthread_self.
'__libc_thr_self' is called by 'pthread_self' macro defined in <pthread.h>.
(#define pthread_self __libc_thr_self)

attached patch adds support for NetBSD.


http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/thread-stub/thread-stub.c?rev=HEAD
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpthread/pthread.c?rev=HEAD
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpthread/pthread.h?rev=HEAD
Comment 1 Josh Triplett 2009-08-05 20:15:05 UTC
That patch looks like it will break support for non-NetBSD platforms.  Got a patch that doesn't?

Ideally, we should test for functions like pthread_self by compiling a test program that uses them, not by checking for the specific symbols.  That would improve portability to platforms which work like NetBSD does here.  On the other hand, it wouldn't fix portability to platforms that have different symbols in the pthread library and don't have stubs.  Still seems like an improvement, though.
Comment 2 AOSASA Shigeru 2009-08-06 04:18:56 UTC
Created attachment 28396 [details] [review]
find stubs with AC_CHECK_FUNCS and AC_TRY_LINK
Comment 3 AOSASA Shigeru 2009-08-06 04:28:08 UTC
I had a big mistake. my first patch break everything.
new patch attached.

new patch use following strategy,

  1. find symbols with AC_CHECK_FUNCS.
  2. if fails, try to compile and link with AC_TRY_LINK
Comment 4 Josh Triplett 2009-08-06 09:59:39 UTC
(In reply to comment #3)
> new patch use following strategy,
> 
>   1. find symbols with AC_CHECK_FUNCS.
>   2. if fails, try to compile and link with AC_TRY_LINK

That patch looks much better.  One thing, though: do we really want to bother with AC_CHECK_FUNCS at all?  What advantage does that give us over just using AC_TRY_LINK?  Using AC_TRY_LINK alone would mean we don't have to consider platform-specific details about the implementation of pthread functions (at least, on platforms which *do* provide pthread stubs).

Also, have you tested that the appropriate HAVE_* macros get set in the AC_TRY_LINK case, so that the appropriate stubs go into the library?
Comment 5 AOSASA Shigeru 2009-08-06 22:16:55 UTC
Created attachment 28413 [details] [review]
find stubs with AC_TRY_LINK

new patch.
changes from previous:

  * discard AC_CHECK_FUNCS, there is no strong reason to use.
  * treat WITH_* macro
Comment 6 AOSASA Shigeru 2009-08-20 19:07:15 UTC
Created attachment 28824 [details] [review]
find stubs with AC_TRY_LINK

patch updated.
changes from previous:

  * separate macro definition to check-stub.m4
  * follow latest codebase. (support sem_* function stubs)
Comment 7 Josh Triplett 2009-08-20 21:43:35 UTC
(In reply to comment #6)
> Created an attachment (id=28824) [details]
> find stubs with AC_TRY_LINK
> 
> patch updated.
> changes from previous:
> 
>   * separate macro definition to check-stub.m4
>   * follow latest codebase. (support sem_* function stubs)
> 

Thanks for updating the patch.  I noticed a typo in the new version, though:

+CHECK_SEM_STUB([sem_destory],
+	       [sem_t s; (void)sem_destory(&s);],
+	       [], [lack_stubs=yes])

s/destory/destroy/g
Comment 8 Julien Danjou 2012-01-11 08:55:27 UTC
This patch does not apply anymore. There's a chance it's somewhere in NetBSD, could you update it so we can merge this into XCB itself?
Comment 9 GitLab Migration User 2019-02-16 19:41:26 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/proto/xcbproto/issues/13.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.