DESCRIPTION:
Using gcc-6.2.0 to build binutils-2.39 (current maneage 4318670) leads to a fatal error

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D_GNU_SOURCE -I. -I./../include -I./../bfd -I../bfd -DNOBFD=0 -I/BUILD/software/installed/include -std=gnu99 -Wall -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long -I./../zlib -I/opt/exp_soft/local/generic/gcc/6.2.0/include -MT libctf_la-ctf-dump.lo -MD -MP -MF .deps/libctf_la-ctf-dump.Tpo -c ctf-dump.c -o libctf_la-ctf-dump.o
jprofile.c:33:19: fatal error: jvmti.h: No such file or directory
 #include <jvmti.h>
                   ^
compilation terminated.
make[6]: *** [Makefile:723: libgp_collector_la-jprofile.lo] Error 1

This appears to be the result of trying to build 'gprofng' ("gnu profiler next generation"), which is in the current version (2.39) of the basic level package 'binutils', because building gprofng depends on a java header file 'jvmti.h'.

ANALYSIS:
Newer gcc versions apparently find some way of building gprofng without needing this external java dependence. This is not a solution to the bug, because we don't want people with an older host gcc version, such as 6.2.0, to have to downgrade binutils.

PROPOSED FIX:
Based on our reproducibility criteria, favouring builds that work on both newer and older host systems is a higher priority than enabling fashionable new tools, especially at the stage of building 'basic' tools. Moreover, even if some fields of research might use java as a high-level language, profiling the code does not need to be done within maneage itself.

So the fix proposed here is to disabled the build of 'gprofng' in the build rule for 'binutils' in 'basic.mk', i.e. by adding '--enable-gprofng=no' to the build rule. This is implemented in commit c0e30c1 [1].

Users knowing how to do profiling will have the skills to override this build rule.


[1] https://codeberg.org/boud/maneage_dev/commit/c0e30c18accec36737532080223031ed4f76619d