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 libclibrary not shared between ubuntu host , redhat container. container has own libcthat 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

Popular posts from this blog

php - render data via PDO::FETCH_FUNC vs loop -

c++ - OpenCV Error: Assertion failed <scn == 3 ::scn == 4> in unknown function, -

The canvas has been tainted by cross-origin data in chrome only -