#1119241 ippl: FTBFS when built with many parallel jobs

Package:
src:ippl
Source:
src:ippl
Submitter:
John Paul Adrian Glaubitz
Date:
2025-11-20 11:29:01 UTC
Severity:
normal
Tags:
#1119241#5
Date:
2025-10-28 08:11:21 UTC
From:
To:
Hi,

ippl fails to build from source on loong64 and sparc64 when built with
many parallel jobs:

bison -y -d ippl.y
flex ippl.l
gcc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/reproducible-path/ippl-1.4.14=. \
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -O2 -Wdate-time -D_FORTIFY_SOURCE=2 \
-Wall -DVERSION=\"1.4.14\" -DDEFAULT_USER=\"nobody\" -DCONFIGURATION_FILE=\"/etc/ippl.conf\" \
-DPID_FILE=\"/run/ippl/ippl.pid\" -c pidfile.c
make[2]: Leaving directory '/build/reproducible-path/ippl-1.4.14/Docs'
gcc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/reproducible-path/ippl-1.4.14=. \
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -O2 -Wdate-time -D_FORTIFY_SOURCE=2 \
-Wall -DVERSION=\"1.4.14\" -DDEFAULT_USER=\"nobody\" -DCONFIGURATION_FILE=\"/etc/ippl.conf\" \
-DPID_FILE=\"/run/ippl/ippl.pid\" -c ident.c
gcc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/reproducible-path/ippl-1.4.14=. \
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -O2 -Wdate-time -D_FORTIFY_SOURCE=2 \
-Wall -DVERSION=\"1.4.14\" -DDEFAULT_USER=\"nobody\" -DCONFIGURATION_FILE=\"/etc/ippl.conf\" \
-DPID_FILE=\"/run/ippl/ippl.pid\" -c lex.yy.c
pidfile.c: In function ‘read_pid’:
pidfile.c:48:3: warning: ignoring return value of ‘fscanf’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
   48 |   fscanf(f,"%d", &pid);
      |   ^~~~~~~~~~~~~~~~~~~~
pidfile.c: In function ‘write_pid’:
pidfile.c:97:7: warning: ignoring return value of ‘fscanf’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
   97 |       fscanf(f, "%d", &pid);
      |       ^~~~~~~~~~~~~~~~~~~~~
ippl.l:28:10: fatal error: y.tab.h: No such file or directory
   28 | #include "y.tab.h"
      |          ^~~~~~~~~
compilation terminated.

This is reproducible on stadler.debian.net when building with parallel=16 or more while it works with parallel=8.

Works:

$ export DEB_BUILD_OPTIONS="check bench parallel=8" ; dpkg-buildpackage -B

Doesn't work:

$ export DEB_BUILD_OPTIONS="check bench parallel=16" ; dpkg-buildpackage -B

The problems reminds me of a bug that was fixed in the samba package in 2:4.17.2+dfsg-9 [1].

I had hoped to be able to reproduce it with the new "--shuffle" option of make [2][3] but
that's not the case, unfortunately.

Thanks,
Adrian

#1119241#10
Date:
2025-10-28 09:43:23 UTC
From:
To:
Control: tags -1 help
thanks

I don't have the slightest idea how to address this. ippl doesn't
contain more than 10 .c files in the first place.

y.tab.h looks like its created during build, so it might be a simple
Makefile issue. Tagging the bug help.

Greetings
Marc

#1119241#15
Date:
2025-10-28 09:43:23 UTC
From:
To:
Control: tags -1 help
thanks

I don't have the slightest idea how to address this. ippl doesn't
contain more than 10 .c files in the first place.

y.tab.h looks like its created during build, so it might be a simple
Makefile issue. Tagging the bug help.

Greetings
Marc

#1119241#20
Date:
2025-10-28 10:53:54 UTC
From:
To:
Anecdotally, such failures are generally more visible on system which
have both a "slow" single-thread execution paired with very high parallelization.

ippl/Source/Makefile.in has

```
y.tab.c: ippl.y Makefile ../Makefile.common
        $(YACC) -d $<

lex.yy.c: ippl.l Makefile ../Makefile.common
        $(LEX) $<
```

and it probably should look like this

```
y.tab.h: ippl.y
	$(YACC) -d $<

y.tab.c: y.tab.h

lex.yy.c: ippl.l y.tab.h
	$(LEX) $<
```

#1119241#25
Date:
2025-10-28 10:53:54 UTC
From:
To:
Anecdotally, such failures are generally more visible on system which
have both a "slow" single-thread execution paired with very high parallelization.

ippl/Source/Makefile.in has

```
y.tab.c: ippl.y Makefile ../Makefile.common
        $(YACC) -d $<

lex.yy.c: ippl.l Makefile ../Makefile.common
        $(LEX) $<
```

and it probably should look like this

```
y.tab.h: ippl.y
	$(YACC) -d $<

y.tab.c: y.tab.h

lex.yy.c: ippl.l y.tab.h
	$(LEX) $<
```

#1119241#30
Date:
2025-10-28 11:52:14 UTC
From:
To:
Hi Jan,

Yeah, I assumed something like and indeed your patch fixes the problem.

Can you send it as a patch and attach it to the bug tracker?

Thanks,
Adrian

#1119241#35
Date:
2025-10-28 11:52:14 UTC
From:
To:
Hi Jan,

Yeah, I assumed something like and indeed your patch fixes the problem.

Can you send it as a patch and attach it to the bug tracker?

Thanks,
Adrian

#1119241#40
Date:
2025-10-28 11:54:11 UTC
From:
To:
Hi Marc,

The proposed patch by Jan fixes the problem:
--- ippl-1.4.14.orig/Source/Makefile.in +++ ippl-1.4.14/Source/Makefile.in @@ -47,10 +47,12 @@ $(TARGET): $(OBJS) %.o: %.c Makefile ../Makefile.common $(CC) $(CFLAGS) $(CPPFLAGS) $(WARNINGS) $(DEFINES) -c $<
#1119241#47
Date:
2025-10-28 11:54:18 UTC
From:
To:
no need, I can pick it up from here.

Thanks for helping THAT fast!

Greetings
Marc

#1119241#52
Date:
2025-10-28 11:54:11 UTC
From:
To:
Hi Marc,

The proposed patch by Jan fixes the problem:
--- ippl-1.4.14.orig/Source/Makefile.in +++ ippl-1.4.14/Source/Makefile.in @@ -47,10 +47,12 @@ $(TARGET): $(OBJS) %.o: %.c Makefile ../Makefile.common $(CC) $(CFLAGS) $(CPPFLAGS) $(WARNINGS) $(DEFINES) -c $<
#1119241#55
Date:
2025-10-28 11:54:11 UTC
From:
To:
Hi Marc,

The proposed patch by Jan fixes the problem:
--- ippl-1.4.14.orig/Source/Makefile.in +++ ippl-1.4.14/Source/Makefile.in @@ -47,10 +47,12 @@ $(TARGET): $(OBJS) %.o: %.c Makefile ../Makefile.common $(CC) $(CFLAGS) $(CPPFLAGS) $(WARNINGS) $(DEFINES) -c $<
#1119241#60
Date:
2025-11-20 11:24:56 UTC
From:
To:
Hello maintainer,

Do you have plan to upload the next version of ippl? Thanks.

On Tue, 28 Oct 2025 12:54:18 +0100 Marc Haber wrote:

 > On Tue, Oct 28, 2025 at 12:52:14PM +0100, John Paul Adrian Glaubitz
wrote:
 > >Can you send it as a patch and attach it to the bug tracker?
 >
 > no need, I can pick it up from here.
 >
 > Thanks for helping THAT fast!
 >
 > Greetings
 > Marc

Best regards,
Dandan Zhang