What's the latest PUBLIC newlib.library version?

@all

What's the latest publicly released newlib.library?

I need to know because I don't want to write software that depends on as yet unreleased features.

Hans

@Hans

It's version 53.30 AFAIK.

If you use a newlib function that requires a newer version than this you should get a warning at the link stage.

@salass00

Indeed

13.Workbench:> version newlib.library full
newlib.library 53.30 (12/02/2014)

@all

Wow! That's really old. It also means that features I wanted to use aren't available.

Hans

@Hans

Quote:
To add insult to injury, let's also mention this particular newlib gotcha that kas1e has recently discovered. It appears that our newlib is in need of some love.

Well what's holding up the release of newer versions? It seems as if devs and beta testers don't just have access to new stuff that's still in development, but also have access to stuff that was finished years and years ago but hasn't found it's way into a release.

@NinjaCyborg
Quote:

A bit of necromancy, but to answer: nothing, but company/management/motivation factors. Now there some moves in management terms, so things for some time will be better. How long and how better no one knows. But I am sure you can't hope for something like a new version out, and on next days hit users.

With 4.1 FE update 2 + hotfix the latest public newlib.library should now be version 53.62.

@salass00

What nice features & opportunities will this give us including Hans?

Can someone explain how the newlib works. I know that it is an implementation of the C library. I know the difference of linker libs (static/SO) and shared library (.library).

The new version that was just released provides a shared library, but there is no updated to the libc linker library.

A lot of ports, surely, would use the linker library. There will be no code that explicitly opens "newlib.library". If the libc is just forwarding calls to newlib.library, why is the libc in newlib so large? I would have expected a new libc.a too.

Regs,

A newer version of the static library will be available in the next SDK when this is released. Then you will be able to use the latest methods of newlib in your apps or ports.

@walkero

Okay, this makes sense. Thanks.

Once updated newlib via amiupdate I'm no more able to compile projects due "-lamiga" switch no more recognized by "ld" command.
Native builds of course, ..maybe I'm the last one to not using cross compiling?

@flash

I also had some problem as a .h file tried to include utility but that’s a directory, so I got error, I comment it out and stuff compiled again.

@rjd324

Quote:
Isn't there? The libc.a in the SDK is 553,018 bytes and is dated 01-Jan-21, while the one in the latest newlib update is 684,962 bytes and is dated 10-Mar-22. Besides the later date, being significantly larger is consistent with having more functions.

@rjd324

Quote:
I think that's a result of inefficiency in the object module format. In order to allow only those functions that are used to be linked into a program, every single function in the library has to be in its own object module.

While the actual glue code to turn a newlib call into a newlib.library call is likely not very big, there is a good deal of other overhead in the object module. Multiply that by the rather large number of functions in the library, and all that overhead adds up. (Also, I'm guessing that since libm.a is empty, the math functions are actually in libc.a as well, making it even bigger.)

Look at libauto.a. It's quite large too, and all it does is open and close libraries. But it handles a lot of different libraries, each of which requires its own object module. So again, all the overhead adds up.

@msteed
Quote:

I got my update using the AmiSphere... thing. Only the shared library was updated. There was also zero release notes, which would have been nice. Walkero says that we will wait for the next SDK to get a marching updated linker library.

As for your description about the size of the linker library despite forwarding calls... thanks for the explanation.

@LiveForIt

Not sure what you means.. you refer to .h include file issue, instead "ld" is linker, so it's final stage of compiling chain.

Seems that ld version 2.23.3 doesn't accept more "-lamiga" switch. Omitting it all amigalib functions like ArgArrayInit, ArgArrayDone, ArgInt, ArgString, etc.. are no more recognized.

Before newlib update all worked as usual.

@flash
The libamiga library (-lamiga) is not necessary for newlib. If you check a new installation of the SDK, the library is a soft link to the clib2 libamiga library. You just need either to recreate that link or copy that library to newlib.

The SDK installer does the following

@rjd324

Quote:
Same here, using AmiUpdate.

Quote:
There actually are release notes. Try looking in SYS:Documentation/ReleaseNotes, which is where the installer puts them. If you don't have a directory by that name then the release notes are not installed. I think the standard location for release notes is SYS:Documentation/ReleaseInfo, so maybe that's the problem.

Quote:
In addition to the new linker libraries (which yes, are there), there are a bunch of updated newlib include files in the update as well (you should see some includes with 2021 dates). I'm wondering if something went wrong with your install (assuming you used the auto-install option), and your SDK didn't get updated properly or at all.

The SDK won't be updated if you don't have an SDK: assign, but I assume you do have that. I'm not sure what else could have gone wrong. This is the relevant portion of the AutoInstall script:


(makelinks is a shell script that re-establishes the softlinks that were deleted by Delete ALL.)

I always install everything manually, because I never trust install scripts to do the proper thing across all the different system setups out there. If you've still got the update archive try looking at it with LHA or UnArc and see if some of the things you're missing aren't in there.