1. 为什么要在 Ubuntu 18.04 上折腾 GAMMA

GAMMA 安装这件事，说难不难，说简单也不简单。它不是那种apt install一条命令就能解决的软件，而是一整套命令行形式的 SAR 处理工具集，涵盖干涉测量、差分干涉、地理编码、点目标时序分析等模块。它不像常规 Linux 软件那样有完善的包管理支持，所有的环境依赖、路径配置、许可文件、脚本解释器，几乎都要自己一手一脚摆平。所以每一次在新机器上装一遍 GAMMA，本质上都是在重新梳理一遍"这台机器的运行环境是否干净、是否匹配"。

我前后在不同机器上装过七八次，从最早的 Ubuntu 14.04 到 16.04 再到 18.04，每一次踩的坑都不太一样。18.04 这个版本比较特殊：它自带 GCC 7、默认 Python 3、默认不带 32 位兼容库，而 GAMMA 的发行包里相当一部分可执行文件是 32 位编译的，脚本层又大量依赖 Python 2.7 和 csh。这三件事凑在一起，就构成了 18.04 上安装 GAMMA 的三大主要障碍。

这篇文章面向的是刚接触 SAR 数据处理、需要在自己机器或服务器上把 GAMMA 跑起来的人，包括遥感、测绘、地灾监测方向的研究生和工程师。我会把安装拆成"环境准备—落位—验证—排错—调优"几个阶段，每一步都说明白为什么这么做，并把常见的报错和对应处理方式整理成速查表。你照着走一遍，大概率能少花两三天时间。

2. 安装前的环境准备与依赖梳理

2.1 先搞清楚 GAMMA 发行包的结构

拿到手的 GAMMA 安装包通常是一个压缩包，解压之后是一整个目录，名字里带日期戳，用来区分不同发行版本。目录内部按功能模块划分，常见的有干涉处理模块、差分干涉与地理编码模块、时序分析模块、土地利用工具模块、地图投影支持模块、显示工具模块等。每个模块下面又有bin、scripts、src、help这样的子目录，bin放编译好的二进制程序，scripts放各种 shell 和 Python 脚本。

理解这个结构非常重要，因为后面配环境变量时，你实际上是把这个结构里的每个bin和scripts目录都塞进PATH。很多人装完之后敲命令提示 command not found，八成就是漏了某个模块的路径没加进去。我的做法是先把目录树打出来看一眼，find $GAMMA_HOME -maxdepth 2 -type d一条命令就能看清全貌，心里有个数再动手。

注意：不同年份的发行包，模块目录命名会有细微差别，有的版本把显示工具合到主模块里，有的单独拆出来。所以别死记硬背我下面的路径，先自己ls一遍确认目录名。

另外要提前确认的一件事是许可文件。GAMMA 是商业软件，安装包里会附带一个许可文件，通常在根目录或者某个约定位置。这个文件的位置和内容格式不能随意改动，一旦挪错地方，程序启动时会直接报许可错误然后退出。在动手装之前，先把许可文件找出来单独放好，这一步能省掉后面很多无谓的排查。

2.2 系统基础检查：架构、空间与基础工具

第一件事是确认机器架构和磁盘空间。虽然现在基本都是 x86_64，但如果你的机器是 ARM 平台，那 GAMMA 的二进制包是跑不起来的，需要另外确认是否有对应架构的构建。用uname -m看一眼就行，返回x86_64才继续往下走。

磁盘空间方面，GAMMA 本体加上帮助文档，一般几个 G 就够。但真正吃空间的是数据和处理中间结果，一景 Sentinel-1 的 SLC 大概 7 到 8 GB，干涉处理过程中还会产生大量中间文件，一个完整的时序处理项目轻轻松松几百 GB。所以我习惯把 GAMMA 装在系统盘，把数据目录单独挂一块大盘，通过软链接或者环境变量指向数据位置。这个习惯在后期维护时价值极大，重装系统不用重新拷数据。

基础工具方面，先装一批后面一定会用到的：

sudo apt update sudo apt install -y build-essential csh tcsh gawk \ gnuplot ghostscript imagemagick \ libx11-dev libxext-dev libjpeg-dev libpng-dev libtiff-dev

这里解释几个容易忽略的。csh和tcsh必须装，因为 GAMMA 有一批历史脚本是用 c 壳写的，在 bash 下直接执行会报莫名其妙的语法错误，装好之后这些脚本才能正常跑。gnuplot和ghostscript是出图和转图用的，很多处理流程最后一步要生成 PS 或者 PDF 图件，缺了这两个会卡在收尾环节。imagemagick则是把 PS 转 PNG 用的，看结果时很方便。

