Optimal setup for cross-compiling packages for multiple PCs

General talk about packaging procedures and packages.
Post Reply
User avatar
john256
Posts: 89
Joined: 1. Jun 2011, 07:52

Optimal setup for cross-compiling packages for multiple PCs

Post by john256 » 18. Jan 2015, 18:14

As I am going to convert a few PCs to SalixOS MATE, I started to build a bunch of add-on packages on the fastest machine with the intent to install these on the other PCs too in order to save time by not building on every computer separately.

However, after experimentally building a couple of the packages on one of the slower (older) machines, I noticed that some of these packages had different md5sums (assuming different optimizations during the build process).

Now I am wondering what approach should I adopt to cross-compile packages that would run without problems on all the machines I plan to convert. What would you recommend?

User avatar
gapan
Salix Wizard
Posts: 5531
Joined: 6. Jun 2009, 17:40

Re: Optimal setup for cross-compiling packages for multiple

Post by gapan » 18. Jan 2015, 18:34

john256 wrote:However, after experimentally building a couple of the packages on one of the slower (older) machines, I noticed that some of these packages had different md5sums (assuming different optimizations during the build process).
Resulting packages will always have different md5sums, as file creation times are stored inside the package and those differ every single time.

If you're going to md5 something, that should be the libraries and executables within each package. Assuming same build options (those should be taken care of by the respective build scripts), those should be the same.
john256 wrote:Now I am wondering what approach should I adopt to cross-compile packages that would run without problems on all the machines I plan to convert. What would you recommend?
Can you elaborate on that? What do you mean exactly? If you build a 64bit package in one PC with Salix 14.1, it will run on every 64bit Salix 14.1 you have. Unless you mean you have a mix of 64bit/32bit PCs, in which case you want to build packages for both architectures. In that case, have a look at this email from our mailing list archives: https://sourceforge.net/p/salix/mailman ... /33182843/
Image
Image

User avatar
john256
Posts: 89
Joined: 1. Jun 2011, 07:52

Re: Optimal setup for cross-compiling packages for multiple

Post by john256 » 18. Jan 2015, 18:37

All the PCs are 32-bit, so I don't plan to have packages for different architectures.

User avatar
gapan
Salix Wizard
Posts: 5531
Joined: 6. Jun 2009, 17:40

Re: Optimal setup for cross-compiling packages for multiple

Post by gapan » 18. Jan 2015, 18:38

So you can just build on one PC, use on all the others.
Image
Image

User avatar
john256
Posts: 89
Joined: 1. Jun 2011, 07:52

Re: Optimal setup for cross-compiling packages for multiple

Post by john256 » 18. Jan 2015, 18:42

gapan wrote: Resulting packages will always have different md5sums, as file creation times are stored inside the package and those differ every single time.
I had the same thought, but as I had one package with exactly the same md5sum built on both machines while the another wasn't identical, I thought that I probably need to take measures about these differences...

User avatar
john256
Posts: 89
Joined: 1. Jun 2011, 07:52

Re: Optimal setup for cross-compiling packages for multiple

Post by john256 » 18. Jan 2015, 18:45

Thanks also for pointing me to the very informative post on the mailing list! This setup seems somewhat "scary" to me (as I am not that experienced with building environments), so I would consider preparing all the packages in a VirtualBox VM.

Would this be a good option?

User avatar
gapan
Salix Wizard
Posts: 5531
Joined: 6. Jun 2009, 17:40

Re: Optimal setup for cross-compiling packages for multiple

Post by gapan » 18. Jan 2015, 18:49

Yes, but building would be somewhat slower.
Image
Image

User avatar
john256
Posts: 89
Joined: 1. Jun 2011, 07:52

Re: Optimal setup for cross-compiling packages for multiple

Post by john256 » 18. Jan 2015, 18:51

I don't mind the somewhat slower build-process - the build-PC is quite fast and I can let it do its job in the background while working on other things ;-)

Post Reply