multiple definition of __getreent (in newlib's crt0.c and RTEMS' confdefs.h)

[Amaan Cheval]

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