[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_CHECK_FUNC vs. function renaming? (curl on tru64/osf1, threads)

From: Jay K
Subject: Re: AC_CHECK_FUNC vs. function renaming? (curl on tru64/osf1, threads)
Date: Tue, 6 Jul 2021 21:25:09 +0000

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:

 #  pragma extern_prefix "__"
 # else
 #  define pthread_attr_getstacksize __pthread_attr_getstacksize
 # endif
 extern int pthread_attr_getstacksize (
         const pthread_attr_t*,
 # pragma extern_prefix ""

 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 
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 <>
Sent: Tuesday, July 6, 2021 7:07 PM
To: Jay K <>; <>
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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]