So it works properly when you build within Debian Jesse?

And you are trying to run Stretch or Mint on your build machine and similarly get it to work?

Use a VM on your system to run Debian Jesse to do your builds and then have your build machine be whatever it needs to be.

This is similar to what NevemTeve is saying.

This is also very typical of a cross compilation situation, where you install tools, get them correct, and then never change them. You seem to be changing the tools, and you shouldn't because the target isn't changing. I do realize it is not technically "cross compilation", however, it is some form of tools revision issue, which is coupled with the libraries and files provided specifically by Debian Jesse.

1 members found this post helpful.

My motivation is to utilize resources. I have a new machine with quite a bit of power. I'd like to offload our build server because there are 8 people using it. A compile takes 40 minutes for one user using an optimized make configuration. When multiple users use the server, build time increases. I may be ignorant, but I figured this could be done because the hardware architecture is the same and I am using a variant of Debian.

This is what I feared . I have wanted to avoid using a VM because I don't want to reserve system resources for functionality that I don't need. Do you know of a lightweight VM that will allow me to do a barebones configuration just for doing a build? I would like to make it as transparent as possible.

(Off: Slow? Well, that's how C++ is. It is by design. Read the C++ FQA for details.)

You seem to be conflicted about the reasons for trying to configure your own build machine, and should think that through more clearly before trying to put the build system together.

If you have anything that can be described as a new machine with quite a bit of power, then setting up a VM with a dedicated build environmet should be no drain on resources and almost trivial compared to the required effort and problems resulting from installing non-standard library versions on the host.

Clearly you do need those resources to build for another platform - no need to make it more difficult than it should be. Use the resources - that is what they are for!

This is a very good point - a primary feature (characteristic) of the *nix environment, and Free software generally, is the ability to build on the target machine. Make full use of that!

And as has been said several times, use a VM - it solves almost all the problems easily.

Can you define "light weight", or do you have any specific requirements? Just install Virtual Box (or another VM), install the build target and give it a try! Don't complicate the process by trying to solve non-existent problems! If you hit some resource limit or problem, then you will have a problem with parameters to be solved!

1 members found this post helpful.

When I say light weight, I mean something that runs with minimal drain on system resources. Virtual Box is a great solution, however, it requires dedicated x number of processors and y GB of ram. Compiling code requires to startup the VM, wait for boot, and then execute the code. I would rather not develop in the virtual environment, so any compilation bugs would have to be resolved on the host machine, and then compilation restarted.

I found my solution: dchroot. I installed my target OS on a separate partition. On host, I mount the partition and bind mount other necessary locations (i.e. /proc, /dev, and src directories). I then execute dchroot, and run the compile. There is no need to run a VM with dedicated RAM and processors. It essentially created a development sandbox with the correct libraries installed in the right location. I can integrate this with emacs, and it doesn't feel like I am doing anything special. Compilation is fast and I don't have to utilize resources on the build machine.

I am a newbie, so any viewpoints that could make this solution even better are welcomed!