[uClibc]strerror_r undefined in libc/inet/rpc/clnt_perror.c

Manuel Novoa III mjn3 at codepoet.org
Tue Jul 23 16:06:20 UTC 2002


Miles,

On Tue, Jul 23, 2002 at 06:25:54PM +0900, Miles Bader wrote:
> clnt_perror.c uses strerror_r, and I'm getting a link-time failure:
> 
>    clnt_perror.o(.text+0xbc): undefined reference to `strerror_r'

Odd... For me, "nm clnt_perror.o" lists _glibc_strerror_r in the
dependencies.

> strerror_r is apparently supposed to be defined as an alias to one of
> several other functions in <string.h>, and clnt_perror.c _does_ include
> <string.h>, but I'm not entirely clear how the aliasing is supposed to
> happen.
> 
> <string.h> says essentially (I've edited out the __REDIRECT variants):
> 
> #if defined(__USE_XOPEN2K) && !defined(__USE_GNU)
> # define strerror_r _susv3_strerror_r
> #elif defined(__USE_MISC)
> # define strerror_r _glibc_strerror_r
> #endif

Until glibc decides how it will handle the issue, I set things up so
that you'd get the glibc strerror_r unless you wanted SUSv3 behavior
without "inheriting" it from _GNU_SOURCE being defined.  The only real
difference is the return type/value.

> However, looking at <features.h>, it appears that __USE_MISC should be
> defined by default, so I'm not sure why this isn't working.

It is odd.  Have you tried looking at the preprocessor output?

As far as clnt_perror.c goes, it never uses the return value of
strerror_r so changing the two occurrences to _susv3_strerror_r
(the base function) should solve the problem locally.

I'd like to know why the problem is occurring though.

BTW, were the clock() fixes flexible enough for you?  Sorry it took so
long to get to, but my uClibc work isn't currently being funded and
I've had lots of other demands on my time lately.

Manuel



More information about the uClibc mailing list