4 ms·

> ./configure && make && make install Don't do that. Particularly don't do that on Ubuntu, this is a pretty sure way to break something. Build a Debian package

by wazoox 14y ago

> ./configure && make && make install Don't do that. Particularly don't do that on Ubuntu, this is a pretty sure way to break something. Build a Debian package, it's not that hard. For example, use "checkinstall", it'll build automatically one for you.

bradly 14y ago
For the casual Linux user, can you explain why './configure && make && make install' is a bad idea? Thanks.
- josephlord 14y ago
  Someone else can probably explain more issues but how are you going to remove it or update it later?
- derleth 14y ago
  > For the casual Linux user, can you explain why './configure && make && make install' is a bad idea? Thanks. It isn't necessarily, given that the Autotools configure installs to /usr/local by default, which is a directory tree explicitly reserved for installation of software outside the package system. Installing shared libraries can cause problems, but that's rare because shared libraries are versioned in Linux, as opposed to Windows, which greatly reduces the incidence of DLL Hell. In short, a program might find a shared library that isn't the one it wants, but it very likely won't. Similarly, installing your own executable files might cause problems for scripts. This could be more serious, but, in practice, I've installed a newer version of Perl outside the package system and everything works fine. The biggest hassle of doing things outside the package system is the simple fact you don't have the package managers doing the scutwork for you. You have to do your own dependency tracking, your own configuration, and your own update management. There is no really easy way to uninstall anything. You quickly come to realize why we have package management in the first place, if you really go nuts with this stuff. ;) So. The easy advice here is "Wait for the PPA", which the post itself mentions a few times. That will give you a nice little package, albeit not one from the official repos. I do that with VLC and couldn't be happier. But doing this little dance with Wine, building it yourself, is unlikely to cause problems if you follow the instructions.
  - nitrogen 14y ago
    Installing shared libraries can cause problems, but that's rare because shared libraries are versioned in Linux, as opposed to Windows, which greatly reduces the incidence of DLL Hell. In short, a program might find a shared library that isn't the one it wants, but it very likely won't. In fairness to Windows (and I never thought I would say that), .DLL files are now versioned via WinSxS (https://en.wikipedia.org/wiki/Side-by-side_assembly https://en.wikipedia.org/wiki/Side-by-side_assembly).
    - beagle3 14y ago
      > In fairness to Windows (and I never thought I would say that), .DLL files are now versioned via WinSxS Apparently, that's not working as well as MS hoped, either from a technical or adopting perspective: From the same wikipedia article: - However, runtime libraries in Visual C++ 2010 no longer use this technology; instead, they include the version number of a DLL in its file name, which means that different versions of one DLL will technically be completely different DLLs now. - a bug in sxs.dll causes heap corruption, leading to application crashes. This issue is not fixed by any XP service packs. Users must manually install a QFE (Quick Fix Engineering). It should be noted that including the version of the library in the filename has been a simple solution that's been used in Unix since the early '90s, when shared libraries become fashionable. (Oh, Ultrix - how I hated not having shared libraries when I had to use you... Luckily, you're dead now)
- lloeki 14y ago
  Read about the FHS (while its use is evolving), it is still a good reference). Typically, stuff installed in secondary /usr/{bin,lib,...}, and primary (/bin,...) hierarchies is handled by package managers, which handle conflicts in a bulletproof way. This means that if you install some files manually that happen to be in use by some package, the system won't know about it, and if not and you install a conflicting package afterwards, the package manager will barf at you because there's a file there already. Also it will be hard to know which files to remove (e.g when upgrading/uninstalling the manually compiled software) save for a rare few that provide a make uninstall or actually reinstalling, capturing stdout and looking for which files got installed. To sum it up it is a problem of tracking and consistency. In short, if you ever want to build software yourself there are two possible destinations, and hence two solutions: - put it in primary/secondary hierarchy: make a package for your package manager - put it in tertiary hierarchy (/usr/local) or optional software (/opt/your_software_name): use PREFIX/--prefix or whatever idiom the build system uses for controlling where the files will end up. More often than not with tertiary you don't even need to set up PATHs and include directories (think library and dependencies) and whatnot.
- acqq 14y ago
  https://help.ubuntu.com/community/CheckInstall https://help.ubuntu.com/community/CheckInstall " Use CheckInstall instead of just running "sudo make install", as that will likely put files all over the filesystem, with no easy way of removing them if things go wrong. If in the future you try to install a package that contains the same file as the software you are compiling, you will receive errors and the software you compiled may stop working."
