Closed rbucker closed 7 years ago
I see you're also changing the build script to build a statically compiled docker2aci. You use -tags=netgo
which means it will use golang's dns resolver instead of the one in glibc. Although simple /etc/resolv.conf
options work, this means the features not supported by go's resolver are not gonna work.
I'm hesitant about this, do you really need a statically compiled docker2aci? I understand that to build with glibc you'll need to switch alpine (which uses musl) to something that uses it.
For the record, we tried to get a static rkt but we dropped it (https://github.com/coreos/rkt/pull/1380) although things seem to work better nowadays
I do not have a particular opinion other than effort has been expended in this direction based on experience.
ok, so I have a small opinion now and in no particular order... [a] needs to run on CoreOS and it appears glibc is not included [b] docker2aci is licensed under the apache license and statically linking to glibc will virulently attach the GPL and that entire argument chain [c] even the official golang docker container uses Alpine. Clearly perfection is not possible so then something that is good enough needs to be good enough.
I'd rather keep it dynamic by default, maybe you can add a build-option to build statically?
Also, what about using our new rkt-builder, it has everything we need and it is trusted?
This should just work:
sudo rkt run \
--volume src-dir,kind=host,source=${SRC_DIR} \
--volume build-dir,kind=host,source=${SRC_DIR} \
--interactive \
coreos.com/rkt/builder:1.0.1 \
--exec /opt/rkt/build.sh
needs to run on CoreOS and it appears glibc is not included
It is included as far as I can see:
core@core-01 ~ $ ldd ./docker2aci
linux-vdso.so.1 (0x00007ffdacbfd000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f593c61b000)
libc.so.6 => /lib64/libc.so.6 (0x00007f593c270000)
/lib64/ld-linux-x86-64.so.2 (0x00007f593c838000)
On Mon, Jul 18, 2016 at 9:39 AM, Iago López Galeiras < notifications@github.com> wrote:
It is included as far as I can see
I was looking for the wrong filename
Can you squash the commits and change the commit message to our conventional format (I should document it in this repo too). Something like:
build: add support for building with rkt
After that and after my inline comments are addressed we can merge this.
bump?
Closing a stale PR. This can be restarted at a later point, though.
I want to be able to produce an executable for CoreOS host (static binary) and to be able to build the project with rkt as the only requirement.