Re: [gtk-osx-users] Building libtasn1: Undefined symbols _c_isdigit.
- From: John Ralls <jralls ceridwen us>
- To: Pascal <p p14 orange fr>
- Cc: gtk-osx-users-list gnome org
- Subject: Re: [gtk-osx-users] Building libtasn1: Undefined symbols _c_isdigit.
- Date: Sun, 1 Aug 2021 10:01:36 -0700
On Aug 1, 2021, at 1:58 AM, Pascal <p p14 orange fr> wrote:
Le 26 juil. 2021 à 17:51, John Ralls <jralls ceridwen us> a écrit :
On Jul 25, 2021, at 9:54 PM, Pascal <p p14 orange fr> wrote:
Hello,
I built GNUTLS with Xcode 12.5.1.
I have got the error:
% jhbuild build gnutls
...
*** Building libtasn1 *** [4/7]
...
CCLD libtasn1.la
gl/.libs/libgnu.a:c-ctype.o: no symbols
Undefined symbols for architecture x86_64:
"_c_isdigit", referenced from:
__asn1_expand_object_id in parser_aux.o
__asn1_check_identifier in parser_aux.o
Digging in config.h, I've found:
OS X 10.9 has a macro __header_inline indicating the bug is fixed for C and
for clang but remains for g++; see <https://trac.macports.org/ticket/41033>.
Well it might not be the case, thus I forced C_CTYPE_INLINE macro to static in
libtasn1-4.16.0/lib/gl/c-ctype.h.
Pascal,
You want C_CTYPE_INLINE to be inline rather than static.
#ifndef C_CTYPE_INLINE
#define C_CTYPE_INLINE _GL_INLINE
#endif
and config.h *should* have
#define _GL_INLINE inline
So one of two things went wrong in your build: Either C_CTYPE_INLINE got defined incorrectly somewhere
before c_ctypes.h got included or configure got something wrong and didn't define _GL_INLINE to inline.
Hello John,
Intentionally, I set inline in libtasn1-4.16.0/lib/gl/c-ctype.h to be sure it is taken by the preprocessor:
% make
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive
Making all in lib
Making all in gl
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive
CC c-ctype.lo
In file included from c-ctype.c:3:
./c-ctype.h:32:10: warning: 'C_CTYPE_INLINE' macro redefined [-Wmacro-redefined]
# define C_CTYPE_INLINE inline
^
c-ctype.c:2:9: note: previous definition is here
#define C_CTYPE_INLINE _GL_EXTERN_INLINE
^
1 warning generated.
CCLD libgnu.la
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file:
.libs/libgnu.a(c-ctype.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file:
.libs/libgnu.a(c-ctype.o) has no symbols
CC ASN1.lo
CC decoding.lo
CC element.lo
CC parser_aux.lo
CCLD libtasn1.la
gl/.libs/libgnu.a:c-ctype.o: no symbols
Undefined symbols for architecture x86_64:
"_c_isdigit", referenced from:
__asn1_yylex in ASN1.o
__asn1_get_time_der in decoding.o
_asn1_write_value in element.o
_asn1_read_value_type in element.o
__asn1_expand_object_id in parser_aux.o
__asn1_check_identifier in parser_aux.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [libtasn1.la] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
I guess the value inline is puzzling the linker.
Is the bug actually fixed as written in config.h line 337?
How to cope with it then?
Pascal,
Compiler, not linker. The error suggests that the compiler is generating calls to c_isdigit in the indicated
compilation units (ASN1.o, decoding.o, element.o, and parser_aux.o) but isn't creating the function in
libgnu.a. That could be explained by your getting the warning only when building c-ctype.c: That compile saw
the `inline` modifier and didn't create the symbol, but the other compiles didn't see it and inserted a call
to _c_isdigit.
Notice that your hack made the situation worse: before it only parser_aux failed to inline c_isdigit. So take
out your hack and do what I told you to do: Figure out why parser_aux isn't inlining c_digit.
FWIW I've built libtasn1 several times in the last week on 10.14 and 11.5 without any issues.
Regards,
John Ralls
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]