Why isn't libficl the host copy? Is LIBSTAND defined wrong?

In D2312#42020, @imp wrote:

Why isn't libficl the host copy? Is LIBSTAND defined wrong?

libficl is defined in the Makefile as LIBFICL= ${.OBJDIR}/../../ficl/libficl.a where LIBSTAND is defined in bsd.libnames.mk to be LIBSTAND?= ${DESTDIR}${LIBDIR}/libstand.a. When DESTDIR is unset and LIBDIR is the default it will be /usr/lib/libstand.a.

The dependency on /usr/lib/libstand.a (DPADD) is also wrong, no?

That seems to be how we have done things in other places.

My preferred solution to this is to use the LIBSTAND from OBJDIR if it exists, otherwise fall back to the host one.

The i386 loader used to do this before it's Makefile was rototilled for EFI and this feature was lost.

Sometimes when doing boot loader work you want to build and use a custom libstand from your tree. At other times you don't. Also, you want DPADD to be correct. so I would do a variant of this:

.if exists(${.OBJDIR}/../../../lib/libstand/libstand.a)
LIBSTAND=   ${.OBJDIR}/../../../lib/libstand/libstand.a
.endif

I think this will handle the cross-build case ok while also working well for doing boot loader dev.

(Also, I'm not sure I have the right number of "../" in those lines, but you get the idea)

Another point, during a world build, DESTDIR is not empty for the WMAKE stage so that DPADD will work and depend on the libraries used during the world build. So a make buildworld should use the correct libstand. (If it didn't do this DPADD wouldn't work at all for world builds). How are you building the loader?

I'm building it from within the shell you get from make buildenv TARGET_ARCH=armv6hf. This is common when cross building parts of the tree.

This change looks good to me.

I am confused why 'make buildenv' doesn't work though.

Ah, so 'make buildenv' gets WMAKEENV set, but it doesn't use WMAKE:

WMAKE=          ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f Makefile.inc1 DESTDIR=${WORLDTMP}

DESTDIR is the one thing that doesn't get handled correctly then for 'make buildenv', and so DPADD is broken in general for buildenv (not just for loader, but for everything). It might be worth asking Warner if we could move DESTDIR into WMAKE. That would fix DPADD and bsd.libnames.mk inside of buildenv in the general case. I'm not sure what else it might break though. Alternatively, we could just change buildenv to set DESTDIR explicitly in addition to WMAKEENV.

In D2312#44371, @jhb wrote:

Ah, so 'make buildenv' gets WMAKEENV set, but it doesn't use WMAKE:

@andrew perhaps worth referencing this in a comment in the Makefile itself?