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

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

 



I mean, isn’t AC_CHECK_FUNC kinda wrong?

In reality we have essentially pthread.h:
#define pthread_create __pthread_create

In ridiculous extreme we could have:
stdio.h:
#define fopen pthread_create

AC_CHECK_FUNC or its users really should? include include “the” header, right?

But, I don’t understand how that “works with” the other goals there regarding glibc stubs, etc.

- Jay
________________________________
From: Paul Eggert <eggert@xxxxxxxxxxx>
Sent: Tuesday, July 6, 2021 10:15:29 AM
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 1:19 AM, Jay K wrote:
> My intuition would be more like:
>
>   #include <pthread.h>
>
>   int main()
>   {
>   return (int)pthread_create;
>   }

It should be easy to change curl's configure.ac to do that. But
pthread_create is a bigger portability minefield than just that. See the
Gnulib pthread module, e.g.:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.sv.gnu.org%2Fgitweb%2F%3Fp%3Dgnulib.git%3Ba%3Dblob%3Bf%3Dm4%2Fpthread_h.m4&amp;data=04%7C01%7C%7C2791dc39a2204324ede208d940a1abea%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637611885382281053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nEiTWf1Z0wzb%2Bi8WAvm1UxeYxfvd52JKlvDlX0M0aXg%3D&amp;reserved=0




[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux