[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AC_CHECK_FUNC vs. function renaming? (curl on tru64/osf1, threads)
From: |
Jay K |
Subject: |
AC_CHECK_FUNC vs. function renaming? (curl on tru64/osf1, threads) |
Date: |
Tue, 6 Jul 2021 08:19:36 +0000 |
Hi autoconf folks.
I'm trying to build Curl on Tru64 / OSF1.
I think that will help git be useful there (I have git, but not git clone).
Curl configure has this thing where it looks for a thread library.
It tries to link to pthread_create:
AC_CHECK_FUNC(pthread_create, [USE_THREADS_POSIX=1] )
which ends up like this:
char pthread_create();
int main()
{
return pthread_create();
}
Well, you all know, a little more involved:
autoconf-2.69/lib/autoconf/c.m4:
# AC_LANG_FUNC_LINK_TRY(C)(FUNCTION)
..
The way this "really" works on Tru64/OSF1 though is that pthread.h says:
# pragma extern_prefix "__"
so the linked symbol is __pthread_create and the configuration
check fails to link, despite the library being there.
More generally, headers can #define the functions to be something else,
or static inline them. Right? I can still take the address of such things.
(#define foo foo2, not #define foo(x) foo2(x))
The autoconf mechanism..while carefully dodging many problems through
the years..is still a problem?
My intuition would be more like:
#include <pthread.h>
int main()
{
return (int)pthread_create;
}
but you an maybe find holes in that, and it doesn't address the overall
problems I think,
what autoconf is already dealing with, stubs, etc.
Advise? I mean, I can just hack it locally, but autoconf can/should accomodate
this,
generally, somehow?
Thank you,
- Jay
- AC_CHECK_FUNC vs. function renaming? (curl on tru64/osf1, threads),
Jay K <=