|Summary:||app-crypt/heimdal has parallel make issues|
|Product:||Gentoo Linux||Reporter:||Diego Elio Pettenò (RETIRED) <flameeyes>|
|Component:||New packages||Assignee:||Gentoo Kerberos Maintainers <kerberos>|
|Severity:||normal||CC:||jstein, mmokrejs, plevine457|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Diego Elio Pettenò (RETIRED) 2008-11-15 13:54:26 UTC
Check the attached build log, this happens with -j14.
Comment 1 Diego Elio Pettenò (RETIRED) 2008-11-15 13:54:48 UTC
Created attachment 171812 [details] Build log
Comment 2 Michael Hammer (RETIRED) 2008-11-17 07:19:48 UTC
The problem is that I'm not able to reproduce the problem. Did you have mit-krb5 installed on this machine before emerging heimdal? Do you use distcc - I mean -j14 are really a lot of compile units (btw - I have a test installation x86 in a vbox using distcc and -j10 for compilation - no issues here). g, mueli
Comment 3 Diego Elio Pettenò (RETIRED) 2008-11-17 07:48:17 UTC
distcc does not influence installs, you need a truly multi-way system to test parallel install. Here it's running -j14 on an 8-way.
Comment 4 Michael Hammer (RETIRED) 2008-11-17 08:29:48 UTC
What do you mean by "installs" - Your compilation is dying during compiling "/var/tmp/portage/app-crypt/heimdal-1.2.1-r1/work/heimdal-1.2.1/lib/krb5". The line ./krb5.h:43:22: error: krb5_err.h: No such file or directory tastes a bit like you have a krb5.h on your system left from a mit-krb5 install. Therefore my question once again: "Did you have mit-krb5 installed on this machine before emerging heimdal?" An krb5.h in any global include directory wins over the local krb5.h of heimdal during compile. Please check the situation. I am pretty sure that the issue isn't related to parallel build but I might be wrong of course. g, mueli
Comment 5 Diego Elio Pettenò (RETIRED) 2008-11-17 10:07:33 UTC
Oh sorry I confused this bug with another, my fault :/ It's possible mit-krb5 was in the system, I'm building every package in tree so I can't easily tell what was in before, I'll check the emerge log and let you know.
Comment 6 Michael Hammer (RETIRED) 2008-11-17 11:32:05 UTC
Ok, thx. But if mit-krb5 was in system before and the emerge fails it's still a bug I have to fix ... seams really strange to me. Would be nice if we can investigate a procedure for reproduction of the problem so that I can test and fix it myself. greets, mueli
Comment 7 Björn 2008-12-02 22:46:57 UTC
i got the same problem some time ago, but wasn't able to reproduce it. the problem is the use of libcom_err and compile_et to create some of the header files including krb5_err.h. i will try to write a patch for that as soon as possible. for now, please use -j1 to avoid the bug.
Comment 8 Diego Elio Pettenò (RETIRED) 2008-12-03 21:27:50 UTC
The problem is in cf/Makefile.am.common .et.h: $(COMPILE_ET) $< .et.c: $(COMPILE_ET) $< This causes double generation of everything, instead the .h should depend on the .c file, and the .c on .et, so that only one call is present.
Comment 9 Martin Mokrejš 2010-08-18 19:49:42 UTC
(In reply to comment #8) > The problem is in cf/Makefile.am.common > > .et.h: > $(COMPILE_ET) $< > .et.c: > $(COMPILE_ET) $< > > This causes double generation of everything, instead the .h should depend on > the .c file, and the .c on .et, so that only one call is present. Aren't the compile_et binaries gone now with heimdal-1.3? Remember the file collisions with sys-libs/e2fsprogs-libs?
Comment 10 Peter Levine 2022-12-12 01:48:34 UTC
Very old bug. It looks like it might have been been reported with https://github.com/heimdal/heimdal/issues/17 and fixed with https://github.com/heimdal/heimdal/commit/be5afdbf7f9b765e791e7d625cc6b694e088f42a
Comment 11 Sam James 2022-12-12 01:50:59 UTC
Thanks, that sounds plausible.