binutils fails to upgrade: `cpuid.c: fatal error: 'asm/hwprobe.h' file not found`

[barracuda156]

Looks like it tries to use x86 stuff on riscv64?

:info:build configure: creating ./config.lt
:info:build libtool: compile:  /usr/bin/clang -DHAVE_CONFIG_H -I. -U_ASM -I.. -I. -I./../common -I./../src -I./../../include -I../../bfd -I./../.. -I/opt/local/include -Wall -Wno-nonnull-compare -pipe -Os -MT libgp_collector_la-collector.lo -MD -MP -MF .deps/libgp_collector_la-collector.Tpo -c collector.c -o libgp_collector_la-collector.o >/dev/null 2>&1
:info:build mv -f .deps/libgp_collector_la-libcol_util.Tpo .deps/libgp_collector_la-libcol_util.Plo
:info:build /bin/sh ./libtool  --tag=CC   --mode=compile /usr/bin/clang -DHAVE_CONFIG_H -I.  -U_ASM -I.. -I. -I./../common -I./../src -I./../../include -I/opt/local/include -Wall -Wno-nonnull-compare -pipe -Os     -MT collectorAPI.lo -MD -MP -MF .deps/collectorAPI.Tpo -c -o collectorAPI.lo collectorAPI.c
:info:build In file included from libcol_hwcdrv.c:25:
:info:build In file included from ./../common/hwcdrv.c:35:
:info:build ./../common/cpuid.c:49:10: fatal error: 'asm/hwprobe.h' file not found
:info:build #include <asm/hwprobe.h>
:info:build          ^~~~~~~~~~~~~~~
:info:build libtool: compile:  /usr/bin/clang -DHAVE_CONFIG_H -I. -U_ASM -I.. -I. -I./../common -I./../src -I./../../include -I/opt/local/include -Wall -Wno-nonnull-compare -pipe -Os -MT collectorAPI.lo -MD -MP -MF .deps/collectorAPI.Tpo -c collectorAPI.c  -fPIC -DPIC -o .libs/collectorAPI.o

[RJVB]

On Saturday September 21 2024 10:08:12 Sergey Fedorov wrote:

Looks like it tries to use x86 stuff on riscv64?

Afraid that's what it looks like ...

[barracuda156]

Ok, lumme see what is going so wrong there.

[barracuda156]

In fact the code is supposed to be for riscv (know knew it also uses cpuid), but that header may or may not exist. Something related in discussion here: https://github.com/pytorch/cpuinfo/pull/148/commits/fac0b2f3cb616000a9d2dc7b5cc95ffb8c11687c

Anyway, this is an upstream bug in binutils obviously.

[barracuda156]

Header asm/hwprobe.h added in https://github.com/torvalds/linux/commit/ea3de9ce8aa280c5175c835bd3e94a3a9b814b74 So sure enough, it cannot exist prior to that. binutils upstream is spectacular.

[RJVB]

Would this be solved simply by putting adding header in a local headerpath?

[barracuda156]

On a side note, it is also broken on macOS:

