A few days ago I had a few problems while installing trying to install lapis on my new installation of linux mint. The main problem was that I wanted to have lua 5.3 as the main lua interpreter on my system, but lapis only works with lua 5.1.
This is how I ended up installing it
Note: Instructions for normal installation process, with aditional lua 5.3 being optional
Prerequisites
First of all install all the prerequisites with apt-get install libreadline-dev libncurses5-dev libpcre3-dev libssl-dev perl make build-essential*. This is all you should need to install lua, luarocks and openresty.
* copied from openresty website
Lua Interpreter(s)
Next, go to https://www.lua.org/versions.html and download the latest version of lua5.1 (wget https://www.lua.org/ftp/lua-5.1.5.tar.gz). Then extract the downloaded file tar -xf lua-5.1.5.tar.gz and optionally rename the directory mv lua-5.1.5 lua51.
Now you can simply build and install lua by moving to the directory cd lua51 and running make make linux and sudo make install
Aditionally, you might want to have lua5.3 installed on your system as the main lua interpreter. Luarocks doesn't seem to particularly like this kind of setup though, so I recommend the following:
First download and extract (and optionally rename) both lua5.1 and lua 5.3; go to the lua 5.1 directory and open Makefile in a text editor; Edit lines 12-15 to install lua in another directory. For me it worked to just add /lua51 to INSTALL_TOP (line 12). Next go to line 44 and change the names of the binaries (I chose lua51 and luac51), optionally do the same with the man pages (this requires also changing them in the doc subdirectory).
The next step is to go to the src/ directory and edit the makefile there as well: in lines 32 and 35 change the names as you did in the previous makefile (lua51 and luac51 in my case).
After this you can just make linux and sudo make install as described above.
Luarocks
Now you need to install luarocks on your system. Start by downloading the latest release of luarocks (http://keplerproject.github.io/luarocks/releases/) and extract it. Again, you can rename it to luarocks/ reduce typing. cd to the directory you just extracted and run ./condigure.
If you changed the lua installation path, you will have give some parameters to the configure script:
For lua 5.1 ./configure --lua-version=5.1 --with-lua=/usr/local/lua51 --lua-suffix=51 is how I had to do it (--lua-suffix is what I added to lua and luac and --with-lua tells it where the bin, lib, etc. subdirectories are; only relevant if you changed INSTALL_TOP in the makefile)
Optionally you can now proceed to (download, ) build and install lua 5.3 with its standard configuration. After that you can even go back to the luarocks directory and repeat ./configure, make build and make install and it should automatically install itself with lua 5.3 and leave the installation for lua5.1 intact**.
** the luarocks executable is actually just a symlink to luarocks-VERSION (where VERSION can be 5.1, 5.3, etc.) in the same directory. Each time you install luarocks this link is overwritten to point to the latest installation, but the other executables are still there.
OpenResty
The next step is to install OpenResty: open http://openresty.org/en/installation.html and check the prerequisite section. It should say the same as at the beginning of this answer. If not, install any missing package now. You can also just follow the installation instructions there, but I will be repeating it anyway; go to http://openresty.org/en/download.html and download the latest version. Extract the downloaded archives (and rename the new directory to simply openresty). cd to the new directory and run ./configure --with-pcre-jit --with-ipv6 (this might take a while), make (this might take an even longer while) and sudo make install.
At this point everything except lapis itself should be set up and working.
Lapis
To install lapis, type sudo lurocks install lapis (user luarocks-5.1** instead if you have installed more than one version of it).
Congratulations! If you got no errors, you should now have lapis installed and ready to use :)
** see section Luarocks.
Related
I was trying to install RStudio-v2022.07.1-554 (server) under Ubuntu 22.04 LTS (arm64). Because there doesn't exist a binary for arm64, I have to build the RStudio from the source. After download the source (tag 2022.07.1-554), and installed all dependencies. I was able to install the binary.
However, after make install, I found out that the default CMAKE_INSTALL_PREFIX was set to /usr/local, not as the INSTALL file claimed: /usr/local/lib/rstudio-server! Now, all the 1560 library and binary files of RStudio-server are spread over under the folder /usr/local(Thank you RStudio team!):
/usr/local/./README.md
/usr/local/./INSTALL
/usr/local/./COPYING
/usr/local/./NOTICE
/usr/local/./SOURCE
/usr/local/./VERSION
...
When I try to make uninstall, I found out the makefile doesn't define any uninstall action. Fortunately, there is an install_manifest.txt file which listed all the files installed under usr/local. What I could think of to "uninstall" RStudio is to use shell script to loop through the files list and remove them one by one.
Is there any better way to uninstall the RStudio-server compiled from source other than manually delete the files one by one.
Thank you for your attention and reply in advance.
I am trying my hands new on Linux.
The following command is very useful:
sudo apt-get install <application>;
As it adds the application into the linux programs list and automatically upgrades it while running the update manager.
But I would like to get more knowledge on installing the programs from the .tar.gz archives as well.
So I do:
Extract the archive
./configure;
make;
make install;
I have two questions in this process:
1) I read in the forum that "make install" is not good if we are updating the binaries.
So should I just do "make" and the "install" ?
2) Second question is that is there a way to add the program installed in such manner to the Linux Software Update list so that I do not have to use the terminal for every new version that is released
Installing programs from tarballs:
You really do not want to install packages from .tar.gz when they are in the repositories. It is much harder to update or remove it manually than you could do with apt-get.
If you really have to compile the program yourself use checkinstall instead of make install. This creates a package you can install it via the package management and later remove using apt-get. This is much cleaner.
Also you may want to type
./configure && make && sudo checkinstall
instead of the commands you wrote. This way the program is only compiled if the configuration succeeded. The package is only built if the compilation succeeded. With ; instead of && all processes would be attempted no matter if its prerequisites are matched.
Graphical package managers
You can install your packages from GUI programs. Kubuntu uses for example uses muon for this, but the programs vary between distributions.
make install is "not good" if you want to be able to easily remove the files associated with a package as there is no log of the work it does and often no easy way to reverse the process. That has little to nothing to do with updating the software though (though updates can certainly run into related issues).
No, you can't add the manually compiled and installed software to your distributions list of packaged software (other than through something like checkinstall or creating a package yourself) since that's exactly what you were avoiding in the first place.
That all being said if the package exists for your distribution and you want to build it from source yourself you can often just build a more-or-less official version of the package from the distributions source package.
I already installed asteriskNow 2.0 ISO, thus after system installation, i've already have built-in asterisk within CentOS. I do not need to download source package and compile the source files. But right now, i have an situation that requires to recompile asterisk again.
I checked it out the installation tutorial which needs to go to the asterisk source directory to execute following commands:
# make clean
# ./configure
# make menuselect
# make install
# make samples
My questions : Is it the asterisk source directory means the directory which has asterisk installation files? But in my case, i do not download and compile the asterisk source ever.What should i do?
I asked myself: It needs to download source from and execute the following commands:
wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-1.8.17.0.tar.gz
tar xzf asterisk-1.8.17.0.tar.gz
cd asterisk-1.8.17.0
./configure
make
make install
I have a debian package that I built that contains a tar ball of the files, a control file, and a postinst file. Its built using dpkg-deb and it installs properly using dpkg.
The modification I would like to make is to have the installation directory of the files be determined at runtime based on an environment variable that will be set when dpkg -i is run on the deb file. I echo out the environment variable in the postinst script and I can see that its set properly.
My questions:
1) Is it possible to dynamically determine the installation directory at runtime?
2) If its possible how would I go about this? I have read about the rules file and the mypackage.install files but I don't know if either of these would allow me to accomplish this.
I could hack it by copying the files to the target location in the posinst script but I would prefer to do it the right way if possible.
Thanks in advance!
So this is what I found out about this problem over the past couple of weeks.
With prepackaged binaries you can't build a debian package with a destination directory dynamicall determined at runtime. I believe that this might be possible if installing a package that is built from source where you can set the install directory using configure. But in this case since these are embedded Ubuntu machines they don't have make so I didn't pursue such an option. I did work out a non traditional method (hack) for installing that did work. Since debian packages simply contain a tar ball relative to / simply build your package relative to a directory under /tmp. In the postinst script you can then determine where to copy the files from the archive into a permanent location.
I expected that after rebooting and the automatic deletion of the subdirectory under /tmp that dpkg might not know that the file package existed. This wasn't a problem. When I ran 'dpkg -l myapp' it showed as still installed. Updating the package using dpkg/apt-get also worked without a hitch.
What I did find is that if you attempted to remove the package using 'dpkg -r myapp' that dpkg would try and remove /tmp which wasn't good. However /tmp isn't easily removed so it never succeeded. Plus in our situation we never remove packages but instead simply upgrade them.
I eventually had to abandon the universal package due to code differences in the sources resulting in having to recompile per platform but I would have left it this way and it did work.
I tried using --instdir to change the install directory of the package and it does relocate the files but dpkg fails since the dpkg file can't be found relative to the new instdir. Using --instdir is sort of like a chroot. I also tried --admindir and --root in various combinations to see if I could use the dpkg system relative to / but install relocate the files but they didn't work. I guess rpm has a relocate option that works but not Ubuntu.
You can also write a script that runs dpkg-deb with a different environment for 6 times, generating 6 different packages. When you make a modification, you simply have to run your script, and all 6 packages gets generated and you can install them on your machines avoiding postinst hacking!
Why not install to a standard location, and simply use a postinst script to create symbolic links to the desired location? This is much cleaner, and shouldn't break anything in dpk -I.
I want to install multiple versions of a package (say libX) from src. The package (libX) uses Autotools to build, so follows the ./configure , make, make install convention. The one installed by default goes to /usr/local/bin and /usr/local/lib and I want to install another version of this in /home/user/libX .
The other problem is that libX is a dependency for another package (say libY) which also uses autotools. How to I make libY point to the version installed in /home/user/libX ? There could be also a possibility that its a system package like ffmpeg and I want to use the latest svn version for my src code and hence build it from src. What do i do in that case ? What is the best practice in this case so that I do not break the system libraries?
I'm using Ubuntu 10.04 and Opensuse 10.3.
You can usually pass the --prefix option to configure to tell it to install the library in a different place. So for a personal version, you can usually run it as:
./configure --prefix=$HOME/usr/libX
and it will install in $HOME/usr/libX/bin, $HOME/usr/libX/lib, $HOME/usr/libX/etc and so on.
If you are building libY from source, the configure script usually uses the pkg-config tool to find out where a package is stored. libX should have included a .pc file in the directory $HOME/usr/libX/lib/pkgconfig which tells configure where to look for headers and library files. You will need to tell the pkg-config tool to look in your directory first.
This is done by setting the PKG_CONFIG_PATH to include your directory first.
When configuring libY, try
PKG_CONFIG_PATH=$HOME/usr/libX/lib/pkgconfig:/usr/local/lib/pkgconfig ./configure
man pkg-config should give details.