On Jul 11, 2006, at 5:54 PM, Chris Kuethe wrote:
Roughly speaking, a libc minor version bump means that new functions
have been added. A major version bump means functions have been
removed or some behaviour has been significantly changed. Sometime
syscalls are moved, removed, or recycled. That you can get away with a
symlink is just luck - if you have a major version bump, you'd better
recompile.
This is what we suspected. Sorry to raise such dust over the symlink
comment - we don't recommend the symlink option in general, it's just a
test situation.
In short, I guess it is known that applications built against obsd35
libc won't work with obsd39 libc - that's why the version number
changed. Maybe you can include a copy of obsd35 libc with your
product?
Actually, that is most likely the best solution (and one I'd not
considered). We'll update the build on our end and add a copy of the
libc from 3.5.
Thanks,
Tim
--
Tim Jones [EMAIL PROTECTED]
On 7/11/06, Tim Jones <[EMAIL PROTECTED]> wrote:
We've been providing BRU and BRU Server agents for OpenBSD since
OpenBSD 2.8.
For the most part, OpenBSD updates have not broken compatibility with
our baseline builds for 2.8 and 3.5 - until 3.9. We have a customer
that has installed 3.9 on a group of servers and we now witness libc
compatibility issues that can't be resolved with a simply symlink.
Is it known that applications built against the 3.5 libc are not
compatible with 3.9 (they have been proven to work fine with 3.8)? Is
there something that the user can do to enable backwards
compatibility,
or is the only solution to compile special versions of the BRU tools
for 3.9?
Tim
--
Tim Jones [EMAIL PROTECTED]
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
