Page MenuHomeFreeBSD

RFC: Use file-prefix-map to lie about build paths
Needs ReviewPublic

Authored by on Feb 18 2021, 12:22 AM.
Referenced Files
F68479167: D28764.diff
Fri, Sep 29, 1:38 PM
Unknown Object (File)
Wed, Sep 6, 6:45 AM
Unknown Object (File)
Aug 14 2023, 9:52 PM
Unknown Object (File)
Aug 14 2023, 10:22 AM
Unknown Object (File)
Jun 29 2023, 5:11 PM
Unknown Object (File)
Jun 29 2023, 3:43 PM
Unknown Object (File)
Jun 24 2023, 6:46 AM
Unknown Object (File)
May 14 2023, 10:44 AM



Unconditionally remap the cross sysroot to /, so debug information
points to (for example) /usr/include rather than

If MK_REPRODUCIBLE_BUILD is on, then use file-prefix-map to replace
SRCDIR with /usr/src, and OBJDIR with /usr/obj/usr/src. This causes
builds to appear to come from /usr/src and be build from /usr/obj no
matter the real paths.

Diff Detail

rS FreeBSD src repository - subversion
Lint Passed
No Test Coverage
Build Status
Buildable 37145
Build 34034: arc lint + arc unit

Event Timeline

This is a large portion of the userland changes to give consistent debug data path data no matter the source or object directories. There are more reviews coming.

I think this is like to need a ports exp-run.


I'm not a fan of the _libcompat_machine variable name. I think I might write this something like the suggestion.


These lines should go.


I'm not a huge fan of the name either, but.. three hard problems in computer science.

The issue I have with your suggestion is goals. On the high level it's reproducibility, and your suggestion maintains that. But it changes the debug output of the compat builds. I'll use amd64 as an example: with my change, the 32-bit libraries show the path /usr/obj/usr/src/i386.i386/ in their debug data, just as if it were an i386 build. With your suggestion, it gives /usr/obj/usr/src/amd64.amd64/obj-lib32/.

Neither is objectively right or wrong, but I prefer the former.


Agreed, they'll be gone in the next version of this.


Hmm. Looks like I haven't tested this as extensively as I had when I wrote it against 12. The intent was as I describe, but with 14 my output is what your suggestion would do. Looks like I might need to revisit that part :/


We've extended substantially in 13+ so things work quite a bit differently, in particular it's shared between use by Makefile.libcompat and use in libexec/rtld-elf32/Makefile, etc.

Now that I understand what you're proposing here, I think my suggestion is what we want because there are subtle differences between a few libraries built for /usr/lib32 and the native 32-bit ones due to the need to look elsewhere for things like PAM modules. In some cases the differences may be considerably less subtle (e.g., in CheriBSD memcpy uses CHERI instructions when built for lib32, but does so optionally when it's the default ABI).