libtool: compile:  ccache /usr/bin/gcc-4.2 -std=gnu99 -DHAVE_CONFIG_H -I. -DBINDIR=\"/opt/local/bin\" -DLIBDIR=\"/opt/local/lib\" -I. -I. -I./../include -DHAVE_mach_o_be_vec -DHAVE_mach_o_le_vec -DHAVE_mach_o_fat_vec -DHAVE_pef_vec -DHAVE_pef_xlib_vec -DHAVE_sym_vec -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -I./../zlib -pipe -Os -arch ppc -MT bfd.lo -MD -MP -MF .deps/bfd.Tpo -c bfd.c -o bfd.o
none needed
checking whether ccache /usr/bin/gcc-4.2 -std=gnu99 understands -c and -o together... bfd.c:771: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘bfd_error_type’
bfd.c:772: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘bfd_error_type’
bfd.c:773: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘bfd’
bfd.c:774: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘char’
bfd.c: In function ‘bfd_get_error’:
bfd.c:817: error: ‘bfd_error’ undeclared (first use in this function)
bfd.c:817: error: (Each undeclared identifier is reported only once
bfd.c:817: error: for each function it appears in.)
bfd.c: In function ‘bfd_set_error’:
bfd.c:837: error: ‘bfd_error’ undeclared (first use in this function)
bfd.c: In function ‘bfd_set_input_error’:
bfd.c:861: error: ‘bfd_error’ undeclared (first use in this function)
bfd.c:863: error: ‘input_bfd’ undeclared (first use in this function)
bfd.c:864: error: ‘input_error’ undeclared (first use in this function)
bfd.c: In function ‘bfd_errmsg’:
bfd.c:889: error: ‘input_error’ undeclared (first use in this function)
bfd.c:891: error: ‘input_bfd’ undeclared (first use in this function)
bfd.c: In function ‘_bfd_clear_error_data’:
bfd.c:948: error: ‘_bfd_error_buf’ undeclared (first use in this function)
bfd.c: In function ‘bfd_asprintf’:
bfd.c:972: error: ‘_bfd_error_buf’ undeclared (first use in this function)
bfd.c: At top level:
bfd.c:1655: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘struct’
bfd.c: In function ‘error_handler_sprintf’:
bfd.c:1677: error: ‘error_handler_messages’ undeclared (first use in this function)
bfd.c: In function ‘_bfd_error_handler’:
bfd.c:1719: error: ‘error_handler_messages’ undeclared (first use in this function)
bfd.c: In function ‘_bfd_set_error_handler_caching’:
bfd.c:1770: error: ‘error_handler_messages’ undeclared (first use in this function)
bfd.c: In function ‘_bfd_restore_error_handler_caching’:
bfd.c:1792: error: ‘error_handler_messages’ undeclared (first use in this function)
bfd.c: In function ‘bfd_init’:
bfd.c:1922: error: ‘bfd_error’ undeclared (first use in this function)
bfd.c:1923: error: ‘input_bfd’ undeclared (first use in this function)
bfd.c:1925: error: ‘input_error’ undeclared (first use in this function)
make[4]: *** [bfd.lo] Error 1

[RJVB]

On Saturday September 21 2024 11:36:22 Sergey Fedorov wrote:

On a side note, it is also broken on macOS:

On PPC at least apparently. Of course this is a LinuxPorts port, those are not guaranteed to work on Mac (and often, guaranteed not to).

[barracuda156]

On Saturday September 21 2024 11:36:22 Sergey Fedorov wrote: On a side note, it is also broken on macOS: On PPC at least apparently. Of course this is a LinuxPorts port, those are not guaranteed to work on Mac (and often, guaranteed not to).

On macOS I build this from standard port, not from here. Looks like it needs thread local storage now, so Xcode gcc cannot work anymore.

[RJVB]

I reverted the upgrade conditionally, we'll in the future. It wasn't an important one anyway, I just wanted to test something (which didn't work out either).

[barracuda156]

I am trying to build this again with a patch for riscv, will update on this soon.

BTW, the portfile uses a flag for isl, but does not declare a dependency. Should isl be used or not? It seems it is optional, though by default enabled.

[RJVB]

BTW, the portfile uses a flag for isl, but does not declare a dependency. Should isl be used or not? It seems it is optional, though by default enabled.

I didn't find any sign that it is actually used, did you?

[barracuda156]

Configure status did have -lisl flag (on macOS at least), and on Linux build failed initially, complaining about missing isl (which I deactivated because of attempts to build gcc).

UPD. I looked into the macOS log, configure checks for isl, but nothing uses it. So apparently it is used only in components which are disabled on macOS.

[RJVB]

Configure status did have -lisl flag (on macOS at least), and on Linux build failed initially, complaining about missing isl (which I deactivated because of attempts to build gcc).

True, it may be better to remove that argument, or even use the disable form.

[barracuda156]

@RJVB BTW I have fixed the build on riscv for the new version of binutils.

[RJVB]

On Saturday September 21 2024 14:43:45 Sergey Fedorov wrote:

@RJVB BTW I have fixed the build on riscv for the new version of binutils.

How?

[barracuda156]

On Saturday September 21 2024 14:43:45 Sergey Fedorov wrote: @RJVB BTW I have fixed the build on riscv for the new version of binutils. How?

See the patch here: https://github.com/macports/macports-ports/pull/25870

P. S. The code already has fallback, but it cannot work when the build breaks prior to that on a non-existing header.