Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Mar 2023 08:36:34 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Jessica Clarke <jrtc27@freebsd.org>
Cc:        Charlie Li <vishwin@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@freebsd.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@freebsd.org>
Subject:   Re: git: c5c9d980c4b0 - main - libc/csu: rename ignore_init.c to libc_start1.c
Message-ID:  <ZBVb8kYDMt57blPQ@kib.kiev.ua>
In-Reply-To: <137554A7-8067-4E77-96A8-A0B4BF813184@freebsd.org>
References:  <202303112320.32BNKoJe039514@gitrepo.freebsd.org> <8d3503f3-fd05-5f1c-7470-48cef3c9bd2d@freebsd.org> <137554A7-8067-4E77-96A8-A0B4BF813184@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 18, 2023 at 03:46:36AM +0000, Jessica Clarke wrote:
> On 18 Mar 2023, at 03:44, Charlie Li <vishwin@freebsd.org> wrote:
> > 
> > Konstantin Belousov wrote:
> >>     libc/csu: rename ignore_init.c to libc_start1.c
> >>          The current name was a historical curiosity that started when init array
> >>     support was added, and then the file appeared a convenient place for the
> >>     addition of the MI common code to csu.  It is now referenced by name in
> >>     single place and the rename is easy, so do it.
> >>          Sponsored by:   The FreeBSD Foundation
> >>     MFC after:      3 weeks
> >> ---
> >>  lib/libc/csu/Makefile.inc                     | 2 +-
> >>  lib/libc/csu/{ignore_init.c => libc_start1.c} | 0
> >>  2 files changed, 1 insertion(+), 1 deletion(-)
> > Seems like an ABI break. Anything compiled after this but ran on an earlier-by-revision-but-same __FreeBSD_version complains with 'Undefined symbol "__libc_start1@FBSD_1.7"'
> 
> It’s not a break, just new ABI. Same as adding a new function, just
> everything automatically uses it.
Well it is break of ABI indeed, but it is backward-compatible.  We never
guaranteed forward-compatibility, and hopefully never will.  Doing so would
mean that FreeBSD is frozen.

> 
> It’s true that __FreeBSD_version needs bumping if it hasn’t already
> been though.
> 

I bumped the version to please the public, but I do not see much use for
this bump, same as for many other instances of the bump.  The new interface
presence is declared by the export of specifically-versioned symbol in
libc, and really this export, instead of some random osversion reported
from unrelated software artifact (kernel) is what important.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZBVb8kYDMt57blPQ>