Page MenuHomeFreeBSD

Use the correct copy of libstand
ClosedPublic

Authored by andrew on Apr 17 2015, 2:56 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Oct 28, 3:36 AM
Unknown Object (File)
Sep 22 2024, 1:34 PM
Unknown Object (File)
Sep 22 2024, 10:54 AM
Unknown Object (File)
Sep 22 2024, 3:26 AM
Unknown Object (File)
Sep 22 2024, 12:53 AM
Unknown Object (File)
Sep 21 2024, 3:52 PM
Unknown Object (File)
Sep 19 2024, 1:32 AM
Unknown Object (File)
Sep 18 2024, 11:09 PM
Subscribers

Details

Reviewers
emaste
jhb
imp
Summary

When cross-building ${LIBSTAND} may be set to the host copy. This switches
to the guest version.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage

Event Timeline

andrew retitled this revision from to Use the correct copy of libstand.
andrew updated this object.
andrew edited the test plan for this revision. (Show Details)
andrew added reviewers: emaste, imp.
andrew added a subscriber: gjb.

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?

andrew edited edge metadata.

Use ${.OBJDIR}/../../../../lib/libstand/libstand.a

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.

jhb added a reviewer: jhb.

I'm accepting this because I've used this for EFI debugging when you aren't using buildenv, but I still think we should consider fixing buildenv.

This revision is now accepted and ready to land.May 1 2015, 1:38 PM
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?