info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Release 4.2.1 of gawk now available
200 views
Skip to first unread message
none Arnold Robbins
Mar 13, 2018, 1:06:30 PM3/13/18
to
Greetings all.
This note announces the next release of GNU Awk: version 4.2.1.
The following files may be retrieved from ftp://ftp.gnu.org/gnu/gawk,
or via HTTPS from https://ftp.gnu.org/gnu/gawk:
-rw-rw-r-- 1 arnold arnold 473 Feb 25 21:04 gawk-4.2.1.tar.lz.sig
-rw-rw-r-- 1 arnold arnold 473 Feb 25 21:03 gawk-4.2.1.tar.xz.sig
-rw-rw-r-- 1 arnold arnold 473 Feb 25 21:03 gawk-4.2.1.tar.gz.sig
-rw-rw-r-- 1 arnold arnold 5666610 Feb 25 19:35 gawk-4.2.1.tar.gz
-rw-rw-r-- 1 arnold arnold 2985412 Feb 25 19:35 gawk-4.2.1.tar.xz
-rw-rw-r-- 1 arnold arnold 2889549 Feb 25 19:35 gawk-4.2.1.tar.lz
This is a bugfix release. The relevant part of the NEWS file is
appended below.
Differences from gawk 4.2.0 are available:
-rw-rw-r-- 1 arnold arnold 473 Mar 13 18:09 gawk-4.2.0-4.2.1.diff.gz.sig
-rw-r--r-- 1 arnold arnold 462689 Mar 13 18:07 gawk-4.2.0-4.2.1.diff.gz
The .diff file is a shell script that should be executed in the gawk-4.2.0
source directory.
The usual GNU build incantation should be used:
tar -xpvzf gawk-4.2.1.tar.gz
cd gawk-4.2.1
./configure && make && make check
The documentation on the GNU web site has been updated.
Bug reports should be sent to bug-...@gnu.org.
Enjoy!
Arnold Robbins (on behalf of all the gawk developers)
arn...@skeeve.com
---------------------------------
Changes from 4.2.0 to 4.2.1
---------------------------
1. Support for OS/2 has been brought up to date. This support was
accidentally omitted from the initial 4.2 release, for which
we apologize.
2. The manual received a number of updates to make it format better
for PDF.
3. A new configure option, --enable-versioned-dir, causes the directory
holding extensions to include the API version in its name.
4. extension/configure.ac has been improved considerably.
5. In MPFR mode, When ROUNDMODE changes, string values for numerically
type values will be redone.
6. The various 'inplace' tests now pass on modern BSD systems.
7. A number of bugs, some of them quite significant, have been fixed.
See the ChangeLog for details.
--
Aharon (Arnold) Robbins arnold AT skeeve DOT com
This note announces the next release of GNU Awk: version 4.2.1.
The following files may be retrieved from ftp://ftp.gnu.org/gnu/gawk,
or via HTTPS from https://ftp.gnu.org/gnu/gawk:
-rw-rw-r-- 1 arnold arnold 473 Feb 25 21:04 gawk-4.2.1.tar.lz.sig
-rw-rw-r-- 1 arnold arnold 473 Feb 25 21:03 gawk-4.2.1.tar.xz.sig
-rw-rw-r-- 1 arnold arnold 473 Feb 25 21:03 gawk-4.2.1.tar.gz.sig
-rw-rw-r-- 1 arnold arnold 5666610 Feb 25 19:35 gawk-4.2.1.tar.gz
-rw-rw-r-- 1 arnold arnold 2985412 Feb 25 19:35 gawk-4.2.1.tar.xz
-rw-rw-r-- 1 arnold arnold 2889549 Feb 25 19:35 gawk-4.2.1.tar.lz
This is a bugfix release. The relevant part of the NEWS file is
appended below.
Differences from gawk 4.2.0 are available:
-rw-rw-r-- 1 arnold arnold 473 Mar 13 18:09 gawk-4.2.0-4.2.1.diff.gz.sig
-rw-r--r-- 1 arnold arnold 462689 Mar 13 18:07 gawk-4.2.0-4.2.1.diff.gz
The .diff file is a shell script that should be executed in the gawk-4.2.0
source directory.
The usual GNU build incantation should be used:
tar -xpvzf gawk-4.2.1.tar.gz
cd gawk-4.2.1
./configure && make && make check
The documentation on the GNU web site has been updated.
Bug reports should be sent to bug-...@gnu.org.
Enjoy!
Arnold Robbins (on behalf of all the gawk developers)
arn...@skeeve.com
---------------------------------
Changes from 4.2.0 to 4.2.1
---------------------------
1. Support for OS/2 has been brought up to date. This support was
accidentally omitted from the initial 4.2 release, for which
we apologize.
2. The manual received a number of updates to make it format better
for PDF.
3. A new configure option, --enable-versioned-dir, causes the directory
holding extensions to include the API version in its name.
4. extension/configure.ac has been improved considerably.
5. In MPFR mode, When ROUNDMODE changes, string values for numerically
type values will be redone.
6. The various 'inplace' tests now pass on modern BSD systems.
7. A number of bugs, some of them quite significant, have been fixed.
See the ChangeLog for details.
--
Aharon (Arnold) Robbins arnold AT skeeve DOT com
Kenny McCormack
Mar 16, 2018, 4:59:08 AM3/16/18
to
In article <p890ed$s5h$1...@dont-email.me>,
(reported) need to re-compile all my extension libs. Can you give me a
summary or pointer-to-the-documentation that explains, in simple terms, how
much work is needed to get them recompiled?
My understanding is that:
1) In most cases, a straight recompile will work, without making any
source code changes, although there will be warnings generated by
the compiler.
2) To get a clean compile, source code changes will be needed.
Can you explain what those changes are?
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Mandela
none) (Arnold Robbins <arnold@tanda.> wrote:
>Greetings all.
>
>This note announces the next release of GNU Awk: version 4.2.1.
>
>The following files may be retrieved from ftp://ftp.gnu.org/gnu/gawk,
>or via HTTPS from https://ftp.gnu.org/gnu/gawk:
The thing that has been holding me up on trying out the new version is the
>Greetings all.
>
>This note announces the next release of GNU Awk: version 4.2.1.
>
>The following files may be retrieved from ftp://ftp.gnu.org/gnu/gawk,
>or via HTTPS from https://ftp.gnu.org/gnu/gawk:
(reported) need to re-compile all my extension libs. Can you give me a
summary or pointer-to-the-documentation that explains, in simple terms, how
much work is needed to get them recompiled?
My understanding is that:
1) In most cases, a straight recompile will work, without making any
source code changes, although there will be warnings generated by
the compiler.
2) To get a clean compile, source code changes will be needed.
Can you explain what those changes are?
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Mandela
Andrew Schorr
Mar 17, 2018, 6:24:38 AM3/17/18
to
On Friday, March 16, 2018 at 4:59:08 AM UTC-4, Kenny McCormack wrote:
> My understanding is that:
> 1) In most cases, a straight recompile will work, without making any
> source code changes, although there will be warnings generated by
> the compiler.
> 2) To get a clean compile, source code changes will be needed.
> Can you explain what those changes are?
It's not much work at all. Here's a summary of the changes:
> My understanding is that:
> 1) In most cases, a straight recompile will work, without making any
> source code changes, although there will be warnings generated by
> the compiler.
> 2) To get a clean compile, source code changes will be needed.
> Can you explain what those changes are?
https://www.gnu.org/software/gawk/manual/html_node/Changes-from-API-V1.html
For some guidance, you can examine the changes to the bundled extensions between releases 4.1.4 and 4.2.1. Or look at the changes in the gawkextlib extensions.
Regards,
Andy
Kenny McCormack
Mar 17, 2018, 9:28:22 AM3/17/18
to
In article <464475eb-9ee6-407b...@googlegroups.com>,
OK, thanks. I'm reading it as we speak.
From what I can tell, it boils down to two things:
1) The recompile is needed because the size/layout of the main struct
has changed.
2) The main difference in terms of user-code is that the implementation
function is now passed 3 args, not just 2, so user-code written to
take only two will generate a warning (because the C compiler
expects it to take 3). I think that technically this is UB as far
as the C standard is concerned, but will work as expected on most
(all?) compilers.
So, bottom line, is there anything else I will need to do to get a clean
(no warnings) compile, other than adding a third arg to the declaration of
every implementation function?
Note: I suppose I'll also have to do the usual:
(void) that_third_arg;
to avoid an "unused arg" warning.
P.S. I like the fact that you can now write a single function and have it
figure out by which name it was invoked. Kinda like the "Checking argv[0]
to see which name a program was invoked as" trick.
--
Pensacola - the thinking man's drink.
From what I can tell, it boils down to two things:
1) The recompile is needed because the size/layout of the main struct
has changed.
2) The main difference in terms of user-code is that the implementation
function is now passed 3 args, not just 2, so user-code written to
take only two will generate a warning (because the C compiler
expects it to take 3). I think that technically this is UB as far
as the C standard is concerned, but will work as expected on most
(all?) compilers.
So, bottom line, is there anything else I will need to do to get a clean
(no warnings) compile, other than adding a third arg to the declaration of
every implementation function?
Note: I suppose I'll also have to do the usual:
(void) that_third_arg;
to avoid an "unused arg" warning.
P.S. I like the fact that you can now write a single function and have it
figure out by which name it was invoked. Kinda like the "Checking argv[0]
to see which name a program was invoked as" trick.
--
Pensacola - the thinking man's drink.
Kaz Kylheku
Mar 17, 2018, 2:25:36 PM3/17/18
to
On 2018-03-17, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <464475eb-9ee6-407b...@googlegroups.com>,
> Andrew Schorr <asc...@telemetry-investments.com> wrote:
>>On Friday, March 16, 2018 at 4:59:08 AM UTC-4, Kenny McCormack wrote:
>>> My understanding is that:
>>> 1) In most cases, a straight recompile will work, without making any
>>> source code changes, although there will be warnings generated by
>>> the compiler.
>>> 2) To get a clean compile, source code changes will be needed.
>>> Can you explain what those changes are?
>>
>>It's not much work at all. Here's a summary of the changes:
>>
>>https://www.gnu.org/software/gawk/manual/html_node/Changes-from-API-V1.html
>>
>>For some guidance, you can examine the changes to the bundled extensions
>>between releases 4.1.4 and 4.2.1. Or look at the changes in the gawkextlib
>>extensions.
>
> OK, thanks. I'm reading it as we speak.
>
> From what I can tell, it boils down to two things:
>
> 1) The recompile is needed because the size/layout of the main struct
> has changed.
glibc can change the size of pthread_mutex_t or whatever and old binary
> In article <464475eb-9ee6-407b...@googlegroups.com>,
> Andrew Schorr <asc...@telemetry-investments.com> wrote:
>>On Friday, March 16, 2018 at 4:59:08 AM UTC-4, Kenny McCormack wrote:
>>> My understanding is that:
>>> 1) In most cases, a straight recompile will work, without making any
>>> source code changes, although there will be warnings generated by
>>> the compiler.
>>> 2) To get a clean compile, source code changes will be needed.
>>> Can you explain what those changes are?
>>
>>It's not much work at all. Here's a summary of the changes:
>>
>>https://www.gnu.org/software/gawk/manual/html_node/Changes-from-API-V1.html
>>
>>For some guidance, you can examine the changes to the bundled extensions
>>between releases 4.1.4 and 4.2.1. Or look at the changes in the gawkextlib
>>extensions.
>
> OK, thanks. I'm reading it as we speak.
>
> From what I can tell, it boils down to two things:
>
> 1) The recompile is needed because the size/layout of the main struct
> has changed.
clients continue to work. Though that relies on the complex and platform
specific mechanism of symbol versioning at the shared lib level,
the simple Microsoft solution works here:
1. Put a "size_t size" field in the structure which the client
fills in.
2. Add any new members strictly at the end of the structure.
2. If the filled size is smaller than the current sizeof(struture),
it means it's old binary client and we must not access the
struct members beyond the indicated size: they are not there.
We can also emulate any old behaviors that changed.
> 2) The main difference in terms of user-code is that the implementation
> function is now passed 3 args, not just 2, so user-code written to
> take only two will generate a warning (because the C compiler
> expects it to take 3). I think that technically this is UB as far
> as the C standard is concerned, but will work as expected on most
> (all?) compilers.
old one for old clients. The old one can just call the new one,
supplying default values to the new arguments.
Andrew Schorr
Mar 18, 2018, 6:07:02 AM3/18/18
to
On Saturday, March 17, 2018 at 9:28:22 AM UTC-4, Kenny McCormack wrote:
> So, bottom line, is there anything else I will need to do to get a clean
> (no warnings) compile, other than adding a third arg to the declaration of
> every implementation function?
I urge you simply to attempt compiling your extensions with the new gawkapi.h. You will see compiler warnings, and then you can fix them. After cleaning up compiler warnings, you can decide whether you want to take advantage of any of the new features. It's best to dive in rather than engaging in an extensive theoretical analysis of the situation. And as I mentioned, there are plenty of examples of how to modify your code in the gawk and gawkextlib extensions.
> So, bottom line, is there anything else I will need to do to get a clean
> (no warnings) compile, other than adding a third arg to the declaration of
> every implementation function?
Regards,
Andy
Kaz Kylheku
Mar 18, 2018, 1:20:55 PM3/18/18
to
On 2018-03-18, Andrew Schorr <asc...@telemetry-investments.com> wrote:
> I urge you simply to attempt compiling your extensions with the new
> gawkapi.h.
Will the compiled results work with an installation of the older Gawk
> I urge you simply to attempt compiling your extensions with the new
> gawkapi.h.
and its API?
> It's best to dive in
> rather than engaging in an extensive theoretical analysis of the
> situation.
Andrew Schorr
Mar 19, 2018, 5:44:42 AM3/19/18
to
On Sunday, March 18, 2018 at 1:20:55 PM UTC-4, Kaz Kylheku wrote:
> Will the compiled results work with an installation of the older Gawk
> and its API?
No. There has been a major version change in the API.
> Will the compiled results work with an installation of the older Gawk
> and its API?
>
> > It's best to dive in
> > rather than engaging in an extensive theoretical analysis of the
> > situation.
>
> The usual words for that are "after you".
Good luck,
Andy
0 new messages