Kurt Roeckx wrote: > Bob Proulx wrote: > > I installed this symlink: > > /lib/ld-linux-x86-64.so.2 -> /emul/amd64-linux/lib/ld-linux-x86-64.so.2 > > You should create that in /lib64 and not in /lib. That was it! In my case since I am wanting to manage the files in my chroot and access them through the emulation layer I removed the symlink that I added to the system (rm -f /lib/ld-linux-x86-64.so.2) and added these two symlinks. ln -s /emul/amd64-linux/lib /lib64 ln -s /emul/amd64-linux/usr/lib /usr/lib64 With those in place and my previously stated configuration everything is working perfectly. The base system is 32-bit. And additionally 64-bit applications are running fine. The purpose for this is a CAD/EDA desktop environment. Users expect web browser plugins to work and the defacto standard is 32-bits today. This makes everything normal for them in a desktop configuration. They can be naive and things work as they expect. You don't get a huge memory capable /bin/sh or /usr/bin/perl but for a desktop that is fine. But our *HUGE* memory applications are also available to run 64-bit as well. I can manage the libraries for those in the chroot and get all of the benefits of APT for local file management. (We actually access our homebrew binaries over NFS. They are not locally installed.) For our dedicated server configurations this is basically reversed and the system is a 64-bit system with a 32-bit emulation layer for optimized performance. This allows us to run the same locally developed 64-bit binary executable everywhere regardless of it being a server or a desktop. Life is good. Thanks! Bob
Attachment:
signature.asc
Description: Digital signature