2.3 补齐 32 位兼容库，这是 18.04 上最大的坑

这一点单独拎出来讲，因为它是 18.04 上失败率最高的环节。GAMMA 的部分二进制程序是 32 位编译的，在 64 位系统上直接运行会提示找不到文件或者格式错误。Ubuntu 18.04 默认不开启 32 位架构支持，必须先手动启用，再安装对应的 32 位库。

sudo dpkg --add-architecture i386 sudo apt update sudo apt install -y libc6:i386 libstdc++6:i386 \ libx11-6:i386 libxext6:i386 libxrender1:i386 \ libxt6:i386 libxi6:i386 libmotif-common:i386 libxm4:i386

这里有个细节要提醒：不同小版本的 Ubuntu 仓库里，Motif 相关的包名不完全一样，有的叫libmotif4:i386，有的已经拆成libmotif-common加libxm4。如果找不到某个包名，别慌，用apt-cache search motif搜一下，把实际存在的那个装上即可。装完之后可以用ldd验证一下具体某个二进制程序还缺什么库：

ldd $GAMMA_HOME/ISP/bin/xxxx | grep "not found"

哪一行输出not found，就去补哪个库，这是最直接的排查方式，比凭猜测装一堆包高效得多。

提示：如果你的发行版是纯 64 位构建，上面这步可以跳过。判断方法是对任意一个bin目录下的程序执行file命令，输出里带32-bit就需要补 32 位库，带64-bit就不需要。

2.4 Python 2.7 与解释器软链接

GAMMA 的脚本层里有相当一部分是 Python 写的，而且写作年代较早，用的是 Python 2 的语法。18.04 默认只装了 Python 3，直接跑这些脚本会报SyntaxError或者ModuleNotFoundError。解决办法是装回 Python 2.7，并把默认的python命令指向它。

sudo apt install -y python2.7 python2.7-dev sudo update-alternatives --install /usr/bin/python python /usr/bin/python2.7 1

这里有个取舍要想清楚：把系统级python指向 2.7 会影响到机器上其他依赖 Python 3 的工具，尤其是一些系统自带的脚本。如果这台机器是专用的处理机，直接改无妨；如果还要跑别的业务，建议不要动全局软链接，而是在启动 GAMMA 环境的脚本里单独设置一个 PATH 前置目录，里面放一个指向python2.7的python软链接。这样只在处理会话里生效，退出就恢复，互不干扰。

我现在的做法是写一个source gamma_env.sh的激活脚本，里面同时做三件事：设置模块路径、设置python前置目录、设置数据目录别名。每次开会话先 source 一下，环境就干净了，也不污染系统。

3. 安装实操：从解压到跑通第一个命令

3.1 目录规划与软件包展开

我建议把 GAMMA 装在/opt下，这是 Linux 上第三方软件的传统位置，权限清晰，备份和对齐也方便。目录名直接用发行包自带的日期戳，这样以后升级到新版本时可以并存，出问题随时切回去。

sudo mkdir -p /opt/gamma sudo tar -xzf GAMMA_SOFTWARE-*.tar.gz -C /opt/gamma ls /opt/gamma

解压完之后确认一下权限。如果后续是普通用户跑处理，那整个目录要保证普通用户可读可执行；如果许可文件需要写操作（部分版本会写日志），相应目录还要给写权限。用chown -R把属主改成处理账号是最省事的，但要注意别把权限放得太松，尤其多用户机器上。

许可文件按发行包说明放到约定位置。常见的做法是放在 GAMMA 根目录下，或者放在每个模块目录下。放好之后不要随意改名，程序是按固定文件名去找的。我见过有人把许可文件改成license.txt.bak备份，结果程序找不到，排查了大半天，这种低级错误在紧张的项目期特别容易发生。

3.2 环境变量配置：路径组织的核心逻辑

环境变量的配置是安装过程中最关键的一步，配错了后面全是玄学问题。核心是两个变量：一个是 GAMMA 根目录，一个是地图投影支持模块的根目录，后者是给地理编码类程序用的。然后是把各模块的bin和scripts全部塞进PATH。

# gamma_env.sh export GAMMA_HOME=/opt/gamma/GAMMA_SOFTWARE-20201031 export MSP_HOME=$GAMMA_HOME/MSP export PATH=$GAMMA_HOME/ISP/bin:$GAMMA_HOME/ISP/scripts:$PATH export PATH=$GAMMA_HOME/DIFF_GEO/bin:$GAMMA_HOME/DIFF_GEO/scripts:$PATH export PATH=$GAMMA_HOME/IPTA/bin:$GAMMA_HOME/IPTA/scripts:$PATH export PATH=$GAMMA_HOME/LAT/bin:$GAMMA_HOME/LAT/scripts:$PATH export PATH=$MSP_HOME/bin:$PATH # 保证脚本能找到 python2 export PATH=/opt/gamma/py2bin:$PATH

