> On Aug 1, 2021, at 1:58 AM, Pascal <p....@orange.fr> wrote: > >> >> Le 26 juil. 2021 à 17:51, John Ralls <jra...@ceridwen.us> a écrit : >> >>> On Jul 25, 2021, at 9:54 PM, Pascal <p....@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 _______________________________________________ gtk-osx-users-list mailing list gtk-osx-users-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
