How to uninstall RStudio (server) under Ubuntu from source build - linux

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.

Related

Installing lapis on linux mint (alongside lua 5.3)

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.

I cannot Uninstall Tcl from my linux system

I installed tcl to learn it, however, I installed all the files in the wrong location. I am trying to uninstall it, But the uninstall file does not work. I am trying to carry out the instructions form their website:
To uninstall ActiveTcl, run the "uninstall.tcl" script that is located in the directory where you extracted the ActiveTcl archive. Note that you must use the "wish" in the distribution you wish to uninstall. For example:
% /path/Tcl/bin/wish /path/Tcl/lib/ppm/log/ActiveTcl/uninstall_ActiveTcl.tcl
stored, by default, in the directory /lib/ppm/log/ActiveTcl. You must use the wish interpreter from the distribution you wish to uninstall. Ensure that you do not run the uninstall script from a directory that will be removed during the uninstallation.
For example:
% /path/Tcl/bin/wish /path/Tcl/lib/ppm/log/ActiveTcl/uninstall_ActiveTcl.tcl
Note: if you are uninstalling both ActiveTcl and Tcl Dev Kit, uninstall Tcl Dev Kit before uninstalling ActiveTcl.
There is no uninstall_ActiveTcl.tcl. I do see an "uninstall" file but it does not have an extension, and I do not know how to run it.
Any help is appreciated
Thank you
Try editing the file to a uninstall.tcl file and see if that works. Take a back-up first though. Because we might need that file later
I re-installed it in a new location, compared the files that were installed between the old and the new location and deleted the file sin the old location. Unfortunately I could not delete many of the hidden files, as I did not know if they were there originally or if they belonged to Tcl. I am really surprised and disappointed there is no easy way to uninstall tcl properly.
I strongly suspect that you should uninstall ActiveTcl as follows:
Open a command prompt
Change directory to where you found the install file - e.g.
$ cd path_to_Tcl_installation/bin
Run the file
$ ./uninstall
On linux systems, you don't need any particular file extension in order to be able to run a file.
I don't know CentOS but a little googling led me to a forum thread that describes how to open a command prompt.
Good luck

Run time installation directory of debian package contents

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.

Freeswitch mod_java installation problem

I am trying to install mod_java on ubuntu.
I have installed the latest java(1.6).
I have configured freeswitch with mod_java module enabled in module.conf.xml
then when i run the make file, it says:
freeswitch_java.h:5:17: error: jni.h: No such file or directory
I have searched through the java installtion folders, but did not find any include folder or jni.h.
Can anyone help, what is being the problem here.
Thanks for reading this question.
I had the same problem. The solution was to run configure with the option --with-java:
./configure --with-java=/usr/lib/jvm/java-1.6.0-openjdk/include/
I don't know if it makes any difference but I added mod_java after building freeswitch without it. It was disabled in my initial build in module.conf.xml but afterwards I ran the above command plus:
make mod_java-install
It worked for me on ubuntu with openjdk. Are you using the Sun JDK? Maybe in the version you have dont have the include folder which has the source files. Try installing the other JDK. Or try and see of ther are some other related packages in apt that will get you the include folder.
Type this linux command to locate your jni.h file on your filesystem.
locate jni.h
you should be able to get it somewhere
in /usr/lib/java directory or some other directory
depending upon your java home.
copy paste the jni.h in src/include folder of your freeswitch src.
It will throw you some more errors for different .h files
just copy all of them to your src/include folder.
in latest freeswitch, installing through Makefile, its not possible to configure as the Makefile downloads and installs. Its possible by modifying the Makefile.in file to add the include path
mod_java_la_CPPFLAGS
-I/usr/lib/jvm/default-java/include \

Install multiple versions of a package

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.

Resources