写完之后source gamma_env.sh激活，然后echo $PATH检查一下顺序对不对，which SLC_copy之类的命令能不能定位到。这里我把路径一条条加进去而不是拼成一大串，是为了以后某个模块升级或者挪位置时好改，不至于一行超长命令看花眼。

关于路径顺序，还有一点经验：如果你机器上同时装了别的遥感处理工具，它们可能也有同名的命令行程序。这种情况下 GAMMA 的路径要尽量靠前，或者干脆在独立的 shell 会话里跑，避免调用错程序。我就遇到过同名的坐标转换工具被另一个软件抢了优先级，结果输出的投影参数完全不对，查了两天才发现问题出在 PATH 上。

3.3 三步验证法：确认安装真的成功

装完之后不要急着上真实数据，先做三级验证，逐级排除问题，效率最高。

第一步，验证二进制程序能否启动。随便挑一个不带参数时输出用法说明的命令，比如文件拷贝类的工具，直接敲命令名，如果打印出一屏用法提示，说明二进制本身和依赖库都没问题。如果报cannot execute binary file，那基本就是 32 位库没补齐；如果报error while loading shared libraries，就按前面说的ldd方法补库。

第二步，验证脚本层能否运行。挑一个 Python 脚本，加-h或者不传参数执行，看它能不能正常解析参数。如果报bad interpreter，是 shebang 指向的解释器不存在；如果报语法错误，是 Python 版本不对；如果报某个模块找不到，是这个脚本依赖的第三方库（常见的是数值计算和绘图库）没装。

第三步，验证许可和核心算法路径。跑一个最简单的、不涉及大数据的内部算法程序，看它是否能正常完成。这一步能验证许可文件是否被正确读取。如果许可有问题，程序通常在启动瞬间就打印错误退出，不会进入计算阶段，所以这三级验证能快速定位问题层级。

# 第一步：二进制能否启动 SLC_copy 2>&1 | head -5 # 第二步：脚本层 python $GAMMA_HOME/ISP/scripts/par_ISP.py 2>&1 | head -5 # 第三步：依赖检查（找出缺失的库） ldd $GAMMA_HOME/ISP/bin/SLC_copy | grep -i "not found"

3.4 多版本共存与环境切换

实际项目里经常遇到这种情况：老项目用旧版本发行包跑出来的结果，新版本算法有更新，为了复现必须保留旧版本。这时候就需要多版本共存。做法很简单，把不同日期的发行包分别解压到/opt/gamma下的不同子目录，然后准备多个激活脚本，比如gamma_2020.sh、gamma_2023.sh，需要哪个 source 哪个。

关键是不要在同一个 shell 会话里反复 source 不同版本，因为PATH是累加的，旧的路径还留在里面，很容易调到错误版本的程序。切换版本的正确做法是开一个新终端，或者先用exec bash重置会话再激活。我吃过这个亏：切换版本后处理结果异常，最后发现是调到了旧版本的某个工具，which一查才明白。

另外建议在每个激活脚本里加一行版本标识输出，echo "GAMMA env: 2020-10-31"之类，开会话时一眼看到当前用的是哪个版本，能避免很多误操作。

4. 常见报错与排查实录

4.1 动态库类报错：从现象到根因的定位路径

动态库问题在安装阶段占比最高，表现形式主要有三种：cannot execute binary file、error while loading shared libraries: libxxx.so.n: cannot open shared object file、以及运行时突然崩溃。第一种是架构不匹配，第二三种是缺库。

排查顺序我总结成一个固定套路：先用file看程序架构，再用ldd列出所有依赖，把带not found的逐个补齐。补的时候注意版本号，报libX.so.6就必须装提供.so.6的那个包，装成.so.5是没用的。Ubuntu 上可以用apt-file search libX.so.6反查哪个包提供这个文件，虽然要先装apt-file并更新索引，但对不熟悉的库名特别有效。

还有一类隐蔽的情况是库存在但版本太新，符号对不上。这在系统升级之后偶尔出现，表现是启动时直接崩，没有任何提示。这种就只能装对应旧版本的库，或者换用 64 位的构建版本绕开。我的建议是尽量用官方提供的、与你的系统版本匹配的发行包，不要随便跨大版本混用。

4.2 许可与环境变量相关的坑

