[OpenPower-Firmware] sbe fails to build, parsAndCutElf.py should be objcopy?

[Stewart Smith]

On Tue, Feb 2, 2021, at 9:51 AM, Klaus Heinrich Kiwi wrote:
> On 1/24/2021 11:11 PM, Stewart Smith wrote:
> > On Fedora 33 (x86-64) current op-build (and v2.6) fails to build in the SBE code as it errors out in src/build/parsAndCutElf.py
> > 
> > Even with the below "fix" I still end up getting errors as we hit the
> >      if( (startSize == 0) or (endSize == 0)):
> >          exit(-1)
> > chunk later. So... I'm trying to work out what this script does that couldn't be achieved with objcopy.
> > 
> > Anyone have any ideas?
> 
> Apologies for not answering earlier. I was only able to look at this today..
> 
> 
> > --- a/src/build/parsAndCutElf.py
> > +++ b/src/build/parsAndCutElf.py
> > @@ -44,7 +45,11 @@ def parserElf(argv):
> >       cmd = "readelf -S "+SBE_OUT
> >       firstSection = ".header"
> >       cmd1 = "nm "+SBE_OUT+" | grep  _sbe_image_size"
> > +    print("cmd = {}".format(cmd))
> > +    print("cmd1 = {}".format(cmd1))
> >       output = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE)
> > +    startSize = 0
> > +    endSize = 0
> >       i = 0;
> >       for line in output.stdout:
> >           line = str(line.strip())
> > 
> > 
> 
> Good news is that the issue above is caused because parsAndCutElf is 
> calling readelf from the distro,
> while also using a LD_LIBRARY_PATH to pass the buildroot host library 
> dir.. NORMALLY those would be
> similar, and that's why this was never a problem.. Until Fedora 33 
> decided to link readelf with
> openssl and kerberos libraries for some reason (??) and now the distro 
> readelf can't find those
> libraries in the buildroot host dir, which breaks readelf, which breaks 
> the python script.
> 
> So the patch below fixes it:
> 
> diff --git a/openpower/package/sbe/sbe.mk b/openpower/package/sbe/sbe.mk
> index 2f6d5b4b..59d7dfe4 100644
> --- a/openpower/package/sbe/sbe.mk
> +++ b/openpower/package/sbe/sbe.mk
> @@ -14,8 +14,7 @@ SBE_INSTALL_IMAGES = YES
>   SBE_INSTALL_TARGET = NO
> 
>   define SBE_BUILD_CMDS
> -       SBE_COMMIT_ID=$(SBE_VERSION) $(MAKE) -C $(@D) \
> -               LD_LIBRARY_PATH=$(HOST_DIR)/usr/lib \
> +       SBE_COMMIT_ID=$(SBE_VERSION) $(HOST_MAKE_ENV) $(MAKE) -C $(@D) \
>                  CROSS_COMPILER_PATH=$(PPE42_GCC_BIN) \
>                  all
>   endef

That seemed to not fix it for me. Building a tree with that fix still elicits the same error, even with the fixed python patch I included originally.

 Generating /home/stewart/op-build/output/build/sbe-5799af7203689edc9590544b520595f05d9ce7ca/images/sbe_seeprom_DD2.out
readelf: symbol lookup error: /lib64/libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b
219040
make[3]: *** [Makefile:165: output_sbe_image] Error 255
make[2]: *** [Makefile:181: all] Error 2
make[2]: Leaving directory '/home/stewart/op-build/output/build/sbe-5799af7203689edc9590544b520595f05d9ce7ca/src/build'
make[1]: *** [Makefile:39: axone] Error 2
make[1]: *** Waiting for unfinished jobs....
readelf: symbol lookup error: /lib64/libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b
219760
make[3]: *** [Makefile:165: output_sbe_image] Error 255
make[2]: *** [Makefile:181: all] Error 2
make[2]: Leaving directory '/home/stewart/op-build/output/build/sbe-5799af7203689edc9590544b520595f05d9ce7ca/src/build'
make[1]: *** [Makefile:36: DD2] Error 2
make[1]: Leaving directory '/home/stewart/op-build/output/build/sbe-5799af7203689edc9590544b520595f05d9ce7ca'
make: *** [package/pkg-generic.mk:250: /home/stewart/op-build/output/build/sbe-5799af7203689edc9590544b520595f05d9ce7ca/.stamp_built] Error 2
make: Leaving directory '/home/stewart/op-build/buildroot'

> Bad news is that SBE is (as you're well aware) an 'interesting' mix of 
> using host and ppe-specific
> toolchains, and to make things worse there's apparently no consistency 
> on finding what toolchain
> is needed for what. So fixing this so that we'd only ever use 
> buildroot-provided tools instead of distro-provided, so we better 
> insulate in the future against similar things, is a non-trivial task.

It seems pretty fundamental to correctly doing cross compilation :)

Any further ideas?

It looks like the straight readelf invocation here is the issue, and that it should instead be looking at running one that's in the buildroot built toolchain.

> Re your question on objcopy, I don't see a reason why it couldn't be 
> used (even if it would still be
> subject to the LD_LIBRARY_PATH thing), but I'll add SBE folks on cc 
> just in case.

Any further thoughts on this?