Arch Linux User Repository

@ivanzkos Alternately, adding --disable-sim as a configure flag makes the incompatible pointer type warnings go away. I don't know what this flag does, but it seems to be recommended by upstream build docs: https://sourceware.org/gdb/wiki/BuildingNatively

@ivanzkos I've found this patch fixing the incompatible pointer types: https://sourceware.org/pipermail/gdb-patches/2023-December/205492.html

But ran into another compiler error. Didn't have the time yet to look into it.

LTO is now disabled, but the build for 14.2-2 fails for me with:

../../sim/frv/sem.c:24344:41: error: passing argument 2 of ‘sim_queue_fn_di_write’ from incompatible pointer type [-Wincompatible-pointer-types]
24344 |     sim_queue_fn_di_write (current_cpu, frvbf_h_acc40U_set, FLD (f_ACC40Uk), opval);
      |                                         ^~~~~~~~~~~~~~~~~~
      |                                         |
      |                                         void (*)(SIM_CPU *, UINT,  UDI) {aka void (*)(struct _sim_cpu *, unsigned int,  long unsigned int)}
In file included from ../../sim/common/cgen-cpu.h:25,
                 from ../../sim/common/sim-cpu.h:32,
                 from ../../sim/common/sim-base.h:90,
                 from ../../sim/frv/sim-main.h:41,
                 from ../../sim/frv/sem.c:28:
../../sim/common/cgen-par.h:195:47: note: expected ‘void (*)(SIM_CPU *, UINT,  DI)’ {aka ‘void (*)(struct _sim_cpu *, unsigned int,  long int)’} but argument is of type ‘void (*)(SIM_CPU *, UINT,  UDI)’ {aka ‘void (*)(struct _sim_cpu *, unsigned int,  long unsigned int)’}
  195 | extern void sim_queue_fn_di_write (SIM_CPU *, void (*)(SIM_CPU *, UINT, DI), UINT, DI);
      |                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../sim/frv/sem.c:24355:41: error: passing argument 2 of ‘sim_queue_fn_di_write’ from incompatible pointer type [-Wincompatible-pointer-types]
24355 |     sim_queue_fn_di_write (current_cpu, frvbf_h_acc40U_set, FLD (f_ACC40Uk), opval);
      |                                         ^~~~~~~~~~~~~~~~~~
      |                                         |
      |                                         void (*)(SIM_CPU *, UINT,  UDI) {aka void (*)(struct _sim_cpu *, unsigned int,  long unsigned int)}
...

Any ideas on how to fix it?

Thanks for the update. The latest update gdb-multiarch 14.2-1, also fails to build using Paru. Setting options=(!emptydirs !lto) fixed it.

Hello! The build fails for me as well, adding !lto fixed it.

Here's the first few build errors

....
  CC       m32r/nrun.o
  CCLD     m32r/run
../../sim/m32r/traps.c:115:43: error: type of 'm32r2f_h_psw_get' does not match original declaration [-Werror=lto-type-mismatch]
  115 |           m32r2f_h_bpsw_set (current_cpu, m32r2f_h_psw_get (current_cpu));
      |                                           ^
../../sim/m32r/cpu2.c:130:1: note: return value type mismatch
  130 | m32r2f_h_psw_get (SIM_CPU *current_cpu)
      | ^
../../sim/m32r/cpu2.c:130:1: note: type 'UQI' should match type 'int'
../../sim/m32r/cpu2.c:130:1: note: 'm32r2f_h_psw_get' was previously declared here
../../sim/m32r/traps.c:110:43: error: type of 'm32rxf_h_psw_get' does not match original declaration [-Werror=lto-type-mismatch]
  110 |           m32rxf_h_bpsw_set (current_cpu, m32rxf_h_psw_get (current_cpu));
      |                                           ^
../../sim/m32r/cpux.c:130:1: note: return value type mismatch
  130 | m32rxf_h_psw_get (SIM_CPU *current_cpu)
      | ^
../../sim/m32r/cpux.c:130:1: note: type 'UQI' should match type 'int'
../../sim/m32r/cpux.c:130:1: note: 'm32rxf_h_psw_get' was previously declared here
....

Build ended with

....
lto1: all warnings being treated as errors
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:3755: m32r/run] Error 1
make[4]: Leaving directory '--redacted home dir--/.cache/yay/gdb-multiarch/src/gdb-14.1/build/sim'
make[3]: *** [Makefile:4208: all-recursive] Error 1
make[3]: Leaving directory '--redacted home dir--/.cache/yay/gdb-multiarch/src/gdb-14.1/build/sim'
make[2]: *** [Makefile:3021: all] Error 2
make[2]: Leaving directory '--redacted home dir--/.cache/yay/gdb-multiarch/src/gdb-14.1/build/sim'
make[1]: *** [Makefile:9436: all-sim] Error 2
make[1]: Leaving directory '--redacted home dir--/.cache/yay/gdb-multiarch/src/gdb-14.1/build'
make: *** [Makefile:1021: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: gdb-multiarch-exit status 4
 -> Failed to install the following packages. Manual intervention is required:
gdb-multiarch - exit status 4

This fixed it...

• Found the cache directory at ~/.cache/yay/gdb-multiarch
• Edited the PKGBUILD file
  • Changed options=(!emptydirs) to options=(!emptydirs !lto)
• Ran these commands:
  • updpkgsums (I'm not sure if that is necessary)
  • makepkg -si PKGBUILD
• After a long long time it worked!

Version details

From PKGBUILD

pkgname=gdb-multiarch
pkgver=14.1
pkgrel=1

Latest git commit

commit 48cbc609287808cca9e263766e66c0928568126a (HEAD -> master, origin/master, origin/HEAD)
Author: **REDACTED**
Date:   Thu Jan 25 16:28:29 2024 +0200

    upgpkg: gdb-multiarch 14.1-1

Hi! Build fails for me too, fixed with options=(!lto). I did not build in chroot.

@aviel Sorry, didn't notice your reply (didn't have notifications turned on for this package).

As far as I know I don't do anything super-unusual. In makepkg.conf I have the following changes:

CFLAGS="-march=x86-64-v3 -mtune=generic [the rest are standard]"
OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug lto)

I build AUR packages in a chroot with aurutils, so perhaps that I'm using a chrooted build makes a difference?

Can confirm build fails in chroot without options=(!lto)

Hi @VorpalWay! I have never had any issues with the lto option, and it seems like you were the only one who ever posted about that. Do you do anything differently?

Hi! options=(!lto) still seems to be needed, and hasn't been added. I pointed this out almost a year ago in the comments below. I assume you missed it?