Committed in rS339451
Do I read this correctly that once this is applied, the lang/gcc* ports should be bootstrapping fine again?
Fri, Oct 19
If needed, I can skip documenting the -b/-l flags so we could remove them later if we decide to use consistent-endian locale data.
Our comments crossed paths.
@sbruno asked on IRC for me to clarify, so - I don't object to this change, it is definitely a fix and I'd be happy to see this fixed vs status quo. Also, we have strong arguments for being able to share pwd files across machines (potentially of different endianness) that might not apply to locale data.
FWIW I have a small preference for maintaining the approach taken in rS308170 but extending/fixing it for all archs - have the on-disk data in a consistent endianness. See the progression of pwd_mkdb ending with commits rS332902, rS333133 (D15144).
Incorporate fix from kaiw
Thu, Oct 18
Dynamic symtab fix from @kaiw
Not supporting .ctors could be a problem when linking objects created with different compilers, e.g. a static library built with gcc, but linked through clang.
Wed, Oct 17
Tue, Oct 16
Mon, Oct 15
Sun, Oct 14
Sat, Oct 13
Compare with D2808
For reference, this was found while developing WIP to introduce ifunc userland support, and in particular for static binaries.
Fri, Oct 12
Tried again, and it works for me.
Thu, Oct 11
I tried something similar locally and (some of) the patches in files/ did not apply, but perhaps I just missed something.
Wed, Oct 10
Tue, Oct 9
Perhaps a topic for discussion at the Vendor/Dev Summit next week
As discussed elsewhere there are a few toolchain issues with static binaries with ifuncs - one fix is in https://github.com/emaste/freebsd/commit/36131f9c4c9aa343ea2679c18b3d1d621bb837f1
- remove extra blank line
- include Makefile change
Sat, Oct 6
Fri, Oct 5
Put in crtbrand.c as kib suggests
Thu, Oct 4
Wed, Oct 3
think that it would cause more resistance than the amd64 hack