On Tue, Apr 2, 2013 at 4:57 AM, Linda Walsh
If your libs don't work without the patches, it means the patches are needed for binary compatibility. You don't want the patches? Tough luck.
It's not the patches that are needed but symbols that are needed -- If I don't use features you have bound in, the code doesn't travel those paths. It's like in gvim when configured correctly, -- if I don't use python, it doesn't load it -- so the binary version doesn't matter.
If the OWL extensions had been put in their own lib and dlloaded at run time, I wouldn't have to worry about patching them or including them.
No, you're completely wrong there. Take it from someone that actually
does some coding for his livelihood, any kind of patch has the
potential to break binary compatibility. You'd have to know how C
works pretty well to be able to decide whether one in particular does
or does not. It's not just about the symbols.
If you want to remove patches, remove them one by one and test
thoroughly afterwards. Especially patches touching C code.
On Tue, Apr 2, 2013 at 4:57 AM, Linda Walsh
and for that you may want to start by applying
openSuse-specific patches.
Like the ones that break normal functionality applied to BASH or break parallel sorting?
All the ones you don't need to remove, keep them. They're quite likely modifying the lib's ABI, so you have to keep them.
In any case, binary compatibility is a delicate beast.
Only when it is built in a fragile manner.
No, it's been pretty much the same ever since K&R. Well, it worsened a bit with C++, but it's gotten easier since then thanks to versioned symbols. What you see is the effect of increased systems complexity making stuff less predictable to mere mortals. A compiler knows best, and there's the value of a distribution and automated build systems.
that's not the way to get binary-compatible replacements for a whole distro installation. You want to start with RPM sources. You want to read the SPEC file, and follow it.
I usually do, but the specs have been a source of problem when they say: req: prod (version=x)
I'm mostly referring to build/install scripts and the patches, not so much about the requirements (though you probably should pay attention to them, just not that specifically).
Not req prod or rec prod (version>=x), but locking them together.
There's probably a reason though. The package's ABI must be especially unstable, and backwards compatibility especially unreliable for the packager to do that. I know I've had to do that for some subpackages because they're tightly coupled with the main package.
As to return to the title of this email -- IT WASN'T ME who broke binary compatibility ---
Yes, it was you. You installed a broken libc, if I read the OP correctly. Broken by you by not building it to openSuse specs. Distros don't promise any kind of binary compatibility, not to upstream and not to other distros, except on LSB components, and, IIRC, there's a separate libc for LSB.
christian said it was suse that did it by design -- intentionally based on the advice of a 2 year old webpage.
OpenSuse broke compatibility with upstream, but that's not breakage of any kind, just a design decision, because libc works just fine within openSuse with openSuse pacakges. So in conext "you broke binary compatibility" means "you built a libc that didn't match opensuse's libc's ABI". It's you the one that has to conform to openSuse's ABI now, when you try to replace an openSuse component, and not the other way around. If that bothers you, really, you need another distro. Not sure there's any distro that will satisfy your wish of upstream-compatible ABIs. I'd wager those would be immature distros, but it's up to you. In any case, you'd be wise to test this not by installing a modified libc on your system, but by mangling LD_LIBRARY_PATH or chrooting or something of the sort. Just saying. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org