2

I'm not sure if this is the best place to ask this - please point me in the right direction if there's a better place.

Let's say, hypothetically, that I have two machines - A is a development machine, and B is a production machine. A has software like a compiler that can be used to build software from source, while B does not.

On A, I can easily build software from source by following the usual routine:

./configure
make

Then, I can install the built software on A by running sudo make install. However, what I'd really like to do is install the software that I just built on B. What is the best way to do that?

There are a few options that I have considered:

  1. Use a package manager to install software on B: this isn't an option for me because the software available in the package manager is very out of date.
  2. Install the compiler and other build tools on B: I'd rather not install build tools on the production machine due to various constraints.
  3. Manually copy the binaries from A to B: this is error-prone, and I'd like to make sure that the binaries are installed in a consistent manner across production machines.
  4. Install only make on B, transfer the source directory, and run sudo make install on B: this is the best solution I've found so far, but for some reason (perhaps clock offsets), make will attempt to re-build the software that should have already been built, which fails since the build tools aren't installed on B. Since my machines also happen to have terrible I/O speeds, transferring the source directory takes a very long time.

What would be really nice is if there were a way to make some kind of package containing the built binaries that can be transferred and executed to install the binaries and configuration files. Does any such tool exist?

  • 2
    Option 5: Build your software and make a software package on A, install that package on B. Like this: stackoverflow.com/questions/880227/… – Andrew Henle May 23 '17 at 15:03
  • Are A and B essentially identical in terms of software versions and so on? And does the package have a lot of dependencies? If the package doesn't then it may still work if A and B differ. If it does have a lot of dependencies, then it probably won't work unless A and B are very similar. – Faheem Mitha May 23 '17 at 16:24
  • A and B are identical except that B doesn't have the compiler and other build tools. There are some dependencies - what I'm working on right now (although not the only thing I'm asking this question about) is cryptsetup, which has dependencies on e2fsprogs, LVM, and libgcrypt, which depends on libgpg-error, and so on. – millinon May 23 '17 at 19:15
2

Using what you have so far and if the makefile is generated with GNU autotools, I would set the target location or install path with

./configure --prefix=/somewhere/else/than/the/usual/usr/local

and then run

make && make install

and finally copy the files from the prefix folder to the usr/ folder in the other machine. This is assuming both machines have the same architecture, if not, then use the according cross toolchain.

  • I like this idea - I'll try it when I have to build a major package next. However, I'm concerned that it wouldn't handle cases beyond just copying files - make install sometimes does more complex steps like symlinking different versions of libraries and whatnot. Would just a simple copy operation following make install with a prefix handle special cases? – millinon May 23 '17 at 19:20
  • I've used this a few times with some success. However, I'm having some problems with the prefix being used at runtime. For example, I cross compiled OpenSSL, using a prefix to 'install' the built files in /home/millinon/openssl-build. I can then easily copy the files from /home/millinon/openssl-build onto the target machine. However, when I then try to run OpenSSL on the machine, I get an message like this: WARNING: can't open config file: /home/millinon/openssl-build/ssl/openssl.cnf. In this case, I want to use a prefix for building, but not for installation. – millinon Jun 6 '17 at 20:50
  • @millinon Sometime ago, I had to crosscompile Valgrind and got the same problem then. What I did as a quick manual solution was to compile and install it to a prefix dir in the host system. Then I recompiled the application with ./configure --prefix=/usr and didn't execute make install, but instead searched the files by name in the source folder following the structure of the previous install folder, and copied them to the target system. Quite a hack, but worked! – marc Jun 7 '17 at 14:05
  • Hmm, building it twice isn't a bad idea in the case of using a decently fast cross-compiler - I'll try that with OpenSSL. – millinon Jun 7 '17 at 16:06
  • Some software source bundles have makefiles that support a DESTDIR argument to make install that does exactly what I need. The sotware is 'installed' to the specified directory, making it fairly easy to copy the files onto another machine in a consistent way, and runtime paths aren't messed with. Thanks, Python! – millinon Jun 13 '17 at 18:18
2

The cleanest way to do it would probably be to use the packaging tools the OS uses to create a package for the application, and install it like any other. How to do it varies between the package managers and systems), and there's a certain learning curve there.

Manual installing could be made somewhat easier if the source package supports installing the software within some subtree (e.g. /opt/packagename or /usr/local/packagename). Compile and install on one machine, then copy just that subtree to the same location on the other machine. The directory should include all of the relevant files and only them.

If you need changes in /etc, you'll have to do those manually. Also, to actually access the binaries, you'll have to either symlink them to some directory in your path, or add the packages bin directory to path. Most packages using autoconf/automake can take the --prefix argument to the ./configure script to set the install path.

In any case, you need to find out what libraries etc. the application you compiled needs, and make sure you have compatible versions on both machines.

  • I don't think there's a native packaging system built into the OS, but I may be able to use RPM if I can build busybox, so that's a possibility. – millinon May 23 '17 at 19:17
  • @millinon, you mentioned in the question "the software available in the package manager", which made it seem like your OS used some packaging system. cryptsetup, e2fsprogs and LVM make it sound like Linux, is there some Linux distribution that doesn't use any sort of a package manager? – ilkkachu May 23 '17 at 19:28
  • It is a version of μClinux. It has the opkg package manager, but a lot of common packages are missing from the repository, and the packages that are present are very old versions. – millinon May 23 '17 at 19:30
  • Hmm, so I could create .ipk packages from the prefix directory? That sounds like it would work pretty well, although I don't know how much additional work it would take. – millinon May 23 '17 at 19:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.