Makefile.cross: ppc64le compiles fail due to 'depmod' error
This was reported in
Even with these fixes I get a strange depmod error that is unrelated to the fixing of the Makefile:
+ depmod -b . -aeF ./System.map 6.5.0-0.rc2.17.test.fc38.ppc64le
+ '[' -s depmod.out ']'
+ echo 'Depmod failure'
Depmod failure
+ cat depmod.out
depmod: WARNING: /root/rpmbuild/BUILDROOT/kernel-6.5.0-0.rc2.17.test.fc38.ppc64le/./lib/modules/6.5.0-0.rc2.17.test.fc38.ppc64le/kernel/drivers/ptp/ptp_dfl_tod.ko needs unknown symbol __dfl_driver_register
depmod: WARNING: /root/rpmbuild/BUILDROOT/kernel-6.5.0-0.rc2.17.test.fc38.ppc64le/./lib/modules/6.5.0-0.rc2.17.test.fc38.ppc64le/kernel/drivers/ptp/ptp_dfl_tod.ko needs unknown symbol dfl_driver_unregister
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.97Xt7z (%build)
The other arches seem to build correctly. I'm digging into this and will submit another MR to resolve it.
That is odd. fpga is one of the driverdirs for filter-ppc64le.sh.fedora and ptp_dfl_tod is in the singlemods list so they should both be in the same place; there are not any overrides.
Is cross-compiling using the right filter file?
Jumping in here to do some advertisement for an issue I recently filed that up to now didn't get a single reply:
These needs unknown symbol problems seem to happen often enough to be somewhat annoying to some of us afaics. That's why I started to wonder if we could partly automate moving modules into a sesperate package that depend on something that is moved there.
That made me find existing code in another code-path used in the spec file that afaics walks the list of modules and moves those over that depend on something that is moved over. But it's kinda broken. See #121 for details; maybe once we get this to work in that code path and could used it for the filter case as well. Of course carefully (e.g. it should still fail if said code would have to move lot's of modules)