On 15/12/2020 04:59, Chris Johns wrote:
Sorry, I have been distracted with other things....
On 14/12/20 5:55 pm, Sebastian Huber wrote:
On 11/12/2020 14:00, Sebastian Huber wrote:
---
bare/config/devel/gmp-6.1.0.cfg | 18 ++++++++++
rtems/config/6/rtems-default.bset | 1 +
rtems/config/7/rtems-default.bset | 1 +
source-builder/config/gmp.cfg | 60 +++++++++++++++++++++++++++++++
4 files changed, 80 insertions(+)
create mode 100644 bare/config/devel/gmp-6.1.0.cfg
create mode 100644 source-builder/config/gmp.cfg
This change breaks the GCC build:
https://lists.rtems.org/pipermail/devel/2020-December/063751.html
I have no idea how to fix this. So, currently I am not able to do regular tool
chain updates which help to catch issues early. For example:
https://lists.rtems.org/pipermail/devel/2020-December/063751.html
Why is xgcc now dependent on a share libgmp? A FreeBSD gcc does not show any
shared library dependencies other than the standard OS ones. What happens if you
configure the GMP package that is built for gdb with --disable-shared (assuming
it supports it)?
With the RSB master on Linux I have:
/opt/rtems/6/bin/v850-rtems6-gdb:
libexpat.so.1 => /opt/rtems/6/lib/libexpat.so.1
(0x00007fca6ef2b000)
On another Linux machine I see this:
ldd /tmp/sh/rtems-no-gmp/6/bin/sparc-rtems6-gdb
libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fc74b881000)
On FreeBSD is see no dynamic libexpat:
/home/user/rtems/6/bin/sparc-rtems6-gdb:
libutil.so.9 => /lib/libutil.so.9 (0x8009fc000)
libncursesw.so.8 => /lib/libncursesw.so.8 (0x800a13000)
libm.so.5 => /lib/libm.so.5 (0x800a74000)
libpython2.7.so.1 => /usr/local/lib/libpython2.7.so.1 (0x800aa6000)
libdl.so.1 => /usr/lib/libdl.so.1 (0x800c9a000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x800c9e000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0x800cab000)
libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x800cd7000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x800dd5000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800ea5000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800ec7000)
libthr.so.3 => /lib/libthr.so.3 (0x800ee1000)
libc.so.7 => /lib/libc.so.7 (0x800f0e000)
Is gdb picking up a share library reference to it as well?
I have avoided any shared libraries with our tools and I would like to keep it
that way if possible. It is simpler for a number of reasons and what you have
tripped over is one of them.
I tried to use
--with-expat-type=static -with-gmp-type=static
it still picks up the shared libraries on Linux.
Another confusing thing is xgcc not using the in tree source for GMP. I assume
that is still present as git master shows it is still in the gcc common recipe.
Is gcc picking up a shared lib over the in tree source?
I didn't touch the GCC configuration. Before the GMP change for GDB, GCC
used the source tree GMP library.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
