> On Aug 3, 2021, at 12:48 AM, Pascal <p....@orange.fr> wrote: > >> >> Le 1 août 2021 à 19:01, John Ralls <jra...@ceridwen.us> a écrit : >> >>> 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. > > Hello John, > > Ok I guess something is wrong on my side, you're feedback is useful as usual. > > Here are the changes I made: > > --- ./jhbuildrc-custom.0 2021-07-25 10:44:22.000000000 +0200 > +++ ./jhbuildrc-custom 2021-07-25 11:07:36.000000000 +0200 > @@ -18,6 +18,8 @@ > # You can also read environment variables and decide what to do based > # on their values: > > +print ("in jhbuildrc-custom") > + > _target = os.environ.get("TARGET") > if _target is None: > # The default setup... > @@ -27,6 +29,10 @@ > # > # > > +_root = os.path.expanduser("/usr/local") > +checkoutroot = os.path.join(_root, "src-2021") > +prefix = os.path.join(_root, "xnadalib-2021") > + > # The moduleset can be overridden. > # > # moduleset = "gtk-osx" > @@ -113,3 +119,11 @@ > # systems running Mojave and later: > # setup_sdk(target="10.14") > > +environ_append('CFLAGS', "-g -O0 -ggdb3") > +environ_append('CXXFLAGS', "-g -O0 -ggdb3") > +environ_append('CPPFLAGS', "-g -O0 -ggdb3") > +environ_append('OBJCFLAGS', "-g -O0 -ggdb3") > +environ_append('BUILDCFLAGS', "-g -O0 -ggdb3") > +environ_append('CFLAGS_FOR_BUILD', "-g -O0 -ggdb3") > +environ_append('LDFLAGS', "-Wl,-no_pie") > + > > Your question is the good one but not so easy to answer ;-) > > I try to print the macro value: > (trick from > https://stackoverflow.com/questions/1562074/how-do-i-show-the-value-of-a-define-at-compile-time) > > --- ./lib/gl/c-ctype.h.0 2020-01-03 23:26:54.000000000 +0100 > +++ ./lib/gl/c-ctype.h 2021-08-02 07:02:29.000000000 +0200 > @@ -33,6 +33,10 @@ > # define C_CTYPE_INLINE _GL_INLINE > #endif > > +#define XSTR(x) STR(x) > +#define STR(x) #x > +#pragma message "The value of C_CTYPE_INLINE: " XSTR(C_CTYPE_INLINE) > + > #ifdef __cplusplus > extern "C" { > #endif > > The build log: > > ppi% make -w > make: Entering directory `/usr/local/src-2021/libtasn1-4.16.0' > /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive > make[1]: Entering directory `/usr/local/src-2021/libtasn1-4.16.0' > Making all in lib > make[2]: Entering directory `/usr/local/src-2021/libtasn1-4.16.0/lib' > Making all in gl > make[3]: Entering directory `/usr/local/src-2021/libtasn1-4.16.0/lib/gl' > /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive > make[4]: Entering directory `/usr/local/src-2021/libtasn1-4.16.0/lib/gl' > make[5]: Entering directory `/usr/local/src-2021/libtasn1-4.16.0/lib/gl' > CC c-ctype.lo > In file included from c-ctype.c:3: > ./c-ctype.h:38:9: warning: The value of C_CTYPE_INLINE: static __attribute__ > ((__unused__)) [-W#pragma-messages] > #pragma message "The value of C_CTYPE_INLINE: " XSTR(C_CTYPE_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 > make[5]: Leaving directory `/usr/local/src-2021/libtasn1-4.16.0/lib/gl' > make[4]: Leaving directory `/usr/local/src-2021/libtasn1-4.16.0/lib/gl' > make[3]: Leaving directory `/usr/local/src-2021/libtasn1-4.16.0/lib/gl' > make[3]: Entering directory `/usr/local/src-2021/libtasn1-4.16.0/lib' > CC ASN1.lo > In file included from ASN1.y:34: > ./gl/c-ctype.h:38:9: warning: The value of C_CTYPE_INLINE: static > __attribute__ ((__unused__)) [-W#pragma-messages] > #pragma message "The value of C_CTYPE_INLINE: " XSTR(C_CTYPE_INLINE) > ^ > 1 warning generated. > CC decoding.lo > In file included from decoding.c:35: > ./gl/c-ctype.h:38:9: warning: The value of C_CTYPE_INLINE: static > __attribute__ ((__unused__)) [-W#pragma-messages] > #pragma message "The value of C_CTYPE_INLINE: " XSTR(C_CTYPE_INLINE) > ^ > 1 warning generated. > CC element.lo > In file included from element.c:33: > ./gl/c-ctype.h:38:9: warning: The value of C_CTYPE_INLINE: static > __attribute__ ((__unused__)) [-W#pragma-messages] > #pragma message "The value of C_CTYPE_INLINE: " XSTR(C_CTYPE_INLINE) > ^ > 1 warning generated. > CC parser_aux.lo > In file included from parser_aux.c:29: > ./gl/c-ctype.h:38:9: warning: The value of C_CTYPE_INLINE: inline > [-W#pragma-messages] > #pragma message "The value of C_CTYPE_INLINE: " XSTR(C_CTYPE_INLINE) > ^ > 1 warning generated. > 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 > 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[3]: Leaving directory `/usr/local/src-2021/libtasn1-4.16.0/lib' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/usr/local/src-2021/libtasn1-4.16.0/lib' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/local/src-2021/libtasn1-4.16.0' > make: *** [all] Error 2 > make: Leaving directory `/usr/local/src-2021/libtasn1-4.16.0' > > Frankly speaking, it makes me more puzzled. The behavior is definitely > different, not so obvious to find out. > By chance if you have some clues it might help.
Pascal, You were right from the outset, I didn't follow up on the snippet you quoted from config.h. The part that's actually germane is "Suppress extern inline (with or without __attribute__ ((__gnu_inline__))) on configurations that mistakenly use 'static inline' to implement functions or macros in standard C headers like <ctype.h>. For example, if isdigit is mistakenly implemented via a static inline function, a program containing an extern inline function that calls isdigit may not work since the C standard prohibits extern inline functions from calling static functions (ISO C 99 section 6.7.4.(3)." I'll spare you the gory details, https://stackoverflow.com/questions/16245521/c99-inline-function-in-c-file explains the correct interpretation. config.h (really gnu lib's extern_inline.m4) goes on to screw up __header_inline (it's defined in macOS.sdk/usr/include/sys/cdefs.h if you're interested) by not including the requisite header, but even if one adds it it still gets the wrong answer. Rather than try to fix config.h (never mind trying to set the GnuLib devs straight, I've tried that before and it's an utter waste of time) the simplest patch seems to be to insert #define _GL_EXTERN_INLINE_STDHEADER_BUG into parser_aux.c before the int.h include. I'll push a patch for that. The reason I was able to build successfully is that I was doing release builds with -O2, which runs the inliner: With optimization off: $ nm lib/.libs/parser_aux.o | grep c_isdigit U _c_isdigit $ nm lib/.libs/element.o | grep c_isdigit 00000000000013c0 t _c_isdigit With -O2 the function gets inlined and parser_aux.o has no c_isdigit symbol at all because it has been inlined already. That doesn't explain why the compiler detection in config.h works differently in parser_aux.c from how it works in the other files, that's pretty weird. I made your change to c_ctypes.h and can confirm that it does for me too. BTW on debug: You can call setup_debug() in jhbuildrc-custom to set "-g -O0" for CFLAGS, CXXFLAGS, and OBJCFLAGS. The preprocessor doesn't do debug symbols or optimization so there's no need to set CPPFLAGS. clang ignores -ggdb3 and besides the macOS debugger is lldb; there's -glldb. See https://clang.llvm.org/docs/UsersManual.html#id53 . -g -glldb (or -ggdb for that matter) is redundant. 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
