5 ms·

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

by bradly 14y ago

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."

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

by 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."