My Debian system has an old version of the FLEXI-STREAMS library installed as a dependency of some other Debian package. As a result, on every Lisp implementation on the system, ASDF automatically loads that library from somewhere deep in the bowels of the filesystem.
Since Quicklisp uses ASDF, (ql:quickload :flexi-streams) always loads the Debian version of FLEXI-STREAMS, and never downloads the latest version from the Quicklisp repository.
Removing the Debian version of this library will probably break whichever Debian package depends on it.
How do I get Quicklisp to ignore the local version and go ahead and install the latest version?
If the system is visible via ASDF, there is no way to force Quicklisp to use the Quicklisp-supplied version.
Removing the Debian version is the easiest option. If something else depends on it, that should be removed too.
Related
When we ssh onto this Linux server, it says Welcome to Ubuntu 16.04.7 LTS (GNU/Linux 4.4.0-193-generic x86_64), so this is the type of server we are on.
When we run R to launch R in the server from terminal, and then version, we get:
What is the easiest way to upgrade from version 3.4.4 to version 3.5.3? We don't want to upgrade to v4 or to the latest version quite yet until we ensure no breaking issues with our codebase on R v4, however we would like to make this upgrade to 3.5.3 so we can run an R library that requires 3.5.3+.
How can we do this from the command line on the server here, and after switching from 3.4.4 to 3.5.3 do we then need to re-install all R libraries on the server as well? I'm worried if I start running stuff from the command line and I mess up that I'll break our current R app.
I would be surprised if there is a .deb available for this OS release/R release combination.
This page only offers R 4.1, but as far back as 16.04 LTS
This page offers older R versions, but only back to 18.04 LTS
It's also possible that one of the backports on the Debian packages page would work on your system (it reports that 3.5.3 is available for Debian "jessie", although I have no idea how that lines up with Ubuntu releases).
I guess it's possible that one of those .debs works for your system though ... ? If you do install from .deb, you may have to be careful not to clobber your current version (e.g. using the --instdir argument to dpkg).
Building from source:
download the source tarball for R 3.5.3
untar, ./configure, make, sudo make install (assuming you have all the necessary development tools, system libraries, etc.; you'll have to troubleshoot/install as you go along)
It might be worth ./configure --prefix=/path/to/testdir to put the new version in a completely separate location, just to make extra-sure you don't stomp on your current install. (This would also simplify the library-path stuff below.)
Packages do need to be re-installed when switching major versions (e.g. 3.4.x to 3.5.x); one way to do it is to copy the system library of packages to a new place (adjust library paths as necessary; see R installation and administration manual).
Then, you should be able to update.packages(checkBuilt=TRUE, ask=FALSE) to update everything.
The tricky spots are (1) getting the library paths right (this will depend a bit on how things are set up in your existing installation; (2) it's conceivable that some current versions of packages on CRAN will fail to re-install/re-build under R 3.5.3. devtools::install_version() would help, although you'd have to track down the correct version manually. I recall someone posting about a package that would install an archived version by date, which could save a lot of poking around ...
I am installing OMNET++ 5.1.1. However, during the installation, it is reported that:
configure: error: Cannot build Qt apps, probably due to missing or too old Qt packages. Make sure Qt development packages are installed and newer than Qt 5.4. You can disable Qtenv by setting the WITH_QTENV variable to "no" in configure.user.
Then I download and install the Qt from https://www.qt.io/download/. But it still report the same problem. How can I solve this problem ? Thank you.
I assume you're running some kind of GNU/Linux, because on Windows and macOS, the bundled Qt libraries should just work.
Try installing the Qt5 development packages using your distro's native package manager, then they should be detected.
If you can't, or they are too old, take a look in the configure.user file, and adjust the value of the QT_PATH variable according to the instructions there.
EDIT:
Since the OS was clarified: On Windows, you don't need to download Qt, or any other library separately. They are all bundled with the OMNeT++ distribution, and should work fine.
Just make sure you always use the included mingwenv shell to install and run OMNeT++. In it, the environment variables are set up as necessary.
If you are installing OMNET++ on windows make sure you extract the zip file to a folder other than "Program Files" and deactivate your antivirus during the installation process.
I am making an R package with Rcpp. It works fine on my machine which has Rtools installed. But recently, I tried to install my package locally on a different machine (Windows) and got a compiling error. The reason was that on that machine there was no g++ compiler (for Windows, g++ is provided with Rtools). After installing Rtools, it worked just fine.
So the question is, if I upload it to CRAN, does it still requires users to install Rtools by hand? Or does the function install.package() detect and install Rtools for them?
Also, if you guys know some packages written with Rcpp, please let me know. I'd like to take a look how it works.
So the question is, if I upload it to CRAN, does it still requires users to install Rtools by hand?
No.
Or does the function install.package() detect and install Rtools for them?
No.
What happens is that CRAN builds pre-compiled binary files that can be installed by Windows and MacOS users without the need for compilers and related tools.
Also, if you guys know some packages written with Rcpp, please let me know. I'd like to take a look how it works.
rr <- devtools::revdep("Rcpp")
length(rr) ## 907
or see the Rcpp page on CRAN.
Users, e.g. people who download it via install.package(), are actually downloading a "compiled" version of the packaged called a binary that is maintained by CRAN. They will only ever need a copy of R.
On the other hand, Developers, e.g. people who are creating it, require development tools that are system specific. For those on the Windows platform, they must have a local install of Rtools on their machine. For developers on macOS, they must have their own copies of gfortran binaries and xcode developer line tools.
Lastly, there are many such Rcpp packages available to look to for inspiration...
See the Rcpp CRAN page
Pick a package and then look up the source at http://github.com/cran/packagename
View an annotated list by Dirk here.
What all are the differences between install nginx from source and install as package ?
Well to define "all differences" would be near impossible because every OS package is built differently. However, with that said...
1) Package installs are pre-built with their own options configured which also gets installed wherever they decided to put that installation once it's installed.
2) With the source, you are able to define what is built, where it should be installed, etc...
So if you are going to install via a package, you are basically forced into whatever options they set. Unless of course you decide to take their package and then re-package it to fit your requirements. But that would pretty much be a pointless as you'd be better off just installing from source at that point.
Most if not all packages also comes not only with a simple install but a simple way to uninstall the software. Where-as if you compiled and installed via source then you'll need to manually remove the installation if you no longer need it on your machine.
I'm convinced that using Dirk's package is the best way to install and maintain R on an Ubuntu system. But I want to have some fun and get used to installing R from source.
What are the most common configure flags to use when installing?
Also, if I want to install 2.14.1 and I have 2.14.0 currently installed (which was installed from source), should I first uninstall 2.14.0?
There was a recent thread somewhere about having several versions---one from the apt-get repo, one in /usr/local. Try to find that...
Otherwise, I will roll up 2.14.1 on Friday morning, Michael will do his magic and the repo will have .deb packages of 2.14.1 'real soon', sometimes within a day.
Lastly, you can see which flags are used by getting the package sources for which you just do apt-get source r-base (and that works for any Debian/Ubuntu package that way if you have source references in apt's file.
Edit: By the way, regarding the '64-bit' aspect of your question: Nada. We don't do anything differently. It is "merely" the host OS being more generous with resources. But R finds all it needs to know on its own via its configure etc logic.