How does AmiUpdate work internally (and provided newlib updated March)?

Say I installed the SDK (that contains an older "libc.a" for newlib)

Say I then ran AmiUpdate and get the updated newlib that was pushed out; presumably that updates both "newlib.library" and replaces the older "libc.a" in the SDK?

Now, say that I reinstall the SDK overwriting the previously updated "libc.a".

If I run AmiUpdate again, will it recognise that my SDK "libc.a" for newlib is out of date and offer me to resinstall it again - or does it merely check "version newlib.library"?

In any case, is there not a way to see all the recent updates. I should be able to see them and redownloaded them even if the program thinks that I do not need them.

@rjd324
AmiUpdate only checks the version of a single component in a package, in this case newlib.library.kmod
libc.a shouldn't be in newlib updates anyway, maybe libc.so but not libc.a. It's, or at least was while I still maintained it, an user-only package, developers parts are in the SDK instead.

For other cases you can use SystemRollback to restore an older version, but for the newlib libc.a that doesn't help.

Documentation for AmiUpdate is available on http://amiupdate.codebench.co.uk/index.php?page=description

Well, since I have no way to re-download the newlib updated I cannot remember what was in it - but I am 90% sure there was a libc.a in there.

@rjd324
Rollback disabled in the AmiUpdate preferences?

I don't remember how AmiUpdate checks the versions of libraries, if it's using the real library version by loading a library and using struct Library* or by checking the $VER: string.
If it's using the $VER: string and newlib.library.kmod has a $VER: simply change the version there to something lower in the SYS:Kickstart/newlib.library.kmod file and restart AmiUpdate. Ugly hack, but may work.

@rjd324

You can also use the Updates prefs program to tell AmiUpdate to keep downloaded archives, and to save them in a path on your disk (as opposed to in RAM:) - it's on the first tab page of the prefs in the lower half.

That way you can later check what was actually in the archive.

Best regards,

Niels

If the script for auto-installing is correctly written and makes use of the proper way to update *all* files on the file system (do not remember the name of the dedicated shell command atm) then you should be able to browse all your installs in the rollback utility and find the one that updated both libs, rollback this one and AmiUpdate will offer you the ability to download again the package.

As Joerg said libc.a should not be in the same update as newlib because they are targeted to different audiences: users VS developers. There is different situations where mixing won't work, you named one, but what about when I install the update as a simple user (so no SDK installed, hence no place to install the libc.a) but later on I learn how to code and install the SDK?
I advise making two updates one for newlib and one for libc.a the second requiring a given version of newlib (can be described in AmiUpdate database)
BTW AmiUpdate also checks using filesystem dates as a last resort.

@abalaban

Quote:I think you are referring to the CopyStore command. Yes, many AutoInstall scripts only use CopyStore for the main components and plain Copy for the rest, maybe to save space for the rollback? Personally, I don't use the rollback feature at all in AmiUpdate (rely on backups instead, so I'm in total control myself), so I don't have any opinion on whether that's a good idea or not.

Quote:This is not only a problem for newlib, but of every package which has an SDK component. To solve it completely, we would need to have a separate AmiUpdate database especially for all the SDK components and have each one depend on the relevant version of the package in question being installed. And then of course also maintain separate packages with only the SDK parts of those packages.

The alternative - which can be used already - is to create a new OS installation on a fresh boot partition when you decide to install an SDK, start with e.g. FE plus updates 1 and 2, then install the SDK, and follow up by letting AmiUpdate install any newer versions of packages including their SDK parts if found.

Best regards,

Niels

Actually,

I recall that when the new "newlib" was released in March, that AmiUpdate package contained only the "libc.a" - but what about the "libc.so" - or was that always there?

If it was not, in the case that you linked with "-use-dynld" the linker would have picked up the old "libc.so".

I must be wrong - but I have the impression that only the libc.a was there.

In any case, these are nothing more than forwarding calls to the Shared Library (newlib.library). Presumably, if a new C library function is implemented, it is implemented in the Shared Library, but the object code (libc.o) must also be updated to forward the call on.

By only providing the libc.a - it will work if there is no -use-dynld. It will even work with -use-dynld so long as there is no libc.so, but if there is a libc.so then surely we will have an undefined reference since we didn't get that update?