Robert Dubner <[email protected]> writes: >> -----Original Message----- >> From: Richard Biener <[email protected]> >> Sent: Monday, October 13, 2025 03:23 >> To: Robert Dubner <[email protected]> >> Cc: [email protected] >> Subject: Re: [committed] cobol: Convert to individual variable >> character-set >> encoding. >> >> On Fri, Oct 10, 2025 at 7:25 PM Robert Dubner <[email protected]> wrote: >> > >> > [Another e-mail message with the 751,609-byte attachment is awaiting >> > moderator approval] >> > >> > From: Robert Dubner mailto:[email protected] >> > Date: Fri, 10 Oct 2025 11:35:44 -0400 >> > Subject: [PATCH] cobol: Convert to individual variable character-set >> > encoding. >> > >> > Prior to this "patch", the GCOBOL compiler was capable of producing >> > binaries >> > that operated internally in either ASCII or EBCDIC. The COBOL >> > specification, >> > however, allows for the concurrent presence of two encodings, known as >> > "alphanumeric" and "national". >> > >> > In order to support this capability, we have chosen to establish an >> > "encoding" >> > characteristic that gets carried along with every variable, >> > >> > This change affected many parts of the COBOL front end compiler. If >> > anybody >> > looks at any of the changes listed below, they will find they fall into >> > two >> > classes: >> > >> > 1) Removing the dependence on a global ASCII vs EBCDIC determination. >> > >> > 2) Adding a dependence on a new ::encoding characteristic of the compile >> > time >> > and run time cbl_field_t and cblc_field_t variable structures. Those >> > structures now contain the cbl_encoding_t ::encoding members, which >> > drive >> > the >> > use of the iconv(3) function in moving back and forth between variable >> > encodings. >> >> Is this effectively an ABI change for libgcobol? That is, when installing >> libgcobol from GCC 16 will programs built with GCC 15 run with it? >> >> Richard. > > This definitely is an ABI change. > > I actually hadn't thought about it, since as far as I know our current user > base is hovering at somewhere between -1 and +1 installations. > > Now that I am thinking about it, the new libgcobol is completely > incompatible with the prior one. We've changed the fundamental run-time > cblc_field_t COBOL variable structure. > > Now that I have started thinking about it, I am not sure where to go from > here.
It's something to try avoid when COBOL is more mature (lol). For now, cranking libgcobol SONAME when these things happen is both necessary and sufficient. > > Bob Dubner sam > [...]
