I previously bought a used Asus RT-AC1900P wireless router with Merlin installed to use as a home gateway. The previous owner used a 2.6.36.4brcmarm kernel. Since it is more than 10 years old, I don’t need to think about the WireGuard module, but I can still compile tunneling modules such as IPIP/GRE, I will write about the compilation process later. Broadcom only has a 32-bit toolchain, and my server is 64-bit Ubuntu, so I can’t run it directly. Today I’m going to share how to install and clean up a 32-bit runtime environment on a 64-bit Linux system.
Running 32-bit programs in a pure 64-bit Linux environment may encounter errors.
The executable is there, but bash says it doesn’t exist. Checking the file information confirms that it is a 32-bit application:
So why is it “possible” to get an error? You can try it out. If it’s a 32-bit programme compiled in Go, it’s likely to work fine. The difference is that Go programs are statically linked by default, and do not rely on dynamic link libraries installed on the system. And 64-bit CPUs inherently support running 32-bit instructions, so most Go programs will run directly.
View Go program information.
Here statically linked means statically linked. Static links do not depend on so files on the system.
So the so-called 32-bit runtime environment is a set of related dynamic link libraries that ensure that 32-bit applications load the corresponding so-files when they run. All we need to do is to install the libraries.
First turn on the 32-bit architecture, which is the i386 architecture.
|
|
Then install the i386 architecture core dynamic libraries.
|
|
The only thing left to do is to install the libraries that depend on the specific application. There are two types of libraries, those with the word 32 in their name, such as lib32stdc++6, and those with the architecture specified in the library name, such as libelf1:i386.
Then it works fine. But my VPS hard drive is too small, only 20G, not enough, so I had to switch to a friend’s machine. But I’m also an obsessive-compulsive person, I have to clean up the packages I don’t use.
If we remove the i386 architecture directly, the system will indicate an error.
Obviously, this is because 32-bit packages are already installed on the system. We can find them by using dpkg with grep.
|
|
Of course, you can also use dpkg’s built-in command dpkg -l "*:i386", but I think it’s more flexible and versatile to use it with grep.
Then you can use awk {print $2} to extract the package name, which is the second column, and finally use xargs with aptitude to batch remove it.
|
|
The -y option at the end here is to tell aptitude to just delete it and not ask the user for confirmation. However, given the thrilling experience I had last time, I took a more conservative approach. I started by making the package to be deleted a single line and splitting it with a space.
|
|
The xargs echo at the end does the trick. Then run aptitude manually and see what happens.
|
|
The system will find other packages that have dependencies and delete them together, this step requires user confirmation. I looked at the packages to be deleted and felt that there was no problem, so I pressed Y to continue. I didn’t expect the system to display a new prompt.
It said that libcrypt1:i386 was a core package and that removing it might break the system. I panicked a bit. Don’t mess up the system like last time. But to be reasonable, libcrypt1:i386 should only be used by 32-bit programmes, and the system won’t use it, and programmes like SSH are also 64-bit, and shouldn’t depend on it. It might be worth checking which version SSH depends on.
|
|
The path /lib/x86_64-linux-gnu shows that the dependency is on the 64-bit version. We use dpkg -L libcrypt1:i386 to view the package files.
The path is /lib/i386-linux-gnu, so it doesn’t affect 64-bit programs like SSH and can be removed!
To remove it, you have to use the --force-remove-protected parameter of dpkg.
|
|
After deletion you can clean up the i386 architecture.
|
|
Finally rebooted the system. Still able to log in normally, hooray. Above is the whole content of this article.