But, isn't any function subject to arbitrary renaming
by its "declaration"? And AC_CHECK_FUNC is probing kinda at the wrong
level, or skipping a level?
pragmas, defines, static inline, intrinsics, etc.
It isn't specific to pthread_create.
There is this repeating pattern, all these functions would fail:
#ifdef _PTHREAD_USE_MANGLED_NAMES_
# ifdef _PTHREAD_USE_PTDNAM_
# pragma extern_prefix "__"
# else
# define pthread_attr_getstacksize __pthread_attr_getstacksize
# endif
#endif
extern int pthread_attr_getstacksize (
const pthread_attr_t*,
size_t*);
#ifdef _PTHREAD_USE_PTDNAM_
# pragma extern_prefix ""
#endif
Another class of examples would be on Windows/x86, probing
for any __stdcall or __fastcall function would fail this way,
due to the manual declaration.
Is the user supposed to know that the function
might be "renamed" and work to "declare" it correctly?
i.e. not use AC_CHECK_FUNC for "these cases"?
Like gnulib checks for pthread.h and then includes it in other tests?
But that seems like something user shouldn't have to know,
should be generally assumed?
I guess the documentation kinda covers it:
"This macro checks for functions with C linkage"
For some definition of "C linkage".
Macros obviously don't count, and the rest are gray to me,
and the documentation could be excused for not listing every way functions get renamed,
not saying "external" to disqualify inlines, etc.
> ac_cv_func_pthread_create=yes
Thank you.
I got it "working" by editing down configure.
Er, only building so, doesn't work. I'll dig more.
- Jay
________________________________
From: Paul Eggert <eggert@xxxxxxxxxxx>
Sent: Tuesday, July 6, 2021 7:07 PM
To: Jay K <jayk123@xxxxxxxxxxx>; autoconf@xxxxxxx <autoconf@xxxxxxx>
Subject: Re: AC_CHECK_FUNC vs. function renaming? (curl on tru64/osf1, threads)
On 7/6/21 11:32 AM, Jay K wrote:
> I mean, isn’t AC_CHECK_FUNC kinda wrong?
No, it's working as documented. You just have an unusual situation with
pthread_create. Again, please see Gnulib's treatment of pthread_create.
Since we're talking about Tru64, this is of academic interest anyway. HP
stopped supporting Tru64 in 2012, which means curl doesn't need to
support it either. You can port curl to your museum-piece Tru64 by hand,
by configuring with the appropriate arguments to override the
otherwise-incorrect conclusions of 'configure'. For example,
'./configure ac_cv_func_pthread_create=yes' (I haven't tested this and
you may need to change the argument a bit).
