Debian从Jessie升级到Stretch后，需重新编译源码构建的工具吗？

刚好有过Debian大版本升级后处理各类源码编译工具的经验，来给你拆解下你提到的每个工具的情况——虽然表面能跑，但不同工具的隐性风险和处理方式差异很大：

Omnet++ & SUMO #

这俩都是C++编写的模拟器，你现在能正常启动其实是沾了Debian库向后兼容的光（Stretch用的glibc 2.24对比Jessie的2.19，做了不少兼容处理），但隐性问题绝对不能忽视：比如内存分配逻辑、线程调度的细微变化，可能不会让程序直接崩溃，但会悄悄影响仿真结果的一致性——比如同样的仿真参数，升级前后跑出不同的统计数据，排查起来会非常头疼。

我的建议是：立刻备份好当前的项目配置和仿真场景，然后用Stretch自带的gcc/g++重新完整编译一遍。重新编译能让工具完全适配新系统的库，从根源上消除仿真结果不一致的隐患。

Python编写的程序 #

分两种情况来看：

• 如果是用系统自带的Python：Jessie默认是Python 2.7.9，Stretch是2.7.13，小版本升级的兼容性很好，纯Python脚本基本不用动。但如果你的程序依赖了带C扩展的第三方库（比如numpy、scipy这类），那最好重新安装这些依赖——因为底层系统库变了，之前编译好的C扩展可能已经和新库不兼容，轻则性能下降，重则运行报错。
• 如果是用virtualenv隔离的Python环境：只要环境里的Python版本没换，纯Python脚本可以放心用，但同样，带C扩展的第三方库建议重新pip install一遍，确保适配新系统的底层库。

旧版本R（2.11） #

这个是风险最高的！R 2.11是2010年的老版本，和Stretch里的系统库差异极大，哪怕现在能启动，也大概率会出现计算错误、随机崩溃或者依赖缺失的问题——比如某些内置函数的行为因为底层库变化而改变，导致数据分析结果出错。

我的建议：

1. 优先考虑升级R到Stretch仓库里的版本（3.3.3），新版本不仅兼容性更好，还能获得更多功能和安全补丁；
2. 如果必须保留R 2.11，最好用Docker这类容器工具隔离运行，避免和系统库冲突；
3. 要是硬要在Stretch上重新编译R 2.11，做好踩坑的准备——Stretch已经不再提供它需要的很多旧版依赖，你得手动找源码编译这些依赖，过程会非常繁琐。

总结一下 #

• C/C类工具（Omnet、SUMO）：一定要重新编译，别侥幸，仿真结果的一致性比“能跑”重要得多；
• Python程序：检查依赖的第三方库类型，纯Python脚本可先测试核心功能，带C扩展的就重新安装；
• 旧版R：强烈建议迁移到新版本或用容器隔离，别直接在Stretch上用未重新编译的旧版R，坑太多。

内容的提问来源于stack exchange，提问作者HanniBaL90