From owner-freebsd-hackers Sun Jul 6 04:32:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA19537 for hackers-outgoing; Sun, 6 Jul 1997 04:32:27 -0700 (PDT) Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA19529 for ; Sun, 6 Jul 1997 04:32:22 -0700 (PDT) Received: from erlang (erlang.ericsson.se [147.214.36.16]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with SMTP id NAA25711; Sun, 6 Jul 1997 13:32:11 +0200 (MET DST) Received: from townsend.ericsson.se by erlang (SMI-8.6/LME-2.2.4) id NAA03956; Sun, 6 Jul 1997 13:32:10 +0200 Received: from townsend by townsend.ericsson.se (SMI-8.6/client-1.5) id NAA29134; Sun, 6 Jul 1997 13:32:38 +0200 Message-Id: <199707061132.NAA29134@townsend.ericsson.se> To: tom@sdf.com Cc: freebsd-hackers@FreeBSD.ORG Cc: kent@erlang.ericsson.se Subject: Re: Application os version compatibility? Reply-To: kent@erlang.ericsson.se In-Reply-To: Your message of "Sat, 5 Jul 1997 20:17:24 -0700 (PDT)" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 X-URL: http://www.ericsson.se/erlang Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 06 Jul 1997 13:32:37 +0200 From: Kent Boortz Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Thank you Tom, it is more clear to me know but I'm still a bit confused. > The libc version is ONLY changed if the interface changes. If the > interface changes, some applications will not work. Hence, the version > number change. Do you talk about "system calls" like read/write? Or the interface from the library to the user, like fread/fwrite? > Huh? Statically linked applications ALWAYS work. Could it be the case that a new system call is added from FreeBSD X.X.1 to X.X.2 and for example a new libc.a implement fopen() with this new call? Then running even statically linked applications compiled in X.X.2 running on X.X.1 will break, right? Do the behaviour of system calls *ever* change change in an incompatible way? > Statically link it, and it will work on any version, or > dynamically link it to the oldest good release (probably 2.1.7), and 2.2 > users can install the 2.1 compat package (basically just a copy of > libc.2.2). This will solve the problem I describe above, good idea, thanks. (even though I hate to install an old 2.1.7 on my system just to be able to compile ;-) > It is foolish to make binary-only releases to support an unreleases > os version. There will be other libraries than 'libc' in this application. What I'm after is that if I compile and release a 2.2.2 version and an unreleased 2.2.3 shows up that "there is a good chance" it will work. No guarantee of cause, I may have to do a new release or give instruction how to use a compatibility package or something. The sad thing is that when the user starts the application and he get lots of warnings or it refuses to run he will blame me ;-) or think the product is crap. It doesn't help if the release note says 2.2.2, he runs 2.2.3 and expect it to work I want a FreeBSD version of our free non-commercial version of the product we develop (Erlang, a development system for concurrent and distributed applications) and want FreeBSD look like a "good option" to Solaris that is mostly used by our customers. Thats why I try to understand how I make binary distributions the best way and how and how well new releases are handled in this respect by the FreeBSD group. > It really is quite simple. For you maybe ;-) Thank you for your reply, /kgb