Greetings all, I have a quick question. I'm building an rpm (ssh 4.2p1) for some RH-AS machines and it's been working just fine. However, I needed to install it on an older box (AS 2.1), and received the following error: starting /usr/sbin/sshd... /usr/sbin/sshd: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by /usr/sbin/sshd) /etc/init.d/wfssh: Error 1 starting /usr/sbin/sshd... bailing. My only question is that is openssh dependant on libc >= 2.3, or is this due to the version of libc on my build machine? I couldn't find any documentation on dependencies, so if that exists, if someone could point me that way as well, I would most appreciate it. Thanks! Jason
> I have a quick question. I'm building an rpm (ssh 4.2p1) for > some RH-AS > machines and it's been working just fine. However, I needed > to install > it on an older box (AS 2.1), and received the following error:[[deleted]]> My only question is that is openssh dependant on libc >= 2.3, > or is this due to the version of libc on my build machine?This is due to the version of libc on your build machine. If you need to support an older box you're going to either need to build on that box (or one with a compatible set of libraries) or else find a way to specify linkage with the older set of libraries. The usual solution is the former--I still have functional Solaris 2.5.1 boxes here just in case, to use as build hosts. Hope this helps-- --Rip
>> The only thing to watch for there is for kernel-related things since >> you're obviously running on the same kernel in the chroot.>Certainly. And a good thing to note.>> This was the case with the descriptor passing bugs in Linux 2.0kernels:>> the Debian folk used chroots as you described. configure found that >> descriptor passing worked fine (which it did, on the host's kernel) >> even though it didn't on the target. They eventually added some code>> to detect the buggy kernel versions at runtime.>Yes that can be a problem. But that is almost the same problem as whenyou compile something for the local machine and then boot to a different>kernel on the same machine. Things that depend upon the kernel mightwork differently. So what you say the Debian folks did, which was to detect>the situation at runtime, sounds like a best case solution for thingsthat depend upon the kernel.>I say almost the same problem because obviously most people don't losefeatures when installing new kernels. But it does happen at times.>I often boot into older kernels in order to test something or to try torecreate some particular configuration. Fortunately there are few>things that are sensitive to the kernel version.All very good ideas, but in the essence of compatibility, I think I'll just create a VM of the OS/kernel that's having the problems and just add it to the build script. Thanks for all the info, you guys have been immensely helpful. Jason