autoconf
[Top][All Lists]
Advanced

[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


reply via email to

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