On 15/12/20 6:42 pm, Sebastian Huber wrote: > 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) >
Hmm. Is the gdb executable relocatable? > 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) Good. Silly me, I just assumed this would be the same on all Unix systems. What does an installed gcc show? >> 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. What about building expat as static only? Can you ask it to not build and install a shared library? If you cannot, as a test, add an rm of the shared library to the `install:` section of the GMP recipe. Maybe gdb and gcc will use a static library if that is all they are given. >> 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. Great. I wonder why it ignores the in source tree? I kind of assumed doing this would override the environment and give us control. The idea behind static is to lock down the exact configuration. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
