Re: bad package build of gcc10

[Greg Troxel <gdt%lexort.com@localhost>]

"John D. Baker" <jdbaker%consolidated.net@localhost> writes:

> On Mon, 21 Oct 2024, John D. Baker wrote:
>
>> Not netbsd-10 and gcc10, but I'm seeing the same failure with gcc12 on
>> -current/amd64 (10.99.12).
>> 
>> I had built with "-j 5", MAKE_JOBS=5 (4-core CPU).
>> 
>> Now trying a build with "-j 1" (MAKE_JOBS=1).
>
> The MAKE_JOBS=1 build completed without the complaints about the missing
> required libraries (which the package actually provides).

So it seems there is a bug in "gccN + mk" somewhere, and as a result
gccN is not MAKE_JOBS_SAFE, at leaset on NetBSD.

It's also a bug in pkgsrc infrastructure that packages are created (even
with PKG_DEVELOPER=yes) that pkg_install will not install.

> It seems, however, that for some reason there was no previously-installed
> build of gcc12, so 'make replace' failed.  'make package-install' did
> not provoke any complaints.

I don't know why you were expecting a previous gcc12, but indeed make
replace prints an error if not.  This part seems entirely expected and
unremarkable, so I wonder if something else happened.

I have found that "pkg_add -u", when the shlib check fails, will remove
the previous package and not install the new one.  That's also a bug in
pkg_add, which should IMHO basically

  BEGIN TRANSACTION
  REMOVE
  INSTALL
  REPOINT DEPS
  END TRANSACTION

and end up either in an ok new state or not do anything.  That's of
course way too hard, but basicaly all the checks about not liking a
package should happen before removal.  That's surely not new with the
new check; it's just making the problem more obvious.

> After the MAKE_JOBS=5 build failed, I manually ran "make MAKE_JOBS=1
> replace package clean" and although it failed because there was no
> gcc12-foo package to replace, it didn't complain about missing required
> libraries, but I suspect that was because it failed checking for a
> previously-installed gcc12-foo package rather than checking the just-
> built gcc12 prior to the attempted replacement.

This is hard to follow.  If gcc12 is not installed, because it never
was, or because pkg_add -u buggily removed it when failing to update,
make replace isn't going to work.

(Because of people that dislike make replace, it's unhelpful to drag in
make replace to any discussion which is not actually about make replace,
because then those people ignore it.  Please try to reduce to simpler
commands, like 'make package' and then 'pkg_add -u
/path/to/built/package' or without -u if not installed.)


Thanks for doing the experiment; this confirms it isn't just something
damaged on my systems.


I ran a build of gcc10 with a number of MAKE_JOBS values, with pkgsrc
head.  Here's the output of pkg_add -u with each.

-rw-r--r--  1 gdt  wheel    0 Oct 20 10:18 OUT.package.1.install
-rw-r--r--  1 gdt  wheel  252 Oct 20 11:34 OUT.package.2.install
-rw-r--r--  1 gdt  wheel    0 Oct 20 21:13 OUT.package.3.install
-rw-r--r--  1 gdt  wheel    0 Oct 20 12:17 OUT.package.4.install
-rw-r--r--  1 gdt  wheel  252 Oct 20 21:52 OUT.package.5.install
-rw-r--r--  1 gdt  wheel    0 Oct 20 22:26 OUT.package.7.install
-rw-r--r--  1 gdt  wheel  252 Oct 20 12:50 OUT.package.8.install
-rw-r--r--  1 gdt  wheel  252 Oct 20 22:57 OUT.package.9.install
-rw-r--r--  1 gdt  wheel  252 Oct 20 07:59 OUT.package.12.install

My read is that there is a -j bug that is increasingly likely to be hit
with higher MAX_JOBS, and that it never happens with -j1.
Contrary evidence welcome of course.