[PATCH] env: another attempt at fixing SPL build failures

[Tom Rini]

On Fri, Jan 10, 2020 at 02:28:54PM +0000, Rasmus Villemoes wrote:
> On 15/12/2019 23.29, Rasmus Villemoes wrote:
> > I'm also seeing the build failure that commit
> > 
> > 7d4776545b env: solve compilation error in SPL
> > 
> > tried to fix, namely that the reference to env_flags_validate from
> > env_htab cannot be satisfied when flags.o is not built in. However,
> > that commit got reverted by
> > 
> > d90fc9c3de Revert "env: solve compilation error in SPL"
> > 
> > Necessary, but not sufficient conditions to see this are
> > 
> > CONFIG_SPL=y (obviously)
> > CONFIG_SPL_ENV_SUPPORT=n (so flags.o does not get compiled)
> > CONFIG_SPL_LIBCOMMON_SUPPORT=y (so env/built-in.o is part of the SPL link)
> > 
> > Now, these are satisfied for e.g. imx6q_logic_defconfig. But that
> > builds just fine, and spl/u-boot-spl.map lists .data.env_htab among
> > the discarded (garbage collected) sections. Yet, on our
> > mpc8309-derived board, we do see the build failure, so perhaps the
> > linker works a bit differently on ppc than on ARM, or there's yet some
> > other configuration option needed to observe the break.
> 
> Yeah, I think this is a difference in how the linker works on ppc vs
> arm. Doing
> 
> git grep --files-with-matches SPL=y -- configs/ | xargs grep
> --files-with-matches SPL_LIBCOMMON_SUPPORT=y | xargs grep
> --files-without-match SPL_ENV_SUPPORT | xargs head -n1
> 
> shows that all the in-tree defconfigs with the above combination are ARM
> boards (except for microblaze_defconfig, but I don't have such a
> toolchain), and they most likely all build just fine. But taking some
> random PPC config (say T2080QDS_NAND_defconfig) with the first and third
> point, and then manually disabling SPL_ENV_SUPPORT, immediately shows
> the break.
> 
> For reference, I have
> 
> $ ${CROSS_COMPILE}ld --version
> GNU ld (GNU Binutils for Ubuntu) 2.30

Which SPL are you using on PowerPC?  There's the one based
CONFIG_SPL_FRAMEWORK and the one that's not.  I suspect it's a framework
vs not problem here rather than linker exactly.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200110/bb480667/attachment.sig>