[gccsdk] Loading SO Manager automatically
John.Tytgat at aaug.net
Mon May 26 12:29:57 PDT 2008
In message <BLU141-W32823391AAE284A8BE6FFFF0C20 at phx.gbl>
alan buckley <alan_baa at hotmail.com> wrote:
> > On Fri, 23 May 2008 23:50:58 +0200 John Tytgat wrote:
> > In message
> > alan buckley wrote:
> >> I was wondering if it would make sense to modify the !SharedLibs
> >> !Boot file so that it could automatically load the SO Manager
> >> when an ELF file was run.
> >> I was thinking of changing the boot entry for ELF files to:
> >> Set Alias$@RunType_E1F SharedLibs:SOM1stRun %%*0
> >> and have a new Obey file in the SharedLibs folder called
> >> SOM1stRun with the following contents.
> >> | Load the SOManager and run an ELF executable
> >> RMEnsure SOManager 2.00 RMLoad SharedLibs:SOManager
> >> RMEnsure SOManager 2.00 Error Need at least v2.00 of Shared Object Manager (SOManager)
> >> Set Alias$@RunType_E1F SOMRun %%*0
> >> SOMRun %*0
> >> Any comments?
> > Yes, I don't think this is a good idea. Why would you do that instead of
> > only relying on activation when !SharedLibs gets run ?
> This was so that it could be placed in a position where it did not need to
> be run. If we want to put it in !Boot.Resources anyway this is
> really not an issue.
> My take on the RISC OS Packaging project was that it would probably
> be better to put it in Apps.Libraries and register the boot variables
> including one to launch the SOM1stRun obey file when the first ELF
> file is run.
That's equally good as well. I don't think there is a technical relevant
difference so it's matter of taste and personal preference of the person(s)
doing the packaging (and not the user taste & preference).
> > Loading a module when Filer sees a directory is bound to have user
> > dissatisfaction IMHO. Firstly just by the fact binaries get automatically
> > loaded. And secondly, you could have a Wimp_ReportError error with the
> > RMEnsured lines mentioned above .
> I think you misunderstood what I was proposing. The Module would only be
> loaded when the first ELF file was run. The SOM1stRun obey file would only
> be run when this happened. The !Boot file just assosiates the ELF file type
> with this Obey file.
Yes, I completely misread your proposal. :-( Apologies. Your proposal is
fine as it is actually doing what I suggested it should be doing.
> > I see a suitable place for !SharedLibs in the system's !Boot.Resources
> > as all those apps get automatically run at boot time and SOManager will be
> > loaded at that moment. And we could even finetune its current !Run so that
> > SOManager module only gets loaded when the first ELF binary is executed.
> My idea with the SOM1stRun obey file is one way this kind of fine tuneing
> could be done.
> I really don't know which way to go here though. If the plan is to put it into
> !Boot.Resources, then the riscpkg package could be made to do that and
> in this case wouldn't need to register any of the variables.
> Would people prefer for the !SharedLibs to be put in !Boot.Resources?
If a user goes the RiscPkg way, we follow its rules to make RiscPkg
packages. And if that's suggesting/dictating Apps.Libraries, so be it.
If users want a more flexible way where they want to install their RiscPkg
packages (but I doubt this being a case for the shared libraries) then it
should be discussed with and possibly acted on by the RiscPkg people to
add this functionality.
If uses don't want to deal with RiscPkg, they can install !SharedLibs where
they want and probably !Boot.Resources is the most convient place.
Is the answer you were looking for ?
John Tytgat, in his comfy chair at home BASS
John.Tytgat at aaug.net ARM powered, RISC OS driven
More information about the gcc