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
In my project, I'm using two copies of jemalloc simultaneously. To avoid duplicated symbols, one of then modifies the symbols using --with-jemalloc-prefix and --with-private-namespace flags.
When building with LTO, the --with-private-namespace flag has no effect, but no errors/warnings are reported.
I was able to track this problem, and it turns out that jemalloc calls nm in its post-processing step used for renaming private symbols. This fails when using LTO and building with GCC, in which case it's necessary to use gcc-nm instead of nm. I was able to fix this by manually setting the NM env variable to the path of gcc-nm.
The issue I see here is that this behaviour is not documented anywhere, and the errors returned by nm seem to be ignored (and not reported to the user).
The text was updated successfully, but these errors were encountered:
In my project, I'm using two copies of jemalloc simultaneously. To avoid duplicated symbols, one of then modifies the symbols using
--with-jemalloc-prefix
and--with-private-namespace
flags.When building with LTO, the
--with-private-namespace
flag has no effect, but no errors/warnings are reported.I was able to track this problem, and it turns out that jemalloc calls
nm
in its post-processing step used for renaming private symbols. This fails when using LTO and building with GCC, in which case it's necessary to usegcc-nm
instead ofnm
. I was able to fix this by manually setting theNM
env variable to the path ofgcc-nm
.The issue I see here is that this behaviour is not documented anywhere, and the errors returned by
nm
seem to be ignored (and not reported to the user).The text was updated successfully, but these errors were encountered: