Issue with 64-bit inodes vs. 32-bit inodes with osxfs in Ubuntu 16.04 container

I have an issue I’m looking to get some feedback on the correct “docker” way to resolve. I believe this is Docker for Mac specific because of the fact bind mounts use osxfs and the inodes are 64-bit, not 32-bit. Unlike filesystems like cifs which allow the use of ‘noserverino’, osxfs does not seem to have a way to let the client determine inodes rather than the mounted system.

I have created a basic docker image based on Ubuntu 16.04

    FROM ubuntu:16.04@sha256:ea1d854d38be82f54d39efe2c67000bed1b03348bcc2f3dc094f260855dff368

    RUN dpkg --add-architecture i386
    RUN apt-get update && apt-get install -y \
      bzip2 \
      expect \
      file \
      gtk2-engines-murrine:i386 \
      libgtk2.0-0:i386 \
      libxtst6:i386 \
      lib32stdc++6 \
      libxt6:i386 \
      libdbus-glib-1-2:i386 \
      libasound2:i386 \
      make \
      maven \
      openjdk-8-jdk \
      patch \
      python \
      rsync \
      swig \
      unzip \
      vim \
      wget \
      && rm -rf /var/lib/apt/lists/*

The purpose of this image is to server as a common build environment for developers. It also includes a commercial cross-compiler for an older 32-bit embedded device. For the purposes of this explanation, the docker image is named ‘crosscompiler’

Using Ubuntu (16.04 specifically) has been no issue for developers in a Virtual Machine form, but the many benefits of Docker outweigh the VM approach. So this Docker image is to replace the VM.

So the PROBLEM:
Because the cross-compiler is a 32-bit toolchain it relies on i386 libraries to be included, which I’ve included in the above Dockerfile.

To use this image to compile code we might run something like the following:
docker run --rm -ti -ti --volume=/path/to/source/code/to/build:/root/workspace crosscompiler /bin/sh -c “cd /root/workspace && ./build.sh”

build.sh runs a script that builds all of the code. The issue is that because this is a 32-bit cross compiler that does things like stat (which in our older cross-compiler does not have support for Large Files; i.e. 64-bit inodes).

What would be the suggested way to resolve something like this?

  • Copy our source to the container that is spun up each time?
  • Somehow use Docker ‘Volumes’ so that the container builds the files itself?
  • Some way to configure a ‘noserverino’-like mount for osxfs?
  • Other options?

The goal here is to allow for local source code changes on the host to be easily compiled within the container. This will be used locally or on a Continuous Build environment so it is advantageous to come up with an elegant and sustainable solution.

Thanks
-Adam H.