Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
10 user(s) are online (6 user(s) are browsing Forums)

Members: 0
Guests: 10

more...

Support us!

Headlines

 
  Register To Post  

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


See User information
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.


Edited by rjd324 on 2023/6/1 22:44:16
If liberty means anything at all, it means the right to tell people what they do not want to hear.
George Orwell.
Go to top
Re: How does AmiUpdate work internally?
Just can't stay away
Just can't stay away


See User information
@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

Go to top
Re: How does AmiUpdate work internally?
Quite a regular
Quite a regular


See User information
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.

If liberty means anything at all, it means the right to tell people what they do not want to hear.
George Orwell.
Go to top
Re: How does AmiUpdate work internally?
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: How does AmiUpdate work internally?
Just can't stay away
Just can't stay away


See User information
@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

Go to top
Re: How does AmiUpdate work internally?
Quite a regular
Quite a regular


See User information
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.

Back to a quiet home... At last
Go to top
Re: How does AmiUpdate work internally?
Just can't stay away
Just can't stay away


See User information
@abalaban

Quote:
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)
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:
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?
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

Go to top
Re: How does AmiUpdate work internally?
Quite a regular
Quite a regular


See User information
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?

If liberty means anything at all, it means the right to tell people what they do not want to hear.
George Orwell.
Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project