[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 18:32:07 +0000 |
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@cs.ucla.edu>
Sent: Tuesday, July 6, 2021 10:15:29 AM
To: Jay K <jayk123@hotmail.com>; autoconf@gnu.org <autoconf@gnu.org>
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&data=04%7C01%7C%7C2791dc39a2204324ede208d940a1abea%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637611885382281053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nEiTWf1Z0wzb%2Bi8WAvm1UxeYxfvd52JKlvDlX0M0aXg%3D&reserved=0