[PATCH] Add GMP as a prerequisite for GDB

[Sebastian Huber]

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.huber at 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/