Hi! As part of getting a stub x86_64 stub port to compile using the x86_64 tools, I've come across the same error as in ticket #3176: https://devel.rtems.org/ticket/3176
_However_ the proposed patches to fix this, which are already in Newlib 3.0.0 and the RSB, are part of what cause this error - the following line defines the __getreent function: RTEMS_STUB(struct _reent *, __getreent (), { }) I don't see how this is compatible with our confdefs.h[1], which also tries to define __getreent[2] and will inevitably cause the multiple definitions, unless we use "-nostdlib". I'm going to continue looking into how we actually use / used __getreent, but I believe this problem continues to exist with all tools using newlib-3.0.0 now (which RSB uses in the rtems-default.bset) - it makes use of our confdefs.h incompatible, which I believe most tests do. I must be doing something wrong here, because if this is right, many many builds would be failing with the new toolsets when --enable-tests is set. To reproduce: - Update RSB (confirm that ./rtems/config/tools/rtems-gcc-7.3.0-newlib-3.0.0.cfg exists) and rebuild your tools for any arch - this should use newlib-3.0.0's libc, which defines __getreent. - Use the arch's gcc to compile any test that includes confdefs.h or as a quick test (slightly quicker than locating crt0.o and analyzing symbols): -> % echo "void __getreent(){}" | i386-rtems5-gcc -xc -v - ... GNU C11 (GCC) version 7.3.0 20180125 (RTEMS 5, RSB c9db1326ef99e3e1267d17d2c7e5e51a48d1be2a, Newlib 3.0.0) (i386-rtems5) .... /tmp/cc90vvoP.o: In function `__getreent': :(.text+0x0): multiple definition of `__getreent' --------------- Next steps: - Figure out how __getreent is actually meant to be used based on the confdefs setup - reentrancy seems relevant to interrupts, so I imagine RTEMS should be able to maintain control entirely. Is that right? Should __getreent be left as a dynamically resolved symbol up until the RTEMS executive can resolve it (if that's even an option)? (Possibly tangential: I do see that newlib needs the definition of __getreent for __errno[3][4]. If I remove the definition from newlib, gcc fails to even compile in bootstrapping gcc, the compiler throws an undefined reference to __getreent[5], understandably, when trying to compile libgomp, since there are missing references within the stdlib. I imagine some linker tricks could let me pull it off, but I'm not _quite_ sure I understand all the actors in this complex dance yet.) P.S. - Sorry about the length of the email! I tend to put more information in rather, but if you think I should keep them more concise and to the point, let me know, please! Thanks! [1] https://sourceware.org/ml/newlib/2017/msg01020.html [2] https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs.h#n2266 [3] https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/errno/errno.c;h=fd1743d73625bf098fc23af9c06924381f840139;hb=HEAD#l13 [4] https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/sys/reent.h;h=6e55e1c1fa760c4090a1f9cca8c9f83ae68065f9;hb=HEAD#l825 [5] https://gist.github.com/AmaanC/4b43095b88e3fed17245a7da91d5b65a#file-libgomp-config-log-L119-L120 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel