[PATCH] 6: Use GDB 13.2

Chris Johns chrisj at rtems.org
Tue Jul 25 05:26:00 UTC 2023


On 25/7/2023 3:18 pm, Sebastian Huber wrote:
> On 25.07.23 03:43, Chris Johns wrote:
>> On 24/7/2023 9:53 pm, Sebastian Huber wrote:
>>> Hello Karel,
>>>
>>> On 24.07.23 13:15, Karel Gardas wrote:
>>>>
>>>> this together with also libexpat patch builds fine on:
>>>>
>>>> - macOS 13.4.1
>>>> - FreeBSD 13.2
>>>> - Ubuntu 20.04
>>>
>>> thanks for the testing.
>>>
>>>>
>>>> btw, recently Joel remarked that gdb from 7/ makes troubles building on fbsd
>>>> 12.x. I verified the same on fbsd 13.x and Hesham noted on discord that he has
>>>> the same issues on macOS. GBD from 7/rtems-* complains about missing libmpfr.
>>>>
>>>> [...]
>>>> checking for the correct version of gmp.h... yes
>>>> checking for the correct version of mpfr.h... no
>>>> configure: error: Building GDB requires GMP 4.2+, and MPFR 3.1.0+.
>>>> Try the --with-gmp and/or --with-mpfr options to specify
>>>> their locations.  If you obtained GMP and/or MPFR from a vendor
>>>> distribution package, make sure that you have installed both the libraries
>>>> and the header files.  They may be located in separate packages.
>>>> shell cmd failed: /bin/sh -ex
>>>> /usr/home/karel/git/rtems-source-builder/rtems/build/aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1/do-build
>>>> error: building aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1
>>>>
>>>> Obviusly gdb from 6/ does not hence there is probably some bit missing in 7/
>>>> which is already fixed in 6/
>>>
>>> Actually I don't know how this should be handled. Some libraries are added to
>>> rtems/config/6/rtems-default.bset others seem to be specific tool files. The 7/
>>> tools should a minimum set of patches. Things should be directly fixed in the
>>> upstream projects.
>>
>> We have been moving to build support libraries, such as GMP, separately and not
>> by links into the source tree of gcc. MacOS M silicon requires a specific option
>> for GMP to work and this has resulted in us building these libraries before
>> building the packages that depend on them because the upstream provide no means
>> to inject specific options. GDB added GMP and it seems more are being added so
>> we need to add support to build them before GDB and remove the symlink'ing into
>> the GCC source tree. The GMP change should provide a suitable template for doing
>> this.
> 
> So, ISL, MPC, MPFR, etc. should also move to the top level configuration?

We have been doing this as required, ie more than one package depends on it or
extra options. I suppose it is OK to build them them all from the top level. It
would protect us later if we find we need to handle the package in a specific
way, eg many years from now.

Chris


More information about the devel mailing list