image update to ubuntu18.04

最近在升级apollo docker image nvidia/cuda:10.0-cudnn7-devel-ubuntu18.04。真叫一个头大，但是往往在这个过程中能够得出很多体会，比如应该怎么做更好，更容易维护，更容易升级等等。

计划是分三个阶段来完成，目前还在第二阶段：

1. build image：这个阶段的体会最深的是在速度方面，主要是cache相关。正确合理的利用好cache机制，但要注意bad cache。

• 建议将较稳定偏系统不易变的 置于靠前位置。
• 另一个，之前制作image相关的script到处都是apt-get update，基本在apt之前大家都update一把，其实是非常耗时的。关于这个操作做了什么，什么时候需要做，这里面的细节可以了解下。
• 还有关于bad cache，cache机制以后再了解下，由于规模大，目前大部分image的dockerfile RUN xxx.sh，这个里面cache好像有点奇怪。
• 小技巧，由于做一次整的build很耗时，在失败时，可以运行上一层成功的layer进行调试，很方便好使。

2. compile code in new image：new image最终是用于承载product code，product code跟image的interaction主要体现在头文件和库文件。

• new image做出来，还有很多跟product code可能不兼容的地方，特别是OS层的升级，携带着许多默认小库的自动升级，比如boost，vtk.xx==>vtk.xx等，会携带大量头文件及库文件的改动，以及接口变更等。这些往往还会带来关联波及。
• 另一个就是之前的image使用大量打包的so，这些so都是基于以前的环境做出来，或者说运行很依赖于做它的环境，比如so是打包boost.54.xx相关东西，现在新环境很可能已经相应升级。这个很不便于跨度较大的升级。所以在考虑编译时间成本可以忍受的情况下，尽量不要去down so来用。

3. test code：做这个的原因是，上述相关还只是停留在symbol层次的工作，还需要验证上述做的相关symbol变更是否达到等价的效果。

一些好用的技巧：

#!/bin/bash
hgrep()
{
  sudo find $1 -name "*.h" -o -name "*.hpp" |xargs grep -n $2
}
cgrep()
{
  sudo find $1 -name "*.c" -o -name "*.cpp" |xargs grep -n $2
}
cmgrep()
{
  sudo find $1 -name "CMakeList.txt" |xargs grep -n $2
}

把这个在.bashrc中source一把，很方便快捷好用。

aptitude show libboost-dev            show version

apt-cache madison libboost-dev    list candidate，sourcelist

patch -p0 < xx.patch

在每行的头添加字符，比如"HEAD"，命令如下：sed ‘s/^/HEAD&/g‘ test.file

在每行的行尾添加字符，比如“TAIL”，命令如下：sed ‘s/$/&TAIL/g‘ test.file

nm -C xxx.so |grep "yyy" --color=auto

linker相关：

echo "/usr/local/mysql/lib" >> /etc/ld.so.conf

sudo ldconfig -v | grep mysql # 查看mysql库文件是否被找到。

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/mysql/lib

LIBRARY_PATH is used by gcc before compilation to search directories containing static and shared libraries that need to be linked to your program.

LD_LIBRARY_PATH is used by your program to search directories containing shared libraries after it has been successfully compiled and linked.

EDIT: As pointed below, your libraries can be static or shared. If it is static then the code is copied over into your program and you don‘t need to search for the library after your program is compiled and linked. If your library is shared then it needs to be dynamically linked to your program and that‘s when LD_LIBRARY_PATH comes into play.

 #在PATH中找到可执行文件程序的路径。
export PATH =$PATH:$HOME/bin
#找到动态链接库的路径
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/MyLib
export LD_LIBRARY_PATH
#找到静态库的路径
LIBRARY_PATH=$LIBRARY_PATH:/MyLib
export LIBRARY_PATH

gcc -L / -l option flags

gcc -l links with a library file.

gcc -L looks in directory for library files.

头文件相关：

#gcc找到头文件的路径
C_INCLUDE_PATH=$C_INCLUDE_PATH:/usr/include/libxml2:/MyLib
export C_INCLUDE_PATH
#g++找到头文件的路径
CPLUS_INCLUDE_PATH=$CPLUS_INCLUDE_PATH:/usr/include/libxml2:/MyLib
export CPLUS_INCLUDE_PATH

cpp -Iheaders -v    like  gcc -Iheaders source.c 

cpp -iquote hdr1 -v

image update to ubuntu18.04

原文：https://www.cnblogs.com/cjyp/p/11198377.html