Closed leahneukirchen closed 6 years ago
I will move my current set of packages built to a safe place and then start another cycle of bootstrapping with gcc-8.2 to see how far I get.
Edit: I will also try to update the gcc template to mpfr-4.0.1
at the same time.
Edit2: isl-0.20
won't play with gcc, so I'll go with isl-0.16.1
.
Arch uses isl 0.19.
Ok, I'll go with isl-0.19
then and update isl15
for cross-*
as well.
base-system
and base-devel
built for x86_64
Packages which fail to build OOTB:
loginrec.c: In function 'record_failed_login':
loginrec.c:1687:2: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation]
strncpy(ut.ut_user, username, sizeof(ut.ut_user));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
loginrec.c:1696:2: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation]
strncpy(ut.ut_host, hostname, sizeof(ut.ut_host));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:160: loginrec.o] Error 1
=> ERROR: openssh-7.7p1_2: do_build: '${make_cmd} ${makejobs} ${make_build_args} ${make_build_target}' exited with 2
=> ERROR: in do_build() at common/build-style/gnu-configure.sh:13
**solved with a patch**
const char*
vs. char *
mismatches, e.g.:
main.cpp:246:49: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
mesg("Checksum = %s\n", get_checksum(NULL, 0));
I think we will see several packages failing to build for this reason, as it's a common bug to omit const where it belongs.i686{,-musl}
In file included from gen4_vertex.c:34:
gen4_vertex.c: In function 'emit_vertex':
sna_render_inline.h:40:26: error: inlining failed in call to always_inline 'vertex_emit_2s': target specific option mismatch
static force_inline void vertex_emit_2s(struct sna *sna, int16_t x, int16_t y)
^ ^~~~~~~~~~~~~~~~~~~~~~~~
gen4_vertex.c:360:2: note: in expansion of macro 'OUT_VERTEX'
OUT_VERTEX(dstX, dstY);
^~~~~~
make[4]: [Makefile:690: gen4_vertex.lo] Error 1
make[4]: Leaving directory '/builddir/xf86-video-intel-2.99.917.831/src/sna'
make[3]: [Makefile:709: all-recursive] Error 1
make[3]: Leaving directory '/builddir/xf86-video-intel-2.99.917.831/src/sna'
make[2]: [Makefile:622: all-recursive] Error 1
make[2]: Leaving directory '/builddir/xf86-video-intel-2.99.917.831/src'
make[1]: [Makefile:486: all-recursive] Error 1
make[1]: Leaving directory '/builddir/xf86-video-intel-2.99.917.831'
make: *** [Makefile:418: all] Error 2
=> ERROR: xf86-video-intel-2.99.917.831_2: do_build: '${make_cmd} ${makejobs} ${make_build_args} ${make_build_target}' exited with 2
=> ERROR: in do_build() at common/build-style/gnu-configure.sh:13
disable_parallel_build=yes
**solved with 2 patches**
Is the bumped branch public? Then I can debug locally.
The bumped branch is in my fork's master. The patch works fine and I'll add a commit.
base-chroot{,-musl} for the 4 native architectures is completed. Now building base-system.
Unrelated note: the bootstrap dependency loop between librsvg
and vala
is back or still there. You have to build librsvg
with -o ~vala
first, then build it again to make all dependencies, and finally build with -f
to have a librsvg
with vala
enabled.
librsvg-devel-2.40.20_4 doesn't contain vala stuff here oO.
I guess this should be moved to a separate package then.
The vala stuff resides in librsvg, where it doesn't belong.
due to a typo: $build_options_vala
cross-arm-none-eabi needs a fix for the patch to enable multiarch. I tried it, but it fails because of some part of the build requiring hard float for arm? I guess that needs to be fixed by its maintainer @teajay-fr .
architecture | packages built |
---|---|
aarch64-musl | 1815 |
aarch64 | 1873 |
armv5tel-musl | 1042 |
armv5tel | 890 |
armv6l-musl | 1785 |
armv6l | 1886 |
armv7l-musl | 1791 |
armv7l | 1895 |
i686-musl | 4448 |
i686 | 4655 |
mips-musl | 2896 |
mipsel-musl | 2912 |
mipselhf-musl | 2923 |
mipshf-musl | 2928 |
x86_64-musl | 4523 |
x86_64 | 7499 |
noarch | 2000 |
@chneukirchen I don't understand. srcpkgs/librsvg/template
has if [ "$build_option_vala" ]; then
which should be right, no? Yet there is no usr/share/vala
data in librsvg-devel
... strikes me a bit odd.
No, the variable is spelt wrong with an s
.
New issue with linux4.14 and plugins:
Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support plugins, perhaps the necessary headers are missing?
make: *** [scripts/Makefile.gcc-plugins:70: gcc-plugins-check] Error 1
=> ERROR: linux4.14-4.14.61_1: do_build: 'make ARCH=$arch ${_version} ${_cross} ${makejobs} prepare' exited with 2
=> ERROR: in do_build() at srcpkgs/linux4.14/template:95
IMHO we really should get rid of the plugin stuff for the kernels.
Yes, let's do it.
Live images for testing.
I didn't get time to look into the issue you mentioned about the cross-arm-none-eabi. Is the issue still present ? I will find some time in the next days to look into it.
@teajay-fr : no problem. The package is marked as broken for the update, so it will be built only after you found time to do whatever is necessary to build it for gcc-8.2.0.
Can we fallback to disable GCC plugins only in case of errors?
@thypon I guess you meant to add --enable-plugins
to gcc's template? I think that's ok. Opinions?
Edit: Updated #1650 to include --enable-plugins
. Do you also need it for the cross compilers?
Mission accomplished. Except for the aarch64 builders which need to be kicked to build gcc-8.2.0 for the host first. cc @chneukirchen
TODOs:
mozc
build with GCC 8.2cross-vpkg-dummy also needs a host build on the aarch64 builders
This issue resumes https://github.com/voidlinux/void-packages/issues/14633.
gcc 8.2 is out now, and we should see which remaining packages are broken and how to fix them.