I've built from source a version of GCC for Red Hat. Given that was a fairly expensive exercise, I'd like to "back up" the built version so I can avoid having to do it again on other machines or even if I scrap the VM it's currently built on.
What are my best options for doing that please?
This is what package managers are for. However, you have to build (usually) or deploy the package under the control of the package manager, because it is what keeps track of where the installed files are. You built it without using a package manager, and no longer have the complete build directory? Sorry, it's going to be quite tricky to find all the installed files.
However, if you still have the build directory and you haven't run make clean, you can just tar that up and copy that tar file somewhere, and run make install from an untarred copy of that tar file on each machine. Alternatively, you could use something like GNU Stow or XStow as a poor-man's package manager to deploy and undeploy it on various machines, by installing it to /usr/local/stow/gcc, tarring up the /usr/local/stow/gcc directory, untarring it on another machine, and then using GNU Stow to install it.
Related
I have to work with ubuntu 14.04, but I need to use cloc 1.92. The highest cloc version via package update for Ubuntu is 1.6.
https://packages.ubuntu.com/search?keywords=cloc
I did a wget https://github.com/AlDanial/cloc/releases/download/v1.92/cloc-1.92.tar.gz to download this package to my machine, but it's not showing up in the package list when I do dpkg --list. I'm not sure how to make the cloc 1.92 folder run the same way that 1.6 does on my VM, or if it's even possible to do so.
The git page for cloc explains all related aspects, and skimming over it, in the Why use cloc? section says that the "program is self-contained, only download and run it". This program is developed in Perl 5, present in all Ubuntu distros. You can check that with the command perl --version.
Simply extract the file cloc from the tar.gz and copy it in an appropiate directory, for example /usr/local/bin, and confirm it has the proper executable rights with the command chmod a+rx /usr/local/bin/cloc.
Caveat: cloc claims to use only standard Perl modules. If your installed Perl doesn't have all needed, you will have to install them using CPAN.
Edit: See the comments by Knud Larsen for manual installing as Ubuntu mantainers do.
In this case, as the program is run by an interpreter, it wasn't needed to compile it, but in general programs/libraries in source form could to be compiled and installed independently from the apt/dkpg package management, but could need other libraries/programs to operate. The mantainer of the distro ensures this dependencies are installed together with the desired package. If we want to compile/install manually, then also we have to compile/install all requirements of the program if they aren't there already.
In other cases, the additional required software for the package could be already installed in some older versions, but it is used by other installed programs that could fail if we install new versions. That is the main problem when updating software in older distros: We need to investigate and resolve any conflicts manually.
So, the second answer is: Yes, we can update software in older versions of Ubuntu, but could be impractical to do so.
When trying to install Android Studio on my Linux Laptop, I get "Unable to Run mksdcard tool" From what I can tell from searching, this is usually caused by lacking the 32 bit compatibility libraries on 64 bit Linux, however I am running it on an ARMv7 processor, using the crouton project to use Linux on my Chromebook. I have tried install the recomended packages ending in i386, but the command line returned:
Reading Package Lists... Done
Building Dependendency Tree
Reading State information... Done
E: unable to locate package [Name of package here]
E: Couldn't find any package by Regex '[Name of package]'
Does anyone know what is causing this and how I can fix it?
I've discovered a workaround.
After a little searching, I've found that we can create executable binary of the tool for the ARMv7 platform ourselves! Whupee!
Head over to GitHub and pick up the source code, mksdcard.c. Download this to wherever you'd like, but make sure you download it as mksdcard.c and not as mksdcard.c.txt, which your browser might try to do. You can always rename the file later in case you accidentally save the filename incorrectly.
Over in your chroot environment, head to the directory where you downloaded the file.
Make sure you have the gcc compilation tools installed. Try running gcc -v in an attempt to see what version of GCC you have installed. If this doesn't work, you'll need to install GCC via sudo apt-get install gcc.
Run gcc -o mkdscard mksdcard.c. This uses GCC to compile the source code into something that can be executed. After compilation has completed, you can use ./mkscard to have Linux execute the binary file, which verifies that it works.
Navigate to your Android SDK Tools directory. This is usually ~/Downloads/Android/Sdk/tools. By running ls, you'll list the files and find the version of mksdcard that your Linux distribution doesn't understand how to run. (Running ./mksdcard on this file will confirm this.)
Backup the broken binary somewhere, then delete the copy in the tools folder. (I created a backups/ directory within the Android SDK Tools folder to move it to.)
Within the directory, use rm -r mksdcard to delete the old mksdard binary.
Finally, copy your compatible binary over to take it's place, e.g. cp ~/Downloads/mksdcard . (Copies the mksdcard binary we've created to the current directory ., the Android SDK Tools folder.)
Head back over to your Android Studio installer. In the dialogue complaining about mksdcard failing, hit Retry and the installation should continue. After it's finished, be sure to apply any updates that are recommended by the environment. Enjoy!
For newer versions eg. 3.1 C4 of Android Studio running with Ubuntu on ARM32 you will also need to place mksdcard in ~/Downloads/Android/Sdk/emulator (referencing like path from Alext T.).
I have a machine that doesn't have internet access at all.
I installed the Haskell Platform on it using the installer which I got from another machine through a pendrive.
Now I want to install the package repa on my home machine which has no internet access. How should I do that?
My home machine is running Linux (Debian) and my office machine is Windows 7.
From a machine you can access the internet you can either:
Run cabal get pkg-name where pkg-name is the package you want.
Go to the package's page on Hackage and on the Downloads section there's a .tar.gz file you can download.
After you get it, transfer it to your other machine, extract it anywhere you'd like (a sandbox if you want it just in a sandbox). Then from that directory (where there's a .cabal file) run cabal install.
Package managers, such as cabal, work internally to get a package from a remote repository. I doubt there exist an easy workaround to make cabal install a package in offline mode.
Probably the easiest way is to find a compressed version of package, find a way to get them on the offline computer (local sharing, thumb drive, etc.) and install a package manually.
Using the commandline installer, one can easily install Cygwin with a list of wanted packages like so
setup-x86.exe -q -p='tar,sed,<more packages>'
Is it also possible to fix the version of the packages, something like
setup-x86.exe -q -p='tar:1.2.3,sed,<more packages>'
(this obviously doesn't work)?
The short answer to your query is, No. Cygwin's setup -x86.exe does not give you the flexibility to specify version names along with package names. As per the official doc :
The basic reason for not having a more full-featured package manager is that such a program would need full access to all of Cygwin's POSIX functionality. That is, however, difficult to provide in a Cygwin-free environment, such as exists on first installation. Additionally, Windows does not easily allow overwriting of in-use executables so installing a new version of the Cygwin DLL while a package manager is using the DLL is problematic
There are however a couple of workarounds if you want to download a specific package:
Locate a cygwin mirror that hosts the specific version. Google for your version, and if you find a mirror hosting that version, simply use that mirror before running setup -x86.exe. [source]
Maintain a local pacakge repository and use the commandline options -q -L -l x:\cygwin-local\, where your downloaded package tree is in x:\cygwin-local\ [source] . You can learn how to build and maitain packages here
Compile and install the package after you've set up cygwin using make.
This is function that Cygwin's installer now provides. By default, when running from the command line, it will install the latest version of each package, but you can specify a version with =. For example:
setup-x86_64.exe -P git=2.35.0-1,vim
will install the latest version of Vim, and version 2.35.0-1 of Git.
I have installed Node.js on an Ubuntu 64bit server using a standard apt-get and would like to profile scripts through the "--prof" flag.
Web searching shows there should be a tool to process the v8.log output located in "deps/v8/tools/linux-tick-processor" but I don't seem to have any of those directories. Do they come with the native install? should they be installed separately? if so how?
Thank you
You need to download the source package with sudo apt-get source nodejs.The path you mentioned is in there.
You'll need to scons prof=on d8 in deps/v8 to build the debugger first, which might have some trouble on a 64-bit machine (v8 is 32-bit only), see here for more info.
Here's how I did it for Node.js 0.10.25 and 0.10.26:
I downloaded the source for Node.js that corresponds to the binaries I'm using. (I'm on Debian testing, which is a bit behind the releases from the Node.js web site.)
I checked the version of v8 bundled in the node sources. (Look at deps/v8/ChangeLog. It was 3.14.5 for Node.js 0.10.25 and 0.10.26.)
I downloaded this exact version of v8 from the v8 site.
Why? I tried running make native in Node.js deps/v8 directory but the Makefile was complaining about a missing test directory. From this we can infer that the Node developers are not including the entire v8 distribution. Once upon a time, with an earlier version of Node (0.8.something) I did build v8 from what was available in deps/v8 but this time I decided to use a different approach.
As explained in v8's build/README.txt, in the top level of the source tree for v8, I did:
$ svn co http://gyp.googlecode.com/svn/trunk build/gyp
(Linking my installed gyp to build/gyp as suggested in OrangeDog's answer did not work. That's why I did the above.)
I ran:
$ CXX=g++-4.7 make native
Why the CXX setting? I ran into a compilation problem right away when I tried with the default gcc. I checked the version. It was 4.8 and I remembered a story on Slashdot about how 4.8 was giving people trouble. So I installed 4.7. Worked fine.
I linked out/native/d8 to a location which is in my PATH. This is because the linux-tick-processor script does a poor job at finding d8. The simplest solution was to make it available in my PATH. Your mileage may vary.
After all this, linux-tick-processor can be used with the v8.log files that Node produces.
Either install the source package - sudo apt-get source nodejs, or switch to the official source as the ubuntu packages are very out of date.
To build d8, go to the deps/v8 directory.
Create a symlink at build/gyp to the directory where gyp can be found (e.g. /usr/bin).
Run make native.
Copy/symlink out/native/d8 to somewhere on your PATH.