Search code examples
buildcross-compilingautotoolsconfigurelibtool

cross-compile yuma123 using autotools for a MIPS target


I'm trying to cross-compile the yuma123 open source package on a Ubuntu 18.04 development system to a MIPS target, where yuma123 uses Autotools and shared libraries.

I am using a directory INSTALL_PREFIX=/tmp/yuma123 as a staging area for files to be copied to the MIPS target.

The code (cross-)compiles and links without any errors using:

autoreconf -i -f
./configure ...
make

However, how do I install to $INSTALL_PREFIX?

Should I specify some --prefix= options to ./configure as follows:

./configure \
    --target=mipsel-buildroot-linux-gnu \
    --host=mipsel-buildroot-linux-gnu \
    --build=x86_64-unknown-linux-gnu \
    --prefix=$INSTALL_PREFIX/usr \
    --sysconfdir=$INSTALL_PREFIX/etc \
    --localstatedir=$LOCALSTATEDIR \
    --program-prefix=""

or should I specify DESTDIR= when I sudo make install as follows:

sudo make DESTDIR=$INSTALL_PREFIX install

What do I need to set above to ensure that libtool handles the $INSTALL_PREFIX directory correctly for shared libraries when cross-compiling in this way?


Solution

  • However, how do I install to $INSTALL_PREFIX?

    Should I specify some --prefix= options to ./configure

    [...]

    or should I specify DESTDIR= when I sudo make install[?]

    You should use DESTDIR for your use case, although in practice, it's possible that you could get away with using --prefix.

    The --prefix option conveys the prefix of the intended permanent installation location to the Autotools. Under some circumstances, this path or paths derived from it may end up being incorporated into the built binaries (RPATHs, config-file locations, etc.) or into built documentation. This is especially true if you're using libtool. That's obviously undesirable if the prefix is not reflective of where you intend the files actually to live on the target system.

    DESTDIR, on the other hand, is for exactly the purpose you describe: installing into a into a staging area or an alternative root. This is what package builders generally use, for example, though I suspect that the alternative root angle was the one that originally inspired the facility. Note, too, that if you're installing to a staging area then you probably don't need to use sudo to make install.