许可类报错的典型表现是程序启动后立刻退出，或者打印一行很短的错误信息就结束。这时候先确认三件事：许可文件是否在程序期望的位置、文件名是否被改过、文件的属主和权限是否允许当前用户读取。

我遇到过一次特别典型的案例：文件放在正确位置，名字也对，权限是 600，属主是 root，普通用户读不了，程序报的是"许可无效"而不是"权限拒绝"，误导性很强。后来ls -l一看才发现。所以现在的习惯是，许可文件放好之后统一chmod 644，属主设成处理账号，省得后面折腾。

环境变量类的坑更隐蔽。因为PATH配错时，程序可能还能跑，只是悄悄调用了错误版本，结果是计算结果不对而不是报错。这类问题的排查方法是：在处理脚本开头加一行which输出所有关键程序的路径，或者用type -a看是否存在多个同名程序。把路径打印到日志里，出问题时对照日志看当时调的是哪个，能省大量时间。

提示：如果你在csh脚本和bash之间来回切换，注意变量语法完全不同。export VAR=value在 csh 里要写成setenv VAR value，$VAR在 csh 里要写成$VAR但赋值用set VAR = value。批量脚本里混用两种语法是这个领域最常见的低级错误之一。

4.3 图形显示与出图相关的问题

GAMMA 有几个基于 X11 的直接显示程序，用于快速查看图像和干涉图。在服务器上跑的时候，如果没有图形环境，这些程序会报cannot open display。解决办法要么是通过 SSH 的 X11 转发把图显示到本地（ssh -X，注意本机也要有 X server），要么就跳过直接显示，改用导出图像文件再看。

出图环节的常见问题是字体和编码。生成的 PS 文件里如果含中文或者特殊符号，容易出现乱码或者方块。原因是 ghostscript 找不到对应字体。处理办法是把需要的字体装进系统字体目录，或者直接在出图参数里指定用英文字体。我一般习惯把图件里的标注全部用英文和数字，省去字体配置的麻烦，反正这些图最终多半要重新排版。

还有一个容易忽略的点是图像尺寸和分辨率。默认参数出的图像素往往偏低，直接放到报告里会糊。可以在出图命令里显式指定分辨率和输出尺寸，虽然生成的文件会大一些，但后期不用返工。

4.4 数据路径、文件大小与磁盘 IO

处理大数据时，路径问题和磁盘问题会集中爆发。路径方面最常见的是路径里含空格或者中文，很多老程序的参数解析很简单，遇到空格就把一个参数当成两个，直接报参数数量错误。所以数据目录一定要用纯英文、无空格的路径，这个规则在 SAR 处理里几乎是铁律。

文件大小方面，老程序可能对单个文件有大小限制，处理超大文件时会截断或者报错。如果遇到这种情况，可以尝试用程序自带的分块参数，把大文件切成几块处理再拼接。另外注意文件系统类型，某些网络挂载的文件系统对大的单文件支持不好，处理中途报 IO 错误，换成本地盘就正常了。

磁盘空间要预留足够。干涉处理中途写满磁盘是最难受的，因为中间文件已经生成了一半，续跑和重跑都麻烦。我的习惯是在处理脚本开头加一个空间检查，剩余空间低于预估的 1.5 倍就直接退出并提示，避免跑到一半崩掉。

4.5 常见问题速查表

5. 装好之后：性能调优与日常维护

5.1 内存、线程与并行策略

GAMMA 的大部分程序是单线程的，但有些模块支持通过环境变量指定线程数。在一台多核机器上，把线程数开满并不一定最快，因为内存带宽和磁盘 IO 会成为瓶颈。我的经验是按"每线程 2 GB 内存"来估算，比如 64 GB 内存的机器，开到 16 线程左右比较稳，再多就容易触发交换，反而变慢。

真正能显著提速的是流程级的并行，也就是同时处理多个数据对或者多个子区。这时候要注意每个并行任务的工作目录必须独立，否则中间文件互相覆盖，结果全乱。我一般按数据对建目录，每对数据一个子目录，用简单的循环加&后台跑，配合wait控制并发数，比复杂调度简单可靠。

提示：并行跑之前先单跑一对，确认整个流程能完整走通，再放大并发。否则一旦流程某一步有隐藏的问题，并行只会让问题成倍放大，排查成本也成倍增加。

5.2 让处理流程可复现：脚本化与日志

手工敲命令是复现的天敌。每一条处理命令都应该落在脚本里，参数写死在脚本或者配置文件中，运行时的关键信息写进日志。日志至少记录三类信息：运行的命令原文、开始和结束时间、以及关键中间产物的文件大小和校验值。

