I have a computer which is not to be connected to the internet for security reasons. It is running Linux. On a separate computer, I have code and a cross compiler for linux. When I move the program over to the offline Linux computer, I cannot execute it, due to an error " version `GLIBC_2.17' not found "
After checking /lib, I see that I do indeed only have version 2.13 of libc. On my development computer, I have all the relevant files for the 2.22 version which is being used to compile the program. I would like to somehow copy this version of libc on my development computer over to my offline computer so that I can run my program.
The problem is, I cannot seem to copy the files. Attempting to do so gives an error:
mv: error writing ‘./libc.so.6’: No space left on device
or something similar. I know this is not actually due to there not being space left on the device, because I don't have much of anything ON the device, and I can copy the files to other places in the filesystem, just not to the /lib directory. How can I migrate my newer version of libc over to the offline computer?
I would like to somehow copy this version of libc on my development computer over to my offline computer so that I can run my program.
Incorrectly updating libc on your "offline" computer is a very easy way to render it unbootable. You should not attempt this unless you understand what you are doing (which you clearly do not), and unless you know how to restore "offline" computer in case of failure.
The best approach is to use the package manager on the "offline" computer to install libc package correctly (details vary on what package manager is being used).
If the package manager approach doesn't work, you can copy individual files. Hoever note that system ld-linux.so and libc.so.6 must match at all times, or every dynamically linked program (your shell, cp, mv etc.) will break.
Since you need to update two files simultaneously, how could this be done? You need a statically-linked copy of cp. It is best to have a statically-linked copy of $SHELL and ln as well (in case you make a mistake).
Related
Why would spring-tool-suite-4-4.10.0.RELEASE-e4.19.0-win32.win32.x86_64.self-extracting.jar be harmful for my computer? I have downloaded from here.
This type of file may harm your computer
message appeared.
Please advise me know the correct Link for my Laptop RV509 having installed with Windows10 Pro with 20H2.
The file is not harmful to your computer. This is a generic warning from your computer/OS that you get because the jar is an executable. Anytime you download an executable file onto your computer and execute it you are potentially opening the door for that executable to do 'something bad' (e.g. install a malware).
This warning is so you should be aware of the potential risk before downloading and executing random things from the internet.
The question is really whether you trust the file you downloaded or not. That question is for you to answer.
Note that this risk is somewhat unavoidable. Since you intend to install and run STS on your machine, there is no avoiding running something you downloaded onto your machine.
Simply put, if you do not trust STS to not be a malware, then you shouldn't run it.
So, provided that
you downloaded the installer from its official website so it is not a 'spoofed' copy, and...
STS is a product that you trust not to be malware...
... then you can dismiss the warning, elect to keep the file, and run it to install STS onto your computer.
I've cloned it but I didn't find any .exe file, Nor do i see it in programs list in Control Panel of windows. I'am a bit confused as to what cloning means. I know that there is direct download .exe file on vim.org website. Its for sure that I'am beginner for all these. Please help. Thanks for the help in advance.
reading the "installation" section found in the README.md of the vim repo, you can see the filenames containing the instructions that will help you with the installation, depending on your OS.
README_ami.txt Amiga
README_unix.txt Unix
README_dos.txt MS-DOS and MS-Windows
README_mac.txt Macintosh
README_haiku.txt Haiku
README_vms.txt VMS
So, for the full information I suggest you go to those files, or go to the vim website where there is also good information about the installation.
Anyway, I will briefly explain below the information that those files and the vim website say for most common operating systems
If you're on Unix:
git clone https://github.com/vim/vim.git
cd vim/src
make
If you're on Mac
The Macintosh binaries are not on the Vim ftp site. They are produced by a few Macintosh lovers. Often they lag behind a few versions.
MacVim has more a Mac look and feel, is developed actively and most people prefer this version. Most of MacVim was made by Björn Winckler.
MacVim can be downloaded here: link
Or if you prefer, here is the MacVim homepage.
If you're on Windows:
The next instructions were copied from here.
Option A: Using the self-installing .exe
Go to vim.org/download.php and click on self-installing executable (or just click here) and follow the prompts.
Watch out for:
When an existing installation is detected, you are offered to first remove
this. The uninstall program is then started while the install program waits
for it to complete. Sometimes the windows overlap each other, which can be
confusing. Be sure the complete the uninstalling before continuing the
installation. Watch the taskbar for uninstall windows.
When selecting a directory to install Vim, use the same place where other
versions are located. This makes it easier to find your _vimrc file. For
example "C:\Program Files\vim" or "D:\vim". A name ending in "vim" is
preferred.
After selecting the directory where to install Vim, clicking on "Next" will
start the installation.
Option B: Using .zip files
Go to the directory where you want to put the Vim files. Examples:
cd C:\
cd D:\editors
If you already have a "vim" directory, go to the directory in which it is
located. Check the $VIM setting to see where it points to:
set VIM
For example, if you have
C:\vim\vim82
do
cd C:\
Binary and runtime Vim archives are normally unpacked in the same location,
on top of each other.
Unpack the zip archives. This will create a new directory "vim\vim82",
in which all the distributed Vim files are placed. Since the directory
name includes the version number, it is unlikely that you overwrite
existing files.
Examples:
pkunzip -d gvim82.zip
unzip vim82w32.zip
You need to unpack the runtime archive and at least one of the binary
archives. When using more than one binary version, be careful not to
overwrite one version with the other, the names of the executables
"vim.exe" and "gvim.exe" are the same.
After you unpacked the files, you can still move the whole directory tree
to another location. That is where they will stay, the install program
won't move or copy the runtime files.
Change to the new directory:
cd vim\vim82
Run the "install.exe" program. It will ask you a number of questions about
how you would like to have your Vim setup. Among these are:
You can tell it to write a "_vimrc" file with your preferences in the
parent directory.
It can also install an "Edit with Vim" entry in the Windows Explorer
popup menu.
You can have it create batch files, so that you can run Vim from the
console or in a shell. You can select one of the directories in your
$PATH. If you skip this, you can add Vim to the search path manually:
The simplest is to add a line to your autoexec.bat. Examples:
set path=%path%;C:\vim\vim82
set path=%path%;D:\editors\vim\vim82
Create entries for Vim on the desktop and in the Start menu.
That's it!
Vim is open source software, and its source code, i.e. all the technical files that make up Vim is (nowadays) hosted at GitHub.
Cloning that repository means you'll download all of those files to your computer (and with Git as the underlying revision control system, you'll even get the full history of all changes ever done). As Vim supports a very big set of very diverse platforms (Windows, Linux, Mac, ...), the repository itself does not (and should not) contain pre-built binaries, nor a full installer that most users expect to run. So, unless you have the intention to actively contribute to Vim by submitting bug fixes or enhancements, you don't need to clone or do anything with GitHub. If you do want to get technical, src/INSTALLpc.txt contains the instructions for building Vim on Windows. This includes choosing a compiler, installing it and the required dependencies, configuring the build, building, and then finally copying the files to a permanent location on your PC, either manually or by building and then running an installer.
For plain passive consumption of Vim (which is rewarding in itself, but may even lead you to eventually also programming it), the Downloading Vim page on vim.org has all the information that you need, with links to the most popular installers right at the top.
a word on versions
For a casual user, using the latest stable version is recommended; this is 8.2 right now; gvim82.exe is a corresponding installer for Windows. This offers the best compromise between stability and latest features. In the case of Vim, expect a new release roughly every year.
You'll also find development builds (something like 8.2.0740); these usually function as well and have the very latest features under development, but often are less stable. I would use these only if you really need a leading-edge feature, or want to report a bug. You should then probably update very frequently, and from there it's only a small step to actually cloning the repository and building everything on your own!
I want to develop a new feature or change and existing program of the FreeBSD distribution, specifically the user space¹. To do so, I need to make changes to the FreeBSD code base and then compile and test them.²
Doing so on the tree in /usr/src and installing the result on the system seems like a bad idea, given that it requires you to run your development machine on CURRENT, to develop with root privileges and hoses your system if you make a mistake. I suppose there must be a better way and possibly a standard setup FreeBSD developers use.³
What is the recommended workflow to develop the FreeBSD code base?
¹ so considerations specific to kernel development aren't terribly important
² I'm familiar with the process to submit changes after I have developed them
³ I have previously read both the development handbook and the FreeBSD handbook chapter on building the source but neither seem to recommend a specific process.
I am a src committer.
I often start with the lowest release that I intend to back port to (e.g., RELENG_11_3.
I would then do (before or after making changes):
make buildworld
then deploy to a jail directory:
make DESTDIR=/usr/jails/test installworld
This jail directory, as the first responder hinted, can be used with bhyve, but I find it easier to configure a jail or even just use chroot.
I like to configure my jails in /etc/rc.conf instead of /etc/jail.conf:
Example /etc/rc.conf contents:
jail_enable="YES"
jail_list="test"
jail_test_rootdir="/usr/jails/test"
jail_test_hostname="test"
jail_test_devfs_enable="YES"
I can provide more in-depth examples, ones where the jail has a private networking stack so you can SSH into it, for example, but I don't get the sense that a networking stack is important to your testing from the posted question.
You can see the running jail with "jls" and you can enter the running jail with "jexec test bash"
Inside the jail you can test your changes.
When doing this kind of sandboxing, jails work so long as the /usr/src that you built/installed to the jail is from a release that is:
Older than the guest OS, or
In the same STABLE branch as the guest OS, or
At the very least binary-compatible with the guest OS
Situations 1 and 2 are pretty safe, while situation 3 (e.g., running a newer /usr/src than the guest OS) can get dodgy. For example, trying to run /usr/src head (13.0-CURRENT) on a 12.0-RELEASE-pX guest OS where the KBI, KPI, and API can all differ between kernel and userland (with jails, each jail runs under the guest OS's kernel).
If you find that you have to run the newest sources against an older guest OS, then bhyve is definitely the solution. You would take that jail directory and instead of running a jail with that root directory, run a bhyve instance with the jail directory as its root. I don't use bhyve that often, so I can't recall if you first have to deposit the contents inside a disk image and point bhyve at the disk image first -- others and/or Google would know the answer to that.
I'm a ports committer, not a src one, but AFAIK running CURRENT is a common practice amongst developers.
Another way to work is to setup a CURRENT VM, share it over NFS, mount from the host and install into by running make install DESTDIR=/mnt/current. You can use BHyVe for virtualizing, by the way.
I have installed a perl module, say XYZ then a folder is created that contains many .pm files. I copied the folder and put it in any other system where XYZ is not installed. So, I'm able to use methods of XYZ module in both system. I mean, I'm unable to find out the difference between these method, but I think there must be some. What I know is, when we install a perl module then dependencies also gets installed. Am I right? Can anyone mention other difference between two, if any?
A few off the top of my head:
In case of an XS module, the code is compiled for the local platform.
Installing a module via cpan usually runs the test suite so if there is any other reason beyond dependencies why it wouldn't work, you're told so (I guess that's very rare though)
Regular installation automatically goes to a directory where your perl can find modules.
Of course you can take care of all these yourself. These days chances are pretty good you're running either Linux or Windows on something x86-ish and as long as you only copy Linux to Linux and Windows to Windows, and to the same place as on the source system, you'll be fine. Basically that's what binary Linux distributions and ActivePerl packages do, too, and it may make sense e.g. if you want to avoid installing a whole bunch of compile-time dependencies on all target systems. Just make sure you don't get yourself into a mess by writing to system directories (e.g. /usr/share/perl5) that are supposed to be managed by your system's package manager.
When you install your product locally, all the needed files are stored in the machine.
When you set the features to Advertise, files will be installed locally when the user launches the application.
What happens then when yo set the features to "run-from-source"? I Googled it and was only able to find this: http://msdn.microsoft.com/en-us/library/aa367538%28v=vs.85%29.aspx
Thanks!
This is a rarely used feature of Windows Installer and I don't normally reccomend using it. It was invented back in a day when hard drives were small and the thought was you 'advertised' ( pretend install aka install source ) a feature and that when the user clicks the shortcut it would go to the source and finish the installation of the feature ( aka install local )
It just adds a lot of complexity to your servicing model. It's not worth it IMO.
When placing all installation files next to the MSI (similar to advertised installation), you can install features from source. This means that all files in these features will be used from the MSI location (they are not copied in the target folders during install).
Running from source can be used when the installer remains permanently on the target machine. So the application can use the installer directly instead of using installed files.