... the binary created from compiling on his machine, which is the same, is about 6mB bigger
It's worth figuring out what the difference is (even if it's just the case that his build hides, while yours exposes, a real bug):
- double-check you're compiling exactly the same code (no un-committed local changes, no extra headers in the include search path, etc.)
- triple-check by adding a
-E
switch to your gcc arguments in cmake, so it will pre-process your files with the same include path as regular compilation; diff the pre-processor output
- triple-check by adding a
- compare output from
nm
orobjdump
or whatever you have to for your two linked executables: if some system or 3rd-party library is a different version on one box, it may show up here - compare output from
ldd
if it's dynamically linked, make sure they're both getting the same library versions- compare the library versions it actually gets at runtime too, if possible. Hopefully you can do one of: run
pldd
, compare the.so
entries in/proc/pid/map
, run the process understrace
/dtrace
/truss
and compare the runtime linker activity
- compare the library versions it actually gets at runtime too, if possible. Hopefully you can do one of: run
As for the code ... if this doesn't work:
Eigen::VectorXd ModelSearcher::getMinimumBoundingBox();
// ...
Eigen::VectorXd msBb(6, 1); msBb = data.modelSearcher->getMinimumBoundingBox();
and this does:
void ModelSearcher::getMinimumBoundingBox(Eigen::MatrixXd& input);
// ...
Eigen::VectorXd msBb(6, 1); data.modelSearcher->getMinimumBoundingBox(msBb);
you presumably have a problem with the assignment operator. If it does a shallow copy and there is dynamically-allocated memory in the vector, you'll end up with two vectors holding the same pointer, and they'll both free
/delete
it.
Note that if the operator isn't defined at all, the default is to do this shallow copy.