New Release 2.2.0 release ?

[hzeller]

Given that the last commit hinted that 2.2.0 is around the corner, but has been sitting there for a few months, I would like to request to create a new release.

Reason is that I'd like to use the avrxmega3 (attiny1604, attiny804,...) class of devices that have been added after the last release.

If this gets a proper 2.2.0 label and release, it is much easier to convince distributions to pick up and package this version.

Thank you!

(Currently some distributions are stuck in even older versions, but that is a different story)

[dl8dtl]

Basically, not a bad idea, but I'd need some time to at least walk through some of the bugs, and fix the most serious ones.

Going through the pull requests is probably the simpler part here.

[leonty]

Please, include in 2.2.0 the patch mentioned in #563 (pgmspace utils generic usage for tiny core MCUs). Moreover this patch has already been incorporated by Microchip in their version of avr-libc https://onlinedocs.microchip.com/pr/GUID-317042D4-BCCE-4065-BB05-AC4312DBC2C4-en-US-2/index.html?GUID-B4AD7063-9288-4E83-A857-F4FBD028A8BB

[hzeller]

@dl8dtl it seems like you're pretty busy, are there things we can help to get a release out the door ?

[kamocat]

Is there a list of issues which need to be closed before the 2.2 release?
I am happy to help.

[leventelist]

I'd be happy to test an RC version of 2.2.0... if that helps.

[leventelist]

I created a fork, and applied some of the PRs above. https://github.com/leventelist/avr-libc

[anatol]

Hi, the Arch package maintainer here. Some of our users keep asking us to bring the latest avr-libc changes and make a new Arch package. But our policy is to stick to the official releases only. Thus we rely on you to provide a new 2.2.0 release.

Any ETA for 2.2.0 release date?

[dl8dtl]

The question would go to Johann, how comfortable he'd feel to roll out the status quo as v2.2.0.

Actually preparing the release is not that much work, I'll be able to find the time for that.

[dl8dtl]

Here is the result of a make distcheck from last night.
If you have troubles unpacking the file, it is actually a .tar.bz2 file, but Github doesn't allow me to upload it with that extension.
avr-libc-220git.zip

[sprintersb]

There's 2 problems:

1. How to deal with problems in I/O headers? Supporting it all by hand and reviewing changes introduced by device-packs is beyond any reasonable effort. Just using headers from the newest device packs makes it easier to transition from IDEs that use such packs, but it might render quite some users code invalid, so that they would have to port their code to the layout of device packs.
2. While generating HTML docs works as expected, I have considerable problem in generating PDF. 100.000+ errors due to non-existent fonts glyphs. I tried to follow the docs to install new fonts in TexLive, but that's very complicated and requires closed source stuff which is not hosted by TexLive. Plus, Doxygen generates tex files that will hang the TeX processor. It will bail out after 100 errors, but no pdf is generated. What am doing is just make pdf in $build/doc/api.

[dl8dtl]

I'd prefer keeping traditional IO headers where they exist. Atmel eventually switched to generated headers, which might (as you noticed) incompatible with ours. In particular, in the past, names in datasheets have sometimes been changed, and then, we kept the historic names for compatibility as aliases. Automatically generated headers probably would not work that way.

Also, in particular for the ATmega*RF devices, we once tried to establish a new, more error-preventing naming scheme using bitfields (similar to what can be found now with many ARMs). Atmel's auto-generated headers don't follow that scheme, but there might be sourcecode in the wild using it.

For new devices that don't have any precedence in avr-libc, we could simply use their auto-generated headers.

I'm running into troubles with compiling the documentation now myself. It seems recent doxygen produces LaTeX macro calls that just don't work (and then produce hundreds of errors). I'll investigate a bit further.

[sprintersb]

There are also the following issues with the documentation:

• release_method.html is outdated and needs a refresher, it still explains SVN stuff.
• In avr/interrupts.html#avr_signames there is a list of all ISR names for all devices, which is pretty much outdated. I'd rather add a FAQ entry on how to find IRQ names for a device than supporting more than 10000 entries...

[dl8dtl]

Updating the release stuff is probably not going to be a big deal, but first, I need a working Doxygen setup again that produces valid LaTeX.

The interrupt name table has once been automatically generated, but the infrastructure for that is now defunct (and IIRC their XML files also changed format). So yes, it needs to be written in a generic form.

[sprintersb]

Doxygen setup again that produces valid LaTeX.

The avr libc documentation says to install MiKTeX, so is TexLive supposed to work at all?

[dl8dtl]

MikTeX used to be a fairly complete TeX setup once, probably at a time when there wasn't a TeXLive at all.

Anyway, I've always been compiling it with TeXLive (as long as there used to be a TeXLive). My current issue really seems to be related to the longtabu environment which Doxygen offers as their own LaTeX implementation for tables that are defined in plain HTML in the Doxygen source. Maybe it's related to some special stuff there, we are using rowspan/colspan, for example.

All I can say: that used to compile before, with older versions of Doxygen. I just fails now.

[sprintersb]

we are using rowspan/colspan, for example

Doxygen allows rowspan/colspan and has it in its documentatio: https://www.doxygen.nl/manual/tables.html

To all of my knowledge, the only HTML-like elements are ones explicitly allowed and understood by Doxygen.

[dl8dtl]

Yes, all there. It produces LaTeX source code that contains the row and column spans, yet the LaTeX fails to compile.

[sprintersb]

I went ahead and added a new script for and version of vectortable.dox in 5021ae0.

• The script extracts the information from #include <avr/io.h> (hence needs some up-to-date compiler).
• The table is huge, with ~650 rows and ~12000 mcu mentions. Therefore, it's wrapped in \htmlonly.

[dl8dtl]

but first, I need a working Doxygen setup again that produces valid LaTeX.

Update on this: checking out release 2.1.0, I can compile the documentation. So, the breakage must have been introduced by one of the documentation changes since … guess I have to bisect that now, unless I can find it by reviewing the diffs.

[sprintersb]

I can compile v2.1, too (TexLive 2022), but the pdf has only images and table borders, not a single letter is visible. After

apt install doxygen-latex
apt install texlive-fonts-recommended
tlmgr install psnfss
tlmgr install helvetic

I still get zillions of Missing character: There is no ... in font nullfont! due to

kpathsea: Running mktextfm pcrro8t
.../mktexnam: Could not map source abbreviation  for pcrro8t.
.../mktexnam: Need to update ?
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; ; nonstopmode; input pcrro8t
This is METAFONT, Version 2.71828182 (TeX Live 2022) (preloaded base=mf)
kpathsea: Running mktexmf pcrro8t
! I can't find file `pcrro8t'.
...
! Font T1/pcr/m/it/10=pcrro8t at 10.0pt not loadable: Metric (TFM) file not found.
kpathsea: Running mktextfm nullfont

The infinite loop is in the longtabu environment in mem_sections.tex for table Memory Regions of the Default Linker Script. Features not used before are: <caption>, <th>, superscript.

The errors can be seen without \batchmode.

The source uses <td> without </td> which should be fine; Doxygen adds the </td>'s in the HTML version.

[dl8dtl]

not a single letter is visible

That seems like a font installation issue. I didn't run into that, I always got a readable PDF.

I could get the mem_sections.tex to compile after removing the colspan from a normal table row – maybe it's supported only in table headings? Anyway, it then stumbles across more serious errors in assembler.tex which I still did not understand nor was able to remedy them.

The source uses <td> without </td> which should be fine

It is; adding </td> doesn't change the error behaviour at all.

So it must be something else in those tables, still investigating.

[dl8dtl]

Guess we are stumbling across genuine Doxygen bugs here. :-(
The first culprit I found is \anchor inside a table. If I remove all of them in assembler.dox, it compiles. (The \anchor inside a normal list can remain.)
Next, it complains about LaTeX errors in the demo project now.

[dl8dtl]

I see there is a doxygen 1.11.0 just released. I have to compile it here outside of the normal FreeBSD ports infrastructure though, as they have not yet been updated.

[dl8dtl]

Unfortunately, still the same errors. :-( So guess we have to prepare a bug report, but that needs to isolate the bugs in a minimum example.

[dl8dtl]

There appears to be more breakage even in older releases. For example, most of the content for <avr/power.h> disappeared between these two releases in the LaTeX / PDF version.
All that appears to be a big mess. :((

[sprintersb]

Maybe I missed some fixes like 258b20e

[dl8dtl]

<power.h> looks OK to me, so maybe it's in another file. The various LaTeX source files are all concatenated together, so errors from other files might affect one that is later in the chain.
Strange that compilation of the docs on 2.0 works even without this kind of changes – I explicitly checked it. I can still build a 2.0 documentation that is more complete.

All in all, Doxygen appears to be a very sensitive baby …

[dl8dtl]

Small update: \anchor inside a table seems to be severely broken, but it's easy enough to move the anchor just before the table. Then, it compiles now.
Updated a number of things, it's right now in the documentation_fixes branch, I'm going to file a PR for that soon.
Once that is done, I think we are fine for a release.

[sprintersb]

@anatol @hzeller The main obstacle for a new release (generating PDF documentation) is now out of the way. What avr-gcc version are you planning to use with the next libc release?

[anatol]

Arch Linux does not dictate a version you need to release. Arch Linux helps to bring software you provide to users. Arch always packs the latest release made by upstream (you).

[sprintersb]

Arch Linux does not dictate a version you need to release. Arch Linux helps to bring software you provide to users. Arch always packs the latest release made by upstream (you).

I am asking because the libc depends on the version of the compiler, and how the compiler has been configured. Does this mean than when a new GCC version is released, then Arch does outomatically rebuilds libc? Same for releasing Binutils, which GCC depends on etc.

[hzeller]

I am using NixOS, and while I am not a direct packager of gcc, libc etc, it works similar like in Arch: the latest version of everything is combined, and if there are cross-dependencies, things are re-compiled; so say avr gcc changes, then avr libc, binutiles etc. is also recompiled. So nothing to worry about.

[dl8dtl]

What avr-gcc version are you planning to use with the next libc release?

Mine is 11.2.0.

Not sure, are we just going to roll source code releases, or do we also want to maintain binary releases?

[hzeller]

I'd do source-code releases and then have the package maintainers by different Linux distros figure it out.

[dl8dtl]

Sure, but that's Linux.

In the past, we also provided binary releases for those who don't have the ability to easily get at their own compilation. Not sure if anyone would still need these. People running Microchip tools would probably just stick with their old compilers and libraries anyway, I guess.

[anatol]

At arch we always try to use the latest released version of a project (gcc, libc, ...). We just need the source tarball, and then we compile our own binary package that users will install.

[dl8dtl]

The source tarball will be there, of course. That's what always falls out of the make distcheck step during release building.

[dl8dtl]

2.2.0 is done

[anatol]

Thank you very much!

[sprintersb]

2.2.0 is done

Great! Though README.md documentation still points to nongnu.org (and has Atmel).

[sprintersb]

And in my local HTML documentation, the "Main Page" is just containing a table-of-contents of the documentation, the very page content like supported AVR devices is missing.

...found it: Yet another builddir vs. srcdir issue: 9aa7056

[sprintersb]

And maybe https://avrdudes.github.io/avr-libc/ needs "Atmel" being adjusted, too. Nerve-wrecking me.

[sprintersb]

The configure.ac version should now be 2.3.0git or 2.2.1git or something like that, no?

[leventelist]

Thank you all for this release!

…

On Sun, Jun 9, 2024, 01:21 Jörg Wunsch ***@***.***> wrote: 2.2.0 is done — Reply to this email directly, view it on GitHub <#905 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADLOFSYK2M5B6G2UZL2FGKLZGOGYVAVCNFSM6AAAAAATY2BXF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJWGIZDGMRSHE> . You are receiving this because you commented.Message ID: ***@***.***>

[sprintersb]

@dl8dtl One more question: On https://avrdudes.github.io/avr-libc/ there are links to the documentation, but no links to release balls. And the release notes, are they only available per NEWS file, or is there some "official" release notes page?

[dl8dtl]

2.2.0 is done

Great! Though README.md documentation still points to nongnu.org (and has Atmel).

Thanks, e3cd701

...found it: Yet another builddir vs. srcdir issue

Ah sorry, consequence of generating main_page.dox now (but the diverging license statements were really painful).

The configure.ac version should now be 2.3.0git or 2.2.1git or something like that, no?

b791e8d

Also forgot this in the release procedure explanation.

And maybe https://avrdudes.github.io/avr-libc/ needs "Atmel" being adjusted, too.

I plan some more fine-tuning there anyway.

there are links to the documentation, but no links to release balls.

Well, the release tarballs are available from the normal Github releases area. But we could add a pointer there, too.

And the release notes, are they only available per NEWS file, or is there some "official" release notes page?

Basically yes, as it's cumulative. We could certainly also put that release's copy of NEWS straight in the docs directory.

[hzeller]

Could you copy the relevant section from the NEWS file to the release notes in the github release ?
https://github.com/avrdudes/avr-libc/releases/tag/avr-libc-2_2_0-release

This is probably where most people will look, and it is easy to do (modulo some hand-formatting as markdown maybe).

[dl8dtl]

I see an option there to create release notes automatically (based on merged PRs), but I don't see one to explicitly set release notes.
I could just add NEWS to the list of assets, of course.

[hzeller]

What I mean just in the description of the release; so where it now says This is the first version of the AVR-LibC project that is released from Github. ... you can add more text, manually extracted from the NEWS section (for you, there should be an edit button in the release)

There is also a way to show the changes between tags, but with a lot of changes like here, this is less uesful.
https://github.com/avrdudes/avr-libc/compare/avr-libc-2_1_0-release..avr-libc-2_2_0-release

[dl8dtl]

Well, I wouldn't want to blow up that description that much. It would be 180 lines for the current release – and I doubt it is really well enough ready for markdown display.

I just added the file as an asset.

I also added a section about where the releases can be found in the Github pages.

[hzeller]

Fair enough, maybe just a link at that commit highlighting the range of the NEWS section ?

It serves two purposes: it is possible to see the NEWS directly (while in the assets, the browser just downloads the file), and it makes it discoverable for folks to find where it is.

So, adding a link like this:

https://github.com/avrdudes/avr-libc/blob/16b742119eaed8d966929033b1ad325faea89798/NEWS#L1-L179

... will show up as

avr-libc/NEWS

Lines 1 to 179 in 16b7421

	*** Changes in AVR-LibC-2.2.0:
	* General:
	- Project moved to Github
	- Support for many new devices has been added, like devices from the
	AVR 0-series, 1-series, 2-series, AVR-Dx and AVR-Ex, but also for
	some older devices.
	- Parts of the user manual have been reworked, like the inline assembly
	Cookbook and the documentation of memory sections.
	- The multilib layout of the library, and what device belongs to which
	multilib variant, is no more hard coded in AVR-LibC but follows the
	compiler's multilib layout.
	* Improvements and additions:
	- Add support to new multilib layout / 64-bit [long] double compiler
	(Issues #642, #670)
	- Added support for new devices (Issue #824):
	ATtiny202 ATtiny204 ATtiny212 ATtiny214 ATtiny402 ATtiny404
	ATtiny406 ATtiny412 ATtiny414 ATtiny416 ATtiny417 ATtiny424
	ATtiny426 ATtiny427 ATtiny804 ATtiny806 ATtiny807 ATtiny814
	ATtiny816 ATtiny817 ATtiny824 ATtiny826 ATtiny827 ATtiny1604
	ATtiny1606 ATtiny1607 ATtiny1614 ATtiny1616 ATtiny1617 ATtiny1624
	ATtiny1626 ATtiny1627 ATtiny3214 ATtiny3216 ATtiny3217 ATtiny3224
	ATtiny3226 ATtiny3227 ATmega808 ATmega809 ATmega1608 ATmega1609
	ATmega3208 ATmega3209 ATmega4808 ATmega4809
	- Added support for AVR-Dx devices (Issue #881):
	AVR16DD14 AVR16DD20 AVR16DD28 AVR16DD32 AVR32DA28 AVR32DA32
	AVR32DA48 AVR32DB28 AVR32DB32 AVR32DB48 AVR32DD14 AVR32DD20
	AVR32DD28 AVR32DD32 AVR64DA28 AVR64DA32 AVR64DA48 AVR64DA64
	AVR64DB28 AVR64DB32 AVR64DB48 AVR64DB64 AVR64DD14 AVR64DD20
	AVR64DD28 AVR64DD32 AVR128DA28 AVR128DA32 AVR128DA48 AVR128DA64
	AVR128DB28 AVR128DB32 AVR128DB48 AVR128DB64
	AVR64DU28 AVR64DU32
	- Added support for AVR-Ex devices:
	AVR16EA28 AVR16EA32 AVR16EA48 AVR16EB14 AVR16EB20 AVR16EB28 AVR16EB32
	AVR32EA28 AVR32EA32 AVR32EA48 AVR64EA28 AVR64EA32 AVR64EA48
	- Added support for Reduced Tiny devices:
	ATiny102 ATtiny104
	- Added support for Classic devices:
	ATmega168PB ATmega328PB ATmega324PB
	- Added a new module to lib<mcu>.a that can be used as part of the
	startup code by the compiler. The compiler will link the code when
	a device from the AVR-Dx or AVR-Ex families uses a non-default layout
	of NVMCTRL_CTRLB.FLMAP (Issue #931, Binutils PR31124, GCC PR112944).
	For more details on the feature see the GCC v14 release notes at
	https://gcc.gnu.org/gcc-14/changes.html#avr
	- Added support for: strndup.
	- Added support for: PROGMEM_FAR, PSTR_FAR, strchr_PF.
	- Added support for ccp_write_spm() in avr/cpufunc.h
	- The delay routines no more include math.h but use built-in functions
	__builtin_fabs and __builtin_ceil instead of fabs and ceil. This means
	the delay routines are now independent of -f[no-]freestanding (Issue 580).
	- Added macros pgm_read_qword, pgm_read_qword_near, pgm_read_qword_far.
	- Added inline functions to read from progmem that return a type as
	indicated by the function name, like char pgm_read_char (const char*).
	The functions adjust to -mint8, -mdouble= and -mlong-double=.
	Functions for fixed-width types are pgm_read_i64, pgm_read_u24, etc.
	* Functions that read from beyond 64 KiB are suffixed _far and take
	an uint_farptr_t as argument.
	* pgm_read_float has been turned from a macro that takes uint16_t to
	an inline function that takes const float*.
	* pgm_read_byte, pgm_read_word and pgm_read_dword remain as they were
	and still take an uint16_t argument for compatibility and legacy code.
	- Added experimental templates pgm_read<> and pgm_read_far<>. They are
	only available when macro __pgm_read_template__ is defined.
	- Added EEPROM support for: double, long double, uint64_t (*_qword).
	- AVR-LibC does not use section .progmem.* any more for lookup tables and
	string literals. Instead, .progmemx.* is used which does not require
	that the data resides in the lower 64 KiB of program memory.
	This means that on devices with more than 64 KiB of program memory,
	the ELPM instruction is used to read the data where formerly it was LPM.
	Hence code size and execution times on such devices will slightly
	increase for functions from the printf and scanf families, and for libm
	functions that use power series. (Issue #962).
	Notice that only since Binutils v2.29 (PR21849), section .progmemx is
	located after the .text sections.
	- The startup code now defines symbols like __DATA_REGION__LENGTH__ and
	__DATA_REGION_ORIGIN__ according to the memories of the used AVR device
	(Issue #936). These symbols are used by the default linker scripts to
	diagnose when the text or data region overflows.
	To date, only a core specific default value was used, but the devices
	that belong to the same core architecture have different memory sizes.
	- The pgm_read_* and pgm_read_*_far macros and functions now also work for
	the Reduced Tiny devices. (Issue #563). The implementation assumes that
	GCC implements PR71948 which was added in v7. Notice that on Reduced Tiny:
	* There is no need for PROGEMM at all because all const objects in static
	storage are located in program memory since Binutils v2.27 (PR20849).
	* Even when PROGMEM is used, no pgm_read functions or macros are required.
	See the GCC documentation on the __progmem__ attribute for Reduced Tiny.
	* Issues closed:
	- [patch #9543] Add avrxmega3 devices. #824
	- [bug #49567] Use meta-info from --print-multi-lib and
	--print-multi-directory #642
	- [bug #57071] Fix math.h and function names that block 64-bit
	double #670
	- Issue #476 [bug #32945] RAMPZ clobbered in far-pointer library.
	Functions from the far-pointer library in libc/pmstring like
	memcpy_PF that read from program memory using ELPM must set
	RAMPZ to the high byte of the 24-bit address. On devices that
	don't use RAMPZ exclusively with ELPM, RAMPZ has to be reset when
	the function is finished. These are devices with an EBI (External
	Bus Interface): ATxmega64A1, ATxmega64A1U, ATxmega128A1,
	ATxmega128A1U, ATxmega128A4U.
	- Add device support to avr/power.h for:
	ATtiny441 ATtiny841
	- FDEV_SETUP_STREAM from stdio.h now works with C++ (Issue #898)
	- More than 80, mostly historic issues have been closed -- too many
	to mention all of them here
	- Fixed wrong prototypes of frexp, frexpf, frexpl in math.h (Issue #929)
	- time.h: function mktime() is off by 1h when [EU] DST is active (Issue #967)
	* Pull requests:
	- Logo [#969]
	- Documentation fixes [#968]
	- Issue #962 - libm: Use ELPM for tables on ELPM devices. [#964]
	- Issue #934: Fix EEPROM write issue on AVR-Ex and AVR-Dx family [#948]
	- Add code to initialize NVMCTRL_CTRLB.FLMAP in new module flmap-init.S enhancement [#947]
	- Add AVR-Ex devices enhancement [#946]
	- Issue 940 runtest [#941]
	- include/avr/io*.h: Update I/O header files enhancement [#938]
	- Issue #936: Provide symbols for exact memory layout. enhancement [#937]
	- Issue #931: Initialize NVMCTRL_CTRLB.FLMAP for Devices that have it. enhancement [#935]
	- Issue #931: Initialize NVMCTRL_CTRLB.FLMAP for Devices that have it. [#933]
	- Issue 929: Remove __ATTR_CONST__ from frexp* protoypes in math.h. [#932]
	- #890 #884: Fix / add entries for ATmega808/9, ATmega1608/9, ATmega3… [#927]
	- #921: Use all h files of $srcdir/include/avr in Makefile.am. enhancement [#925]
	- #892: configure.ac has outdated CHECK_AVR_DEVICE and AM_CONDITIONAL l… [#924]
	- avrxmega3: fix header installation for attiny424 [#921]
	- Rename aux.c to _aux_.c duplicate [#920]
	- iom32u4.h #define USBRF 5 [#919]
	- memory: Allow the use of stdint types [#918]
	- doc: Note attiny9 being supported documentation [#915]
	- Fix __BOOT_SIGROW_READ for some ATtiny [#914]
	- .githud [#908]
	- Extend _delay_loop_2 so it works with AVR_TINY. [#902]
	- Fix inline asm constraints of wdt_enable, wdt_disable. [#901]
	- Use autotools to determine Python command to run mlib-gen.py. [#896]
	- Issue #894: Remove scripts that make binary distributions and RPMs. [#895]
	- Fix issue #892: [#893]
	- Fix some avrxmega3 device names of generated files [#885]
	- .gitignore: Add outputs of ./boostrap [#883]
	- *.py: Use python3 instead of python [#882]
	- Added support for AVR-DA and DB devices [#881]
	- README.md: fix typo in URL [#873]
	* Other changes:

[dl8dtl]

Fair enough, maybe just a link at that commit highlighting the range of the NEWS section ?

Thanks for the idea, that indeed looks good!

[sprintersb]

One final nit: Would be nice to go from the github.io page directly to the code page. Currently, you have to github.io -> releases -> code.

[dl8dtl]

The backlink is at the bottom of the Github.io page.

[sprintersb]

The nongnu page still points to older versions. And nongnu is still spit out by search engines. Maybe that could be adjusted, too?

https://www.nongnu.org/avr-libc/
https://www.nongnu.org/avr-libc/user-manual/index.html

Notice the link to the documentation is to the "latest" as it doesn't have the version in the URL.

[dl8dtl]

I added a headline that indicates the move to Github.
I also added a 00README file to the downloads area.