[PATCH] Add GMP as a prerequisite for GDB

[Chris Johns]

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