ambrop7 14y ago
If only there was an easy way for a user to add a few patches to an Ubuntu package. Not hacks like checkinstall that don't do dependencies or anything. Maybe something like copying /usr/portage/app-emulation/wine to /usr/local/portage/app-emulation/ and adding an epatch command in. Or if you're lucky just save the patches into /etc/portage/patches/app-emulation/wine/. I'll never leave Gentoo :)
- kiallmacinnes 14y ago
  # Get the source apt-get source $package # Copy the patch in cp my_patch.diff $package-$version/debian/patches echo "my_patch.diff" >> $package-$version/debian/series # Build the package dpkg-buildpackage -us -uc # Install the newly built package dpkg -i package.deb
  - ambrop7 14y ago
    Sure. But: - How do I make sure any other systems I own also get the patched version? (Gentoo: set up an overlay and commit the fixed package) - How do I get notified when the package was updated upstream and my patch is no longer being applied? (Gentoo: emerge tells you when a new package is being installed from a different repository than the currently installed package) You're probably going to say I should use a PPA, but not everyone is comfortable with signing up for a proprietary service and accepting their TOS. And setting up a PPA is way more complicated than maintaining a portage overlay in some VCS. And of course I have to submit a new package whenever a new version of Ubuntu comes out.
nitrogen 14y ago
It's also a good idea to replace "make" with "make -jN", where N is the number of CPU threads on your system. Saves a ton of time.
- robotmay 14y ago
  I can't believe I didn't know this :\
- usefulcat 14y ago
  For bash: alias make="nice make -j $(grep 'processor' /proc/cpuinfo | wc -l)"
  - cpeterso 14y ago
    make -l (--load-average) will throttle the number of make jobs, so you can specify a big -j to have many ready jobs but ensure you don't exceed run more than your number of CPUs.
  - eik3_de 14y ago
    > grep 'processor' /proc/cpuinfo | wc -l or use "grep -c" instead of piping through wc
- stusmall 14y ago
  Alternately you can run -j without an argument and it won't set a limit on the number of jobs it kicks off.
  - nitrogen 14y ago
    Even if you have unilmited RAM, at some point context switching overhead will slow down the process as you add extra simultaneous jobs. Moreover, with the Linux BFS scheduler, optimum performace is achieved when the number of jobs is equal to the number of CPUs.
  - jlgreco 14y ago
    Be careful with that one. I left a very beefy (32 cores, 64GB ram) CS department server unresponsive for several minutes doing that with the linux kernel.
ck2 14y ago
also, always check for make test

by wazoox 14y ago

bradly 14y ago

For the casual Linux user, can you explain why './configure && make && make install' is a bad idea? Thanks.

josephlord 14y ago
Someone else can probably explain more issues but how are you going to remove it or update it later?
derleth 14y ago
> For the casual Linux user, can you explain why './configure && make && make install' is a bad idea? Thanks. It isn't necessarily, given that the Autotools configure installs to /usr/local by default, which is a directory tree explicitly reserved for installation of software outside the package system. Installing shared libraries can cause problems, but that's rare because shared libraries are versioned in Linux, as opposed to Windows, which greatly reduces the incidence of DLL Hell. In short, a program might find a shared library that isn't the one it wants, but it very likely won't. Similarly, installing your own executable files might cause problems for scripts. This could be more serious, but, in practice, I've installed a newer version of Perl outside the package system and everything works fine. The biggest hassle of doing things outside the package system is the simple fact you don't have the package managers doing the scutwork for you. You have to do your own dependency tracking, your own configuration, and your own update management. There is no really easy way to uninstall anything. You quickly come to realize why we have package management in the first place, if you really go nuts with this stuff. ;) So. The easy advice here is "Wait for the PPA", which the post itself mentions a few times. That will give you a nice little package, albeit not one from the official repos. I do that with VLC and couldn't be happier. But doing this little dance with Wine, building it yourself, is unlikely to cause problems if you follow the instructions.
- nitrogen 14y ago
  Installing shared libraries can cause problems, but that's rare because shared libraries are versioned in Linux, as opposed to Windows, which greatly reduces the incidence of DLL Hell. In short, a program might find a shared library that isn't the one it wants, but it very likely won't. In fairness to Windows (and I never thought I would say that), .DLL files are now versioned via WinSxS (https://en.wikipedia.org/wiki/Side-by-side_assembly https://en.wikipedia.org/wiki/Side-by-side_assembly).
  - beagle3 14y ago
    > In fairness to Windows (and I never thought I would say that), .DLL files are now versioned via WinSxS Apparently, that's not working as well as MS hoped, either from a technical or adopting perspective: From the same wikipedia article: - However, runtime libraries in Visual C++ 2010 no longer use this technology; instead, they include the version number of a DLL in its file name, which means that different versions of one DLL will technically be completely different DLLs now. - a bug in sxs.dll causes heap corruption, leading to application crashes. This issue is not fixed by any XP service packs. Users must manually install a QFE (Quick Fix Engineering). It should be noted that including the version of the library in the filename has been a simple solution that's been used in Unix since the early '90s, when shared libraries become fashionable. (Oh, Ultrix - how I hated not having shared libraries when I had to use you... Luckily, you're dead now)
lloeki 14y ago
Read about the FHS (while its use is evolving), it is still a good reference). Typically, stuff installed in secondary /usr/{bin,lib,...}, and primary (/bin,...) hierarchies is handled by package managers, which handle conflicts in a bulletproof way. This means that if you install some files manually that happen to be in use by some package, the system won't know about it, and if not and you install a conflicting package afterwards, the package manager will barf at you because there's a file there already. Also it will be hard to know which files to remove (e.g when upgrading/uninstalling the manually compiled software) save for a rare few that provide a make uninstall or actually reinstalling, capturing stdout and looking for which files got installed. To sum it up it is a problem of tracking and consistency. In short, if you ever want to build software yourself there are two possible destinations, and hence two solutions: - put it in primary/secondary hierarchy: make a package for your package manager - put it in tertiary hierarchy (/usr/local) or optional software (/opt/your_software_name): use PREFIX/--prefix or whatever idiom the build system uses for controlling where the files will end up. More often than not with tertiary you don't even need to set up PATHs and include directories (think library and dependencies) and whatnot.
acqq 14y ago
https://help.ubuntu.com/community/CheckInstall https://help.ubuntu.com/community/CheckInstall " Use CheckInstall instead of just running "sudo make install", as that will likely put files all over the filesystem, with no easy way of removing them if things go wrong. If in the future you try to install a package that contains the same file as the software you are compiling, you will receive errors and the software you compiled may stop working."

ambrop7 14y ago

If only there was an easy way for a user to add a few patches to an Ubuntu package. Not hacks like checkinstall that don't do dependencies or anything. Maybe something like copying /usr/portage/app-emulation/wine to /usr/local/portage/app-emulation/ and adding an epatch command in. Or if you're lucky just save the patches into /etc/portage/patches/app-emulation/wine/. I'll never leave Gentoo :)

kiallmacinnes 14y ago
# Get the source apt-get source $package # Copy the patch in cp my_patch.diff $package-$version/debian/patches echo "my_patch.diff" >> $package-$version/debian/series # Build the package dpkg-buildpackage -us -uc # Install the newly built package dpkg -i package.deb
- ambrop7 14y ago
  Sure. But: - How do I make sure any other systems I own also get the patched version? (Gentoo: set up an overlay and commit the fixed package) - How do I get notified when the package was updated upstream and my patch is no longer being applied? (Gentoo: emerge tells you when a new package is being installed from a different repository than the currently installed package) You're probably going to say I should use a PPA, but not everyone is comfortable with signing up for a proprietary service and accepting their TOS. And setting up a PPA is way more complicated than maintaining a portage overlay in some VCS. And of course I have to submit a new package whenever a new version of Ubuntu comes out.

nitrogen 14y ago

It's also a good idea to replace "make" with "make -jN", where N is the number of CPU threads on your system. Saves a ton of time.

robotmay 14y ago
I can't believe I didn't know this :\
usefulcat 14y ago
For bash: alias make="nice make -j $(grep 'processor' /proc/cpuinfo | wc -l)"
- cpeterso 14y ago
  make -l (--load-average) will throttle the number of make jobs, so you can specify a big -j to have many ready jobs but ensure you don't exceed run more than your number of CPUs.
- eik3_de 14y ago
  > grep 'processor' /proc/cpuinfo | wc -l or use "grep -c" instead of piping through wc
stusmall 14y ago
Alternately you can run -j without an argument and it won't set a limit on the number of jobs it kicks off.
- nitrogen 14y ago
  Even if you have unilmited RAM, at some point context switching overhead will slow down the process as you add extra simultaneous jobs. Moreover, with the Linux BFS scheduler, optimum performace is achieved when the number of jobs is equal to the number of CPUs.
- jlgreco 14y ago
  Be careful with that one. I left a very beefy (32 cores, 64GB ram) CS department server unresponsive for several minutes doing that with the linux kernel.

ck2 14y ago

also, always check for make test