Re: [PATCHv2] Use toplevel configure for GMP and MPFR for gdb

["Arsen Arsenović" <arsen@aarsen.me>]

[-- Attachment #1: Type: text/plain, Size: 3405 bytes --]


Matthias Klose via Gcc-patches <gcc-patches@gcc.gnu.org> writes:

> On 10.11.22 20:05, apinski--- via Binutils wrote:
>> From: Andrew Pinski <apinski@marvell.com>
>> This patch uses the toplevel configure parts for GMP/MPFR for
>> gdb. The only thing is that gdb now requires MPFR for building.
>> Before it was a recommended but not required library.
>> Also this allows building of GMP and MPFR with the toplevel
>> directory just like how it is done for GCC.
>> We now error out in the toplevel configure of the version
>> of GMP and MPFR that is wrong.
>> OK after GDB 13 branches? Build gdb 3 ways:
>> with GMP and MPFR in the toplevel (static library used at that point for both)
>> With only MPFR in the toplevel (GMP distro library used and MPFR built from source)
>> With neither GMP and MPFR in the toplevel (distro libraries used)
>
> this still seems to be broken for a gdb trunk build, using GMP and MPFR system
> libraries:
>
> linking gdb:
>
> [...]
> ../gnulib/import/libgnu.a   -Lyes/lib -lmpfr -lgmp -lsource-highlight
> -lboost_regex  -lxxhash  -ldebuginfod   -ldl
> -Wl,--dynamic-list=/<<PKGBUILDDIR>>/gdb/proc-service.list
> ./libtool: line 5209: cd: yes/lib: No such file or directory
> libtool: link: cannot determine absolute directory name of `yes/lib'
> make[3]: *** [Makefile:2174: gdb] Error 1
> make[3]: Leaving directory '/<<PKGBUILDDIR>>/build/default/gdb'
>
> full build log at
> https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/15065515/+listing-archive-extra
>
>
> the toplevel config.log has:
>
> configure:8183: checking for the correct version of gmp.h
> configure:8202: x86_64-linux-gnu-gcc -c  -Iyes/include  -fPIC conftest.c >&5
> configure:8202: $? = 0
> configure:8220: x86_64-linux-gnu-gcc -c  -Iyes/include  -fPIC conftest.c >&5
> configure:8220: $? = 0
> configure:8221: result: yes
> configure:8237: checking for the correct version of mpfr.h
> configure:8255: x86_64-linux-gnu-gcc -c  -Iyes/include  -fPIC conftest.c >&5
> configure:8255: $? = 0
> configure:8272: x86_64-linux-gnu-gcc -c  -Iyes/include  -fPIC conftest.c >&5
> configure:8272: $? = 0
> configure:8273: result: yes
> configure:8342: checking for the correct version of the gmp/mpfr libraries
> configure:8366: x86_64-linux-gnu-gcc -o conftest  -Iyes/include  -fPIC
> conftest.c  -Lyes/lib -lmpfr -lgmp >&5
> configure:8366: $? = 0
> configure:8367: result: yes
> configure:8615: checking for isl 0.15 or later
> configure:8628: x86_64-linux-gnu-gcc -o conftest   -Iyes/include  -fPIC   -lisl
> -Lyes/lib -lmpfr -lgmp conftest.c  -lisl -lgmp >&5
> configure:8628: $? = 0

Seems that you're passing simply --with-mpfr, however:

  AC_ARG_WITH(mpfr,
  [AS_HELP_STRING([--with-mpfr=PATH],
                  [specify prefix directory for installed MPFR package.
                   Equivalent to --with-mpfr-include=PATH/include
                   plus --with-mpfr-lib=PATH/lib])])

... so it is interpreted to mean that the prefix MPFR is installed in is
yes/include (perhaps we should warn for the 'yes' case - that'd be less
confusing).  I think you should be able to get away without passing
--with-mpfr at all if your toolchain has mpfr available (and there's no
mpfr in the toplevel, to inhibit the toplevel trying to build its own
copy).

Hope that helps, have a lovely night.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]