Docker中的不同内核中编译代码会受到什么影响？
我可以相信在Ubuntu 14.04主机的c / c ++源代码的docker容器中的redhat6.4版本吗？ 或者我需要考虑的任何限制？
我们正在尝试使用docker来为不同的OS平台编译源代码，因为docker中的技术是共享主机os的内核，请参阅相关问题docker主机操作系统和容器基础映像操作系统之间的关系是什么？
- 我的主机操作系统是Ubuntu 14.04（易于安装
3.13.0-24-generic），内核是3.13.0-24-generic - 我的应用程序平台是redhat 6.4（内核是
2.6.32-358.el6.x86_64）
当我为Ubuntu创buildRHEL容器时，内核也更新为3.13.0-24-generic 。
我的应用程序是基于C / C ++和Java的。
我不认为java会编译.jar文件的任何问题，因为它是基于jvm。
而对于c / c ++代码，大部分我都明白它依赖于libc类的共享库，不依赖于内核，所以有可能将这个编译好的代码用到真正的redhat环境中。
此设置仅用于开发，不用于生产，生成的二进制文件应该安装在具有RHEL或VM的真正的独立计算机上。
那么我需要考虑什么呢？
可能是更多lxc相关的问题。
更新后添加一些示例
我下载了gameoflife代码https://github.com/rvsjoen/game-of-life ，并在两个系统中编译，因为md5是一样的，结果是一样的，可信。
这是VM中的redhat 6.4系统
[root@redhat game-of-life-master]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.4 (Santiago) [root@redhat game-of-life-master]# uname -a Linux redhat 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013 x86_64 x86_64x86_64 GNU/Linux [root@redhat]# ldd gol linux-vdso.so.1 => (0x00007fffaeaa8000) libncurses.so.5 => /lib64/libncurses.so.5 (0x00000033fa000000) libc.so.6 => /lib64/libc.so.6 (0x00000033f9c00000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00000033fb800000) libdl.so.2 => /lib64/libdl.so.2 (0x00000033f9800000) /lib64/ld-linux-x86-64.so.2 (0x00000033f9400000) [root@redhat]# md5sum gol 4f3245d3d61b1c73e48537dd612d37c3 gol
这是docker容器中的redhat
bash-4.1# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.4 (Santiago) bash-4.1# uname -a Linux f51c7b4e80aa 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux bash-4.1# ldd gol linux-vdso.so.1 => (0x00007fff5e3c2000) libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f2e84863000) libc.so.6 => /lib64/libc.so.6 (0x00007f2e844d0000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f2e842ae000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f2e840aa000) /lib64/ld-linux-x86-64.so.2 (0x00007f2e84a8e000) bash-4.1# md5sum gol 4f3245d3d61b1c73e48537dd612d37c3 gol
c / c ++代码有没有exception？
在正常情况下，本地编译的代码（C，C ++ …）也不例外。
正如你写的，程序与libc交互，而不是内核，除了非常特殊的情况。
这个libc库不会在你的Ubuntu主机和你的Redhat容器之间共享。 你的容器有自己的libc ，将系统调用抽象为内核。
关于内核本身，请注意，即使Linux内核内部部件倾向于移动，不断发展的代码段，公开的内容（用户空间应用程序和libc可访问的ABI）在发行版之间保持稳定和兼容。 在极less数情况下，这种兼容性已经被打破，大部分时间都不是故意的。 （见这篇文章 ）。
所以，是的，使用RHEL dev是完全安全的。 Ubuntu主机上的环境，并信任从这个容器生成的构build。