>> No it wouldn't. If you *build* fish against libc.so.6, at compile time >> the linker puts a dependency on libc.so.6 into the fish binary. The >> rpm dependency checker notes this. Now, if you CAN run fish against >> libc.so.5, that's fine, but the version you just built will NOT work >> against it because symbols are different sizes, etc, which is why the >> specific version is recorded in the dependency. In order to >work against >> libc.so.5, you need to build against libc.so.5. (And that >binary won't >> then work on a libc.so.6 system.) > >I was under the (apparently incorrect) impression that LSB protected >me from this when only using libc. The fact that I've used a fish >version compiled on FC5 under FC4 the last few days with no issues >also helped. I guess I was simply lucky. The LSB doesn't help with glibc major-version changes, as the library version (.so.1, .so.6, etc.) is actually present in the compiled binary. And so each LSB version does have specific major-version requirements. Except for the C++ library these have not changed much over time. On the packaging side, the LSB provides a meta-dependency to abstract away the problem that was being asked about originally - it you depend on lsb=3.0 and LSB 3.0 requires X to be present, you don't have to worry about the package or filenames tha provide it. On the downside, not evrey system conforms to the LSB, but it may still be worth a look. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
