You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#1120 changed the way stdbuf works to embed the .so inside of the binary. This, however, has some notable cons, such as:
Distro packaging tooling can't access the inner .so, which means things like post-build stripping or dependency scanning or anything else won't run on it. This makes it effectively impossible to do a build with debug info and pull the debug information out for external use after the build completes. (We hit this internally which led to an investigation as to what was going on exactly with the strip process.)
$TMPDIR might be mounted as noexec, in which case the LD_PRELOADwill simply not work.
Would a change to partially add back support for building libstdbuf.so externally be accepted? This could be perhaps configurable at build time & off-by-default (e.g. make USE_EXTERNAL_STDBUF=1), which would help a lot with the first point. (It wouldn't for the second, though! I'm not sure what the best solution for that is.)
The text was updated successfully, but these errors were encountered:
#1120 changed the way stdbuf works to embed the .so inside of the binary. This, however, has some notable cons, such as:
$TMPDIR
might be mounted as noexec, in which case theLD_PRELOAD
will simply not work.Would a change to partially add back support for building libstdbuf.so externally be accepted? This could be perhaps configurable at build time & off-by-default (e.g.
make USE_EXTERNAL_STDBUF=1
), which would help a lot with the first point. (It wouldn't for the second, though! I'm not sure what the best solution for that is.)The text was updated successfully, but these errors were encountered: