From 1.0.1 ./configure --help output: --enable-cxx-exceptions use libunwind to handle C++ exceptions --enable-debug-frame Load the ".debug_frame" section if available --enable-block-signals Block signals before performing mutex operations --enable-conservative-checks Validate all memory addresses before use --enable-msabi-support Enables support for Microsoft ABI extensions maybe it'd be nice to expose this as use flags, or default enable them for sure, cxx-exceptions is disabled here, and with it enabled i could build libcxxrt on top of libunwind and get rid of the gpl-3 libgcc_s dep for the whole libc++ stack.
So your motivation for filing this bug is entirely LICENSE related for userland_BSD? Not everything is deserving a USE flag, and staying with close to upstream ./configure defaults sounds sane. Mostly, only options that expose external dependencies should be with USE flag.
(In reply to comment #1) > So your motivation for filing this bug is entirely LICENSE related for > userland_BSD? not really; motivation in the long term is to have a gcc-less freebsd, yes; it is far from being possible but a libc++ stack not depending on gcc libs is a step. if that were only for bsd, i could just build what they imported from freebsd-lib, but imho making it possible to have clang not depending on gcc has nothing freebsd-specific. > Not everything is deserving a USE flag, and staying with close to upstream > ./configure defaults sounds sane. upstream defaults depend on $host, which is clearly a no go for us: if i need cxx-exception support, how do i depend on that ? moreover, their defaults might change with time, so this gets really messy to get the deps. > Mostly, only options that expose external dependencies should be with USE > flag. Im sure you can find plenty of examples where this is not the case :) anyway, i dont wanna argue if this needs a useflag or not, that's why i suggested enabling them within the ebuild.
thinking more about it, these flags seem to break the ABI, so its definitely not a good idea to expose them without masking or forcing the useflags... since, at least the cxx-exceptions stuff are declared in the installed headers and, depending on the host, built or not in the shared library, i guess we could just always build them and be safe.
cxx-exceptions is fine by me does debug-frame affect the ABI ? doesn't seem like it should. block-signals doesn't affect the ABI, but does affect the API. i think we should leave that alone until someone complains. conservative-checks could be useful under USE=debug
(In reply to comment #4) > cxx-exceptions is fine by me > > does debug-frame affect the ABI ? doesn't seem like it should. doesnt seem to, at least nm -D --defined-only output is the same > > block-signals doesn't affect the ABI, but does affect the API. i think we > should leave that alone until someone complains. yep > > conservative-checks could be useful under USE=debug and yep
Created attachment 313705 [details, diff] proposed ebuild patch
Comment on attachment 313705 [details, diff] proposed ebuild patch LGTM; feel free to commit
(In reply to comment #7) > LGTM; feel free to commit done
