Backward binary compatibility

[Andre Majorel]

Hello all.

One of our customers is having trouble running our application
(compiled on OpenBSD 3.4) on his system (running OpenBSD 3.6)
(libc.so.30 not found, IIRC).

I'd like to know what is OpenBSD's policy regarding backward
binary compatibility. Are ISV expected to rebuild every time a
new release of OpenBSD comes out, or does OpenBSD provide a
backward compatibility package ?

[tedu]

Post by Andre Majorel
Hello all.
One of our customers is having trouble running our application
(compiled on OpenBSD 3.4) on his system (running OpenBSD 3.6)
(libc.so.30 not found, IIRC).
I'd like to know what is OpenBSD's policy regarding backward
binary compatibility. Are ISV expected to rebuild every time a
new release of OpenBSD comes out, or does OpenBSD provide a
backward compatibility package ?

Users who have upgraded will retain the old libraries on their systems.
New users can find the appropriate files via ftp (or you could extract
just libc to make it easier for them to download.) All old versions of
syscalls are supported for a long time.

Compatibility is more concerned with programs already running on a
machine being upgraded, and less so with transfering programs from one
old machine to a different new machine.

[Andre Majorel]

Post by tedu

Post by Andre Majorel
Hello all.
One of our customers is having trouble running our application
(compiled on OpenBSD 3.4) on his system (running OpenBSD 3.6)
(libc.so.30 not found, IIRC).
I'd like to know what is OpenBSD's policy regarding backward
binary compatibility. Are ISV expected to rebuild every time a
new release of OpenBSD comes out, or does OpenBSD provide a
backward compatibility package ?

Users who have upgraded will retain the old libraries on their systems.
New users can find the appropriate files via ftp (or you could extract
just libc to make it easier for them to download.) All old versions of
syscalls are supported for a long time.

Thanks. Which package would that be ?
ftp://ftp.openbsd.org/pub/OpenBSD/3.4/i386/base34.tgz, I guess ?

At least one of our customers must have installed from scratch
and is not smart enough to figure it out himself.

Funny thing, during the last product management meeting, they
came close to dropping support for OpenBSD. Someone wanted us to
concentrate on the platforms that actually make us money.
Someone else argued that since OpenBSD users tend to be
competent, they don't cost much to support and OpenBSD was kept.

Given the choice, we'd rather not have to take the
responsability of telling our users the specifics of how to
admin their machines. We'd rather tell them "you're the
sysadmin, it's your gig, just install the compatibility packages
according to whatever procedure the OS vendor defined".

It looks like OpenBSD is going to be a fairly high-maintenance
platform for us. We're going to have to track releases and
install a new porting machine every time the project bumps the
major SO number of the libc. Not insurmountable; after all, we
already do worse than that for, say, Red Hat. But Red Hat
customers outnumber OpenBSD customers by orders of magnitude. It
won't take a bean counter long to decide that OpenBSD costs us
money and must be dropped.

Thanks again.

[tedu]

yes, libc is in base34.tgz, along with many, many other files that a
3.6 user does not want installed. if you don't want to provide the
needed libc (or other libraries, if you use them), linking statically
is another option.