这样做的好处不只是复现。项目做久了，你会遇到"这个结果当初是怎么跑出来的"这类问题，如果只有结果文件没有过程记录，基本无解。反过来，如果脚本和日志都在，重跑一遍就能验证。我现在每个项目目录下固定有三个文件：run.sh、config.sh、run.log，交接时连同数据一起交付，接手的人能直接看懂。

5.3 升级与备份的正确姿势

GAMMA 升级不要覆盖安装。正确做法是新版本解压到新目录，用新的激活脚本，先用少量数据跑一遍对比结果，确认算法行为没有意外变化再全面切换。老版本目录至少保留一个项目周期，等所有历史项目都验证过了再考虑清理。

备份的重点不是软件本体，因为软件可以从安装包重新解压，真正需要备份的是你的处理脚本、配置文件、自定义的参数模板，以及许可文件。这些加起来可能不到几 MB，但丢了要重新整理很久。我习惯把它们放在一个独立的小仓库里做版本管理，每次改动都留记录，这样哪次改的参数导致结果变差，直接回滚就行。

还有一个容易被忽略的维护点：定期清理中间文件。干涉处理会产生大量临时文件，一个项目跑完可能留下几百 GB 的无用数据。建议在处理脚本里加一个可选的清理步骤，在确认最终结果无误后，把中间目录整个删掉，只保留输入、脚本和最终产物。这个习惯能让你的存储盘多用好几年。

6. 从装好到能用：第一个流程该怎么跑

6.1 用最小数据集验证整条链路

装好之后最忌讳直接上大项目。我的建议是找一小块区域、两景数据，把从数据读取到生成干涉图的最小链路跑一遍。这个链路通常包括：数据导入或读取、影像配准、干涉图生成、去平地效应、滤波、解缠、地理编码。每一步单独执行，每步跑完检查产物是否存在、尺寸是否合理、图像是否有明显的异常条纹。

这个过程中最大的价值不是得到结果，而是暴露环境问题。比如读取环节报错，说明数据格式支持和依赖库有问题；配准环节报错，往往是内存或临时目录权限问题；出图环节报错，是绘图库和字体问题。把这些在小数据上一次性解决，后面跑真实项目就顺畅了。

我实测下来，一个完整的最小链路在小数据上大概十几分钟能跑完，但如果环境有问题，可能卡在某一步反复试。所以建议留出半天时间专门做这件事，不要赶工。

6.2 处理参数的记录与管理

每一步的参数选择都会影响最终结果，而这些参数的合理范围跟数据本身密切相关。我的做法是为每个项目建一个参数表，记录每一步用了什么参数、为什么这么选、以及更换参数后的对比结果。这个表看起来是额外工作，但当你三个月后需要向别人解释结果，或者需要在新数据上复现类似设置时，它的价值就体现出来了。

参数表不用很复杂，一个纯文本或者表格文件就够，关键是坚持记录。我自己踩过的坑是：某次调了一个滤波参数，效果明显变好，但没记具体数值，过了一周想再复现，试了十几次都没调回那个效果，最后只能重跑。从那以后我就强制自己每改一个参数都记一行。

6.3 给后来者的一份检查清单

把上面所有内容压缩成一份可执行的检查清单，装完机器照着过一遍，基本不会漏项：

• 架构确认为 x86_64，磁盘预留充足空间
• 安装csh、tcsh、gawk、gnuplot、ghostscript、imagemagick
• 开启 i386 架构并安装全部 32 位依赖库（若发行包为 32 位构建）
• 安装 Python 2.7 并处理解释器指向
• 发行包解压到独立目录，不覆盖旧版本
• 许可文件放到约定位置，权限 644，属主为处理账号
• 激活脚本中配齐GAMMA_HOME、MSP_HOME与全部模块路径
• 三级验证全部通过：二进制、脚本、许可与算法
• 最小数据集跑通完整链路
• 建立脚本、配置、日志三件套并纳入版本管理

这份清单我用了好几年，每次换机器按顺序走一遍，基本不会出大问题。真正需要现场判断的，往往是那些不在清单上的、和数据本身相关的异常，那属于业务层面的事，跟安装无关了。

我个人在实际操作中的体会是，GAMMA 这类老牌科学软件的安装难点从来不在软件本身，而在于它对运行环境的"年代感"要求——它期待一个更旧的、更宽容的系统环境，而现代系统默认是更严格、更割裂的。理解了这个矛盾，你就能明白为什么每一步都要"手动补齐"而不是"自动适配"，也就不会在反复报错时感到莫名其妙了。