c++ - what will be impacted for compiling code in different kernel in docker? -
can trust builds in docker container redhat6.4 in ubuntu 14.04 host c/c++ source codes ? or limitation need consider ?
we trying use docker serve different os platform compile source codes, since technology in docker share host os's kernel, see related question what relationship between docker host os , container base image os?
- my host os ubuntu 14.04 (easy install docker), kernel
3.13.0-24-generic
- my application platform redhat 6.4 (kernel
2.6.32-358.el6.x86_64
)
when created container rhel ubuntu, kernel updated 3.13.0-24-generic
well.
my application c/c++ & java based.
i don't think java problem compiled .jar
files since based on jvm.
and c/c++ codes, understand depends on libc
kind of shared library, not depends on kernel, possible use compiled codes real redhat environment.
this setup used development only, not production, generated binary files supposed installed real standalone machines rhel or vm.
so things need consider ?
probably more lxc related question.
updated add sample
i download gameoflife codes https://github.com/rvsjoen/game-of-life, , compiled in both system, looks case since md5 same, result same , trustable.
this redhat 6.4 system in vm
[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
and redhat in docker container
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
are there exception c/c++ codes ?
there is, in normal situations, no exception natively compiled codes (c, c++...).
as wrote, programs interact libc
, not kernel, except special situations.
this libc
library not shared between ubuntu host , redhat container. container has own libc
that abstracts system calls kernel.
about kernel itself, note if linux kernel internals tend moving, evolving pieces of code, publicly exposed (the abi, accessible userspace applications , libc
) kept stable , compatible between releases. in rare occasions compatibility has been broken, of time, not intentionally. (see this article).
so, yes, safe have use rhel dev. environment on ubuntu host, , trust builds generated container.
Comments
Post a Comment