[WIP] creation of an x86_64 build environment

[jopasserat]

This is to simplify static builds for CARE and PRoot.
Should fix #1

The image is based on Debian jessie.
It installs all required dependencies and pre-builds the static libs PRoot depends upon

• Dockerfile
• update README with Docker explanations
• update proot and care source archives in packages folder
• integrate ad-hoc fixes
• tests by other users

[fsquillace]

Hi @jopasserat,

Thanks for working this. I did a test and it works fine.
I noticed that the building produces a x86_64 binary.

>> file target/proot
target/proot: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=aef80b001cbbf8d7fca467620dd9bd3c6552717e, not stripped

The previous solution (in master) seems to be able to build arm proot executables from a x86_64 although I could not make it working.
Does your solution accomplish that? Or do you plan to do it?

[jopasserat]

This is the best trick I've found to make sure the binaries built in the docker had the correct uid and gid of the user running docker run from the host. More than happy to merge a better solution that achieves the same result though :) Any thoughts?

…

On 9 December 2016 20:51:47 GMT+00:00, Filippo Squillace ***@***.***> wrote: fsquillace commented on this pull request. > +USER_ID=$(id -u) + +# must be an absolute path +TARGET_DIR=${TARGET_DIR:-"$(pwd)/target"} + +# VOLUMES must be formatted as Docker expects them -> /path_on_host:/mountpoint +# specify multiple volumes using the ; separator +VOLUMES=${VOLUMES:-""} + +### FUNCTIONS + +create_user_cmd() +{ + if [[ ${USER_ID} -ne 0 ]]; then + echo \ + groupadd -f -g ${GROUP_ID} ${CONTAINER_GROUPNAME} '&&' \ Is there a reason to create the user during the execution of the image? I guess we could create a default user in Dockerfile and use it for for building the static binaries. This can potentially things a bit as you do not need to create a user for each user that attempts to build the binaries. WDYT? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #2 (review)

-- Jonathan Passerat-Palmbach, PhD Research Associate Department of Computing Imperial College London South Kensington Campus Huxley Building - room 344 180 Queen's Gate London SW7 2AZ

[jopasserat]

Unfortunately I have literally zero experience neither with arm architectures nor qemu (which is used to do the cross platform build in master). The goal of the Docker was thus to make we can at least easily build static versions for what I assume is the most used version. Would be great if someone could contribute a patch to sort out the arm build. Happy to review and merge any PR you'd open in this direction.

…

On 9 December 2016 20:57:31 GMT+00:00, Filippo Squillace ***@***.***> wrote: Hi @jopasserat, Thanks for working this. I did a test and it works fine. I noticed that the building produces a `x86_64` binary. ```sh >> file target/proot target/proot: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=aef80b001cbbf8d7fca467620dd9bd3c6552717e, not stripped ``` The previous solution (in master) seems to be able to build arm proot executables from a x86_64 although I could not make it working. Does your solution accomplish that? Or do you plan to do it? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #2 (comment)

-- Jonathan Passerat-Palmbach, PhD Research Associate Department of Computing Imperial College London South Kensington Campus Huxley Building - room 344 180 Queen's Gate London SW7 2AZ

[fsquillace]

Unfortunately I do not have time to dig to a proper solution for ARM. In any case I guess if you solution does not cover every feature from the master, it is better to keep this as a separate branch and close this pull request.

[jopasserat]

I think the docker build can at least help those who are running on x86_64 (can also help to automate some CI tests),
I've renamed it to make it clear that it only covers one architecture.