1

Since downgrading GNU make from 4.1 to 3.81, make isn't working. This is the method used for the downgrade:

  • In /usr/bin renamed make to make-4.1
  • Downloaded make 3.81 from gnu.org
  • Extracted make-3.81.tar.bz2 into /usr/bin
  • Renamed make-3.81 to make.

Now when I run make it's like it doesn't exist. How to get GNU make 3.81 working?

  • 2
    Where's the compiling step? – thrig Jul 5 '16 at 20:53
  • You mean I need to I need to compile from source? – LostSoul Jul 5 '16 at 20:58
  • 3
    I think, your question is "How do I install an older version of make on my <DISTRO-NAME>, and pin it". That will yield better results. You will probably get an answer using your distributions package manager, which is the much cleaner approach to software installation. – Alex Stragies Jul 5 '16 at 21:13
  • Thanks for pointing me in the right direction. I started a new thread at unix.stackexchange.com/questions/294121/…. – LostSoul Jul 5 '16 at 22:23
  • 1
    This link is specific to debian, but much of it is relevant to other distros too: wiki.debian.org/DontBreakDebian – cas Jul 6 '16 at 9:54
2

Firstly, breaking vendor space (here, the /usr/bin directory) is rather a bad idea, as other vendor packages may depend on make 4.1 being available, or vendor updates to make may conflict or break on account of the manual changes made to the vendor space, or perhaps undo your changes. A better option is to install your version of make elsewhere, for example to /usr/local/bin—though on *BSD systems that area is used by packages, so check your vendor's documentation on where things should go, then pick somewhere else when making a software depot of your own, e.g. /opt or whatever made-up name is suitable to your environment. Granted, this does mean that you are responsible for updates (in particular, security updates) to the software under that software depot, a drawback that can vary from negligible to horrific, depending on the software and site.

As to the compile step, it would run (with a custom software depot path of /usr/local) along the lines of:

tar xjf make-3.81.tar.bz2
cd make-3.81
./configure --prefix=/usr/local && make && make install

Any application that then needs the olden version of make would need to set the PATH environment variable to list /usr/local/bin before the /usr/bin (or now on some Linux, also /bin) directories.

env PATH=/usr/local/bin:$PATH yoursoftwarethatneedsmake3.81 ...

Or manually in the shell rc or webserver or whatnot configuration. This could be problematical should an application need the old version of make, but does need something else from /usr/bin that is masked by other software under /usr/local/bin; to avoid this, make could be installed to a versioned directory:

./configure --prefix=/opt/`uname -m`/make-3.81

And then applications would need (assuming amd64 on Linux) /opt/x86_64/make-3.81/bin listed first in their PATH. Or, if you only run one architecture you could simplify the path to just /opt/make-3.81, or go more complicated with /opt/centos7/x86_64/make-3.81 to support multiple operating systems under a single tree. As additional software is installed in such a fashion, something like Stow may help managing such versioned installs without making PATH tediously long. With sufficient care, attention, and resources, a software depot built something along these lines may evolve into something like Apollo, though the ideal software depot form (if any!) for a particular site will vary depending on the size of the site, how much out-of-vendor-control software needs to be installed, etc.

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.