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

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

 



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




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

  Powered by Linux