For example, check:
The i686 one doesn't have any sources inside while latter has. I've noticed this during mass rebuild because multiple pascal packages started to fail with:
noarch-20742364/i386-20742462/build.log:error: Empty %files file /builddir/build/BUILD/ccdciel-0.8.16/debugsourcefiles.list
So it seems it was broken forever (I checked some builds from f23 era) and now we fail on such packages ;)
Note that this breakage is also on armv7hl, too. It's not exclusive to i686.
Blocking respective SIGs affected (arm and i686 ones).
I've been able to fix the "Empty %files file" in one of my package (ccdciel) by changing fpc compiler options to "-O1 -gw3" (the -01 was already set, I changed -g -gl to -gw3).
I'm not expert in compiler options, so I ask you if this can be the right solution.
This is the failed rebuild:
And this is the successful scratch build:
(In reply to Mattia Verga from comment #3)
> I've been able to fix the "Empty %files file" in one of my package (ccdciel)
> by changing fpc compiler options to "-O1 -gw3" (the -01 was already set, I
> changed -g -gl to -gw3).
> I'm not expert in compiler options, so I ask you if this can be the right
I'm not expert in fpc, so I can't help here :( I'm still wondering why on non-32bit arches it behaved correctly..
Simple: there are multiple debug-formats. Nowadays Dwarf is the de-facto standard (oss), but in the past this was stabs. There is no 64-bit definition of the stabs-format, so the default debug-format of fpc on 64-bit systems is Dwarf.
Problem is that gdb does not support all of the Dwarf-specs which are needed to debug things like dynamic arrays, Pascal string-types and such. As a compromise, the default debug-format is stabs on 32-bit systems. Yes, the Dwarf-format is better, but GDB can't handle it. At least not in the way FPC uses it. Note that there has been a lot of work on gdb, also from some Redhat employees to solve these issues.
Probably the problem is that the rpm-tools do not recognize, or ignore, the stabs-debug information.
So, two solutions: adapt those tools, or switch to Dwarf (-gw3) debug-information by default on Fedora.
Maybe the latter idea is not so bad, Fedora ships with a heavily patched version of gdb which solves the largest problems. (At least it did in the past, did not check recently)
Otoh, I think that those people who wrote those tools would like the input of another compiler to test their code. But maybe they skip stabs on purpose...
I do not think rpmbuild should care about stabs, that is deprecated format.
But 32-bit systems are also deprecated so I do not see much what is the concern here.
64-bit support for DWARF may have some issues between FPC and GDB but that is outside of the scope of rpmbuild so it is IMO outside of the scope of this Bug.
I would switch FPC 32-bit to behave the same as 64-bit as 32-bit is dead anyway and any difference just makes more issues nobody cares about.
So can we get FPC flipped to dwarf debuginfo generation please?
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.
More information and reason for this action is here:
fpc-3.0.2-4.fc27 lazarus-1.8.0-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b6e484dff7
fpc-3.0.2-4.fc27, lazarus-1.8.0-4.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-b6e484dff7
fpc-3.0.2-4.fc27, lazarus-1.8.0-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.