RISC OS Shared Libraries | RISC OS news and information from Drobe


Beta! \| About us \| Contact \| Submit news \| RSS \| Twitter	Webspace \| Tech docs \| Downloads \| BBC Micro \| Gallery \| Wallpaper

RISC OS Shared Libraries

By Peter Naulls. Published: 29th Sep 2003, 12:41:42.

One for everybody

Not exactly breaking news, but we've been meaning to cover this for sometime, and it remains relatively new to RISC OS.

Ask for the list of things people would like to see in RISC OS - Preemptive Multi-Tasking, improved memory protection, better browsing, etc, and possibly high on the list will appear shared libraries.

Shared libraries are just that - they are chunks of code that contain library functions that can be shared by many programs running at once. One of the important features of shared libraries is that they can be upgraded independently of the programs that use them, avoiding relinking.

Currently on RISC OS, if you want to use a newer version of a library with a program, you need to create a new binary, which will be statically linked with it, meaning that all the library code is included in your program's RunImage. This is particularly unfortunate for programs using things like UnixLib, which can be frequently changed.

There is an existing shared library system on RISC OS, but it's never been extensively used outside of the SharedCLibrary (I only know of one other example). It works via a stubs plus module system - whilst ok as far as it goes for the SharedCLibrary, isn't really ideal in general use. The code needs to exist in a module, which isn't the best, and you need a new SWI base for every module. It's all a bit fiddly and inflexible. Perhaps more importantly, it precludes automated generation of shared libraries from existing Unix build systems.

Of course, Linux, Windows and just about every other non-trival OS has a shared library system - in the form of .dll or .so files, but RISC OS has missed out, perhaps for historical reasons, and the minimal memory requirements of most RISC OS programs (memory saving being another advantage of shared libraries).

To the Rescue

Steven Simpson has started on a shared library system for RISC OS, and you can see his efforts on his RISC OS Shared Libraries page.

It's somewhat experimental, and certainly in its early stages, but you are of course encouraged to try it out. Steven tells drobe.co.uk he based his efforts on the requirements of the One True Dynamic Linker, in a document drawn up by ex-RISC OS user, Mark Wooding. Dynamic linking is a subset of the behaviour required by shared libraries, and essentially means code is loaded upon demand.

Steven's developments were done using GCCSDK under Unix, which shows you don't need to develop natively. Unfortunately, GCC itself can't yet create suitable code for dynamic linking in RISC OS (the problems being essentially those required to allow modules with GCC).

Hopefully in future we'll see practical use of this. In particular, UnixLib would greatly benefit from being a shared library.

Links
RISC OS Shared Libraries

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

The obvious issue with using the SharedCLibrary approach is that you can't just load a new version, as all the current applications that are running that are linked to it expect it to be in a certian place. Killing the old one and loading a new one results in programs pointing to something random in the RMA. You at least to be able to see the explosion happen if you tried to replace the SharedCLibrary if it had already been softloaded. (Programs bound the the one in ROM don't care of course, because it's in ROM and can't be removed.)

mdw has done shared libraries for RISC OS before. The problem with his original linker is that it needed the application to start the show off - it wasn't automatic when the program was loaded. Perhaps it's time for an ELF loader module that handles this for us, and start building ELF executables instead of AOF ones?

One of the other interesting issues is *where* to put the shared code. You want to try to avoid putting them in the RMA because of its size limitation on many machines, and to try to prevent fragmentation. Suggestions have been raised about putting it in a dynamic area, although there can be problems executing code in such areas because of their location (there are of course ways around this...)

Shared libraries are one of the things that RISC OS is missing that it should be possible to implement without breaking everything, like PMT and further memory protection would. I hope it's a success.

nunfetishist on 29/9/03 1:53PM [ Reply | Permalink | Report ]

Would truely be lovely to run ELF's, now of course, any system to run ELF's would have to be called DWARFS, just for the comic value

NoMercy on 29/9/03 9:36PM [ Reply | Permalink | Report ]

DWARF is the companion format to ELF that deals with debugging symbols.

nunfetishist on 29/9/03 10:52PM [ Reply | Permalink | Report ]

Bah, dwarfs hate elves... gotta be some other mythical creatures of that set who's names are free though

NoMercy on 29/9/03 11:34PM [ Reply | Permalink | Report ]

ELF is clearly the right format to use. It already deals with the issues of dynamic linking, runtime relocation, etc, and it provides consistent debugging structures.

There exists already a plethora of tools for dealing with the format, and thanks to the way Linux uses ELF, there's plenty of Linux and GNU code to crib from assuming you're not after selling this loader in the end.

While mdws' (straylight's?) OTDL was a good idea back before ELF, noone should be considering it these days. I believe (although I may be wrong) that even mdw has said that ELF is more sensible than OTDL.

Kinnison on 30/9/03 12:00AM [ Reply | Permalink | Report ]

Pace's 32bit C/C++ tools used to be able to create and process ELF files. I assume Castle's can too.

nunfetishist on 30/9/03 12:02AM [ Reply | Permalink | Report ]

ELF on RISC OS would be superb. I'd suggest looking at the BSD ELF-loading code, though, rather than Linux's (it's considerably easier to read). /usr/src/libexec/rtld-elf on your friendly FreeBSD system (I assume it's somewhere similar on NetBSD).

mckinlay on 30/9/03 11:44AM [ Reply | Permalink | Report ]

What would be even better would be for someone to do some work on this, rather than everybody saying how they think it should be done ;-)

-- Peter, drobe.co.uk

mrchocky on 30/9/03 1:05PM [ Reply | Permalink | Report ]

Hmmm... I was under the impression that Shared Libraries was considered 'old fashion'? By all measns have a shared library between functions used by the same program. But lets not have them for use between different programs made by different developers.

Now that computers can handle large amounts of RAM and disc space is no longer a problem, surely there is little need for an extra Shared Library system.

Windows has had lots of trouble with shared libraries. IIRC Microsoft now recommends that programs keep their library files in the same directory as the program and not in the OS folder as it did with 95/98/Me. So there is multiple copies available.

This way if a hard drive corruption kills a Shared Library file then only the program using it dies and not the entire computer as many programs would be using the same library.

One of the problems of having a common place for shared libraries in Windows (I'm only a Linux newbie) was that a user would install an old program with a old Shared library file and the stupid install program would wipe out the new Shared library by mistake. The result, lots of programs would fail or cause random faults.

The User would have no idea which library file had been overwritten or corrupted. Why should they?

Windows now has to do lots of version checking and file protection of important system libraries to try and stop this happening.

Are we going to have to go down the same route in RISC OS?

Just seems to me to be easier for the reliability of the computer not to bother with them...

quatermass on 30/9/03 1:47PM [ Reply | Permalink | Report ]

So, your view of Shared libraries is totally biased by your experience of them on Windows. You can't compare your perceived failings of Windows shared library systems with those of RISC OS, because the orgnaisation would be completely different.

Who said they were "old fashioned"? Please justify this statement.

Your argument about corruption and upgrades is a red herring. The same thing could happen already with RISC OS modules.

As for "realiability", if there's a serious bug in one of the libraries, only one thing has to be upgraded, unlike recompiling everything. The serious bugs in Unixlib in the past which could lock the machine are just this - every program that uses it needs to be recompiled.

You deserve no less than slap for scaremongering :-(

-- Peter, drobe.co.uk

mrchocky on 30/9/03 2:22PM [ Reply | Permalink | Report ]

The benefits of shared libraries are beyond just space saving, though that is a major benefit. As Chocky points out, they provide nice upgrade paths without the need to recompile entire applications.

They are in no way old hat. For bigger libraries, such as X11 GUI toolkits, they are the obvious right choice. I'm not a Windows user, so I have no idea what the state of play is with DLLs over there, but on UNIX they're alive and kicking.

-- Dougal

Dougal on 30/9/03 2:39PM [ Reply | Permalink | Report ]

ELF, eh? It had crossed my mind, but AOF seemed to be mostly adequate, and it seemed that I would have to understand AOF anyway to read the compiler output. I shall investigate ELF in more detail...

jools on 30/9/03 7:01PM [ Reply | Permalink | Report ]

ELF's advantage is that it's designed for dynamic linking from the outset, is well understood, has a broad feature-set and pretty much everything non-Windows uses it. It seems to be the clear choice.

I wonder how tricky it'd be to make a riscos-elf gcc...

nunfetishist on 30/9/03 8:27PM [ Reply | Permalink | Report ]

...gcc has nothing to do with ELF. The assembler, drlink and libfile has to be modified. We look forward to your patches ;-)

-- Peter, drobe.co.uk

mrchocky on 30/9/03 8:50PM [ Reply | Permalink | Report ]

1x Basic ELF loader module: [link]

jmb on 30/9/03 9:09PM [ Reply | Permalink | Report ]

mrchocky: Er, granted it won't support the same syntax syntax, but binutils for arm-*-elf has been around for donkeys years. To get started, you should be able to configure it and gcc just for 'arm-unknown-elf' which will give you a working compiler, assembler and linker - though no knowledge of RISC OS, obviously. The crt init code can be cribbed from NetBSD easily enough, and then it's a case of building a library containing stubs for all of the SWIs using a syntax gas understands. (Isn't there a library containing all the SWI stubs already, that's autogenerated or something - I'm sure I read about it somewhere?)

Granted, you run into issues if you want to use any inline asm, but taking one step at a time would seem the sensible approach.

(If the libc is shared and SWI calls aren't inline, then there's even the possibility of sharing binaries between RISC OS+elf and other arm-*-elf platforms, which would be nice).

mckinlay on 30/9/03 11:39PM [ Reply | Permalink | Report ]

In reply to myself:

Of course, all of this assumes either cross-compiling, or getting binutils itself working on RISC OS. I must confess to not having a clue how difficult the latter is...

mckinlay on 30/9/03 11:42PM [ Reply | Permalink | Report ]

I'm unsure how you think that contradicts what I said. It doesn't. GCC itself never deals with binary formats.

It's not GCC itself, it's the other tools - specifically, the ones I've listed above. I don't really think you have a very good idea of what's involved - I have no idea why and where this mystery library you name needs to be created, of what the point of those SWIs are.

Porting bits of binuntils to replace the programs I named doesn't help you very much. You still need to be compatible with AOF, and the assembler needs to continue to understand the ARM (as in the company) assemhler syntax.

-- Peter, drobe.co.uk

mrchocky on 1/10/03 7:35AM [ Reply | Permalink | Report ]

Finally, you can't share libraries with ARM Linux/NetBSD because the code generated for them doesn't contain checks for chunked stacks - plus if you take code from non-Debian, it will contain half word accesses which won't work on RiscPCs.

-- Peter, drobe.co.uk

mrchocky on 1/10/03 7:37AM [ Reply | Permalink | Report ]

Erm, my point was that you can get away without having to have a toolchain which understands AOF if you have one capable of producing ELF objects, libraries and executables and the OS (or some helper) knows how to execute ELF binaries.

Being compatible with ARM assembly syntax is still a problem in this scenario, obviously, but for many applications that's not going to be a problem.

The library I was referring to was OSlib (I've since re-found it). The point was that if OSlib could be generated and compiled for arm-*-elf, using the gas assembly syntax, then there would be a baseline libc for building RISC OS applications atop of *right away*, without any need for the huge task of porting the existing toolchain to ELF.

[FWIW I *do* have an extremely good idea of what's involved in porting a toolchain to a new OS or binary format, having had to do exactly that in the past.]

mckinlay on 1/10/03 7:44AM [ Reply | Permalink | Report ]

To mrchocky. You can hardly say I'm 'totally biased'. I've used a very wide range of OSes over the last 25 years, including RISC OS. I've seen the mess Users are getting into with the current Toolbox and Clib modules for example.

"Who said they were "old fashioned"? Please justify this statement." Errr. I did.

"Your argument about corruption and upgrades is a red herring. The same thing could happen already with RISC OS modules." You're right, It does happen already.

So what do Users currently do? RISC OS users are expected to take a supplied copy of !System and merge it with the one in !Boot on blind faith. Do these new modules get version checked or md5sum'd to ensure they are newer and intact?

Me thinks too much thought is given to how to make things easier for the Programmer and not enough time given to how the end User is suppose to handle the control of the libraries. We need to spare some time to making it easier for Users.

"You deserve no less than slap for scaremongering". I was making a valid point surely about how the end User would handle this. No one else seems to thinking of that 'end of the stick'.

Cheers. :-)

quatermass on 1/10/03 10:35AM [ Reply | Permalink | Report ]

Quatermass: > "Who said they were "old fashioned"? Please justify this statement." > Errr. I did.

And in what way are you qualified to say that?

On the corruption front, I have several Unix boxes here that use shared libraries *extensively*, and have been working flawlessly, in some case for years. I can't remember the last time a file on disc got corrupted that wasn't directly my fault, or accidental. Of course, the file systems on Unix tends to be a whole lot more reliable than RISC OS' ones, but that's just another thing that needs to be replaced.

(And yeah, I know that somebody could go poking around in the shared libraries out of curiosity, and break things, but then that's no different from poking around inside the box with a pin to see what sparks - you get what you deserve.)

nunfetishist on 1/10/03 11:00AM [ Reply | Permalink | Report ]

Quartermass:

"I did" isn't a justification

"...how the end User is suppose to handle the control of the libraries." - Well, ideally they shouldn't have to control them. Ideally they shouldn't have to care at all.

I think one of the major problems of shared libraries, to which you refer, is the naming of the things with repect to different versions. I have no idea how Windows handles this, but I suspect badly, In UNIX like things, such as Linux, the library file name is appended with the version number, which makes life easier. In Mac OS X the framework system provides the name and version from insider the framework, so the filename doesn't matter - frameworks (the Mac OS X shared library packages) register a name, major version, minor version with the OS when installed - what the file name is doesn't matter. When an application wants a framework it gives the OS the name and the major version it wants (possibly also the minor version, but minor versions are meant to be interface compatible).

At the end of the day, Windows demonstrated that shared libraries without proper thought to how they're named (by name I mean the more computing science point of view, rather than just the filename). UNIX libraries and Mac OS X frameworks demonstrate it can be done. Just because you've not experienced it done right doesn't mean it can't be.

Shared libraries are more than an aid to the programmer, they're an aid to the user - it requires less memory, it allows applications to be upgraded by just upgrading the appropriate library, reducing file sizes of transfer, it allows the system provider to ship a bunch of libraries and application programmers to rely on them.

-- Dougal

Dougal on 1/10/03 11:19AM [ Reply | Permalink | Report ]

quatermass> "So what do Users currently do? RISC OS users are expected to take a supplied copy of !System and merge it with the one in !Boot on blind faith. Do these new modules get version checked or md5sum'd to ensure they are newer and intact?"

Yes, they get version checked, that's exactly what the SysMerge tool is designed to do. If users are getting in a mess with toolbox and sharedclib releases then that's a (hopefully temporary) political problem with 2 companies developing in parallel, not a technical problem.

illudium on 1/10/03 11:38AM [ Reply | Permalink | Report ]

quatermass: Three people with different OS backgrounds gave you the same answer. I don't think there's anything for me to add.

Mo: Erm all you want, but you haven't adressed the issues - we already _have_ a toolchain that understands AOF - getting away without one makes no sense. I've already pointed out the exact changes that need to be done for using ELF on RISC OS (static linking at any rate) - you've not addressed these points at all.

I don't see what the relevance of OSLib is at all - C programs are no used without a *C Library* - i.e. UnixLib or SharedCLib, not a mere *C* Library, which is what OSLib is.

You may well have experience with porting toolchains, but you don't seem to have much experience with the existing RISC OS GCCSDK.

-- Peter, drobe.co.uk

mrchocky on 1/10/03 4:39PM [ Reply | Permalink | Report ]

mrchocky: Where's the technical sense in having a toolchain which mixes and matches AOF and ELF? ELF isn't just an executable format, it's an object file format, too. On systems which support both a.out and ELF, you don't expect the same toolchain to support both; RISC OS has no reason to be any different.

Would you care to explain the difference between "*C Library*" and "*C* Library"? I'm using the term in the traditional sense - a small layer which separates the OS system calls (which, in the case of RISC OS, are the SWIs), from the applications. Any other utility libraries are be built on top of those. A libc is a starting point - the most basic layer of abstraction. UnixLib and SharedCLib work at the layer above, don't they - they provide additional functionality above that made available by the OS itself, and as such they would lie above the libc.

There's a very good reason why systems which support shared libcs do so - it allows a very small layer of abstraction to be introduced, with very little sacrifice - a layer which allows the semantics of the underlying system to change without breaking everything built on top of it.

mckinlay on 1/10/03 5:23PM [ Reply | Permalink | Report ]

mrchocky: Oh, and one last thing - I DID address the issue. nunfetishist's original post posed the idea of an ELF toolchain for RISC OS. You suggested modifying all the existing RISC OS tools to support ELF (in addition to AOF), whereas I suggested it might be easier just to use the ELF-producing gas, objdump, objcopy, ld, nm, ar and ranlib which are part of binutils *already* - the effort required getting a RISC OS-oriented runtime library working with the existing GNU tools being considerably less than the effort required to make the GCCSDK talk ELF.

mckinlay on 1/10/03 5:29PM [ Reply | Permalink | Report ]

Where's the technical sense in not? RISC OS has a vast array of stuff that's already AOF. Contrary to your final claim, adding ELF support to GCCSDK is not particularly hard, and if the extra binutils later work on newly produced ELFs, that's great, but not particularl relevant.

On the other hand, creating a brand new toolchain for RISC OS makes little sense - you have to modify GCC to produce sensible code for chunked stacks (non trivial), and figure out what you want to do with the resulting ELF binary in terms of loading it, or converting to Absolute, as well as dealing with the masses of minor RISC OS details such as dealing with paths, etc, etc.

And after all that, you have two toolchains for RISC OS which won't interoperate - certain to cause frustration - sounds like a pretty pointless exercise.

I'm really not sure where you're going with the whole C library thing. A compiler for RISC OS _must_ have a C library that implements the standard C functions - only Unixlib and SCL fill this role. OSLIb is neither here nor there, regardless of whether UL/SCL call SWIs or not.

It would be nice if you understood the details of GCCSDK before making any further judgements about what should and should not be done.

-- Peter, drobe.co.uk

mrchocky on 1/10/03 6:00PM [ Reply | Permalink | Report ]

I see. You've turned a potential suggestion into "making judgements about what should and should not be done", and completely failed to grasp the concept of a shared C library as exists on most other operating systems.

Tell you what, though, I'll spend a couple of days fiddling with the de-facto standard toolchain (outside of RISC OS), producing the standard format binaries (outside of RISC OS) with a view to them being useful for producing libraries and executables useable on RISC OS, and see what happens.

I'm at no point saying my approach is what SHOULD be done, I'm saying it COULD be done, and COULD be a better option. Don't be so unnecessarily defensive when the aim is to make it possible for folk to use their existing (and considered standard) toolchains to produce applications for RISC OS.

mckinlay on 1/10/03 6:09PM [ Reply | Permalink | Report ]

Interesting conclusion given that none of my above commentary was about shared libraies, but rather about the specifics of toolchains that don't particulary go near that issue. On the other hand, my above article _did_ clearly talk about concept of shared libraries, so it seems I do understand it.

If you want to throw a tantrum, choose an alternate forum. Please restrain yourself to addressing the technical and practical issues.

But if you _do_ want to help, then please do. Carry out your suggestion by all means - I think the information gleaned will be very useful in understanding the issues, but, for reasons already explained, it is unlikely to be a useful practical proposition.

-- Peter, drobe.co.uk

mrchocky on 1/10/03 6:19PM [ Reply | Permalink | Report ]

Here's any easy one:

What's ELF and AOF? And should I care?

-- Spriteman

Spriteman on 02/10/03 09:07AM [ Reply | Permalink | Report ]

They're binary formats, which describe how an executable file is constructed from various subcomponents (like object files), and how symbols are referenced, and how libraries are linked in, and so on.

As a user you should never really need to care. Most of the time as a programmer you don't need to care either. But, as has been the point of this discussion, not all binary formats are born equal, and some make it easier to do things that others don't. To be honest, it's been a long while since I read up on ELF, but it's nice and clean to understand (as is the Windows PE format actually), and I dare say there are fantastic technical reasons to use it over whatever RISC OS has at the moment given the advocacy in this thread, but I'm not the person to explain that (being RISC OS ignorant

Dougal on 02/10/03 10:34AM [ Reply | Permalink | Report ]

Shared libraries are the bane of Linux for users. Trying to load any new software results in the discovery that it is usually dependent on 20 other items of software that have to be found and downloaded and many of these will be found to have their own unsatisfied dependencies. It is a nightmare. I was told that Debian solved this problem automatically with its loaders but using it I find that it does so only for the Debian distribution of applications. Thus, it is not surprising, that most ordinary users will download a completely new distribution of Linux operating system and applications rather than face the task of updating an old one. RISC OS has had a happily stable operating system in recent times. The great advantage of this is that new software nearly always loads and runs first time because everthing required is entirely in the new binary. Applications are self contained to run on the standard machine. I deprecate the practice of supplying new !System modules with applications because it is going down the Windows/Unix road. There is no reason to save memory. It is abundant. The great thing that RISC OS can give the world is this simplicity for the user. Let programmers compile with any libraries for new features but keep the basic operating system relatively stable, please. - Edward

emf on 02/10/03 5:16PM [ Reply | Permalink | Report ]

Edward:

I agree that some of your points have merit. Yes, there is sometimes a problem with matching library versions under Linux, but in my experience (and I do extensive Linux development) this is very rare in recent times. This is perhaps partly because I use almost nothing that isn't found in Debian's 11000+ packages. You should also consider that any shared library system I unleash upon RO users I would ensure was cohesive, and as free from these issues as possible.

With reference to memory - your point is partially valid - it's somewhat rare to use vast amounts of memory with RISC OS programs. _But_ if you look at the increasing number of Unix ports, memory usage is often much greater - the case for memory saving becomes stronger.

Finally, it depends what you mean by "the basic operating system". There is again a very strong case - one I highlighted earlier, for stability/feature improvements in the C libraries and other somewhat core features. I'm firstly refereing to the SharedCLibrary and Toolbox updates which can often fix important things, but also of course to Unixlib, which remains a rapidly developing library - even if it was just for Unixlib alone to be shared in this way, we would have a substantial argument for such a system.

It's true that the gains from many auxillary libraries being non-statically loaded might be pretty small if we consider a given versions of a program in isolation. But there's one more issue at stake - the OS equivalent of keeping up with the Jonses, particularly when it comes larger programs and libraries that are rapidly developed by non-RISC OS users - there are merits here too for shared library systems.

mrchocky on 02/10/03 5:44PM [ Reply | Permalink | Report ]

Shared libraries could also give speed improvements. For example, the main overhead of running a simple Perl script is loading the interpreter binary from disc, but if most of the interpreter was implemented as a shared library then the library could be cached in memory after the first load and then subseqent loads would be a lot faster.

anon/193.131.176.54 on 03/10/03 09:27AM [ Reply | Permalink | Report ]

Peter

This seems to be more of a philosphical question than anything. Unfortunately, I used the word stable when I meant standardised. I admit that there is no particular rule as to what constitutes part of the operating system and what could be more appropriate for the application. That is really arbitrary. However, the crux of the matter is whether a Linux type approach should be adopted based on incrementally updating the Operating System modules and libraries where there never is a baseline platform for applications or we stick to regular OS updates such as RISC OS 6.0, etc. where each application can state its compatibility to each OS version. This is simple. The incremental Linux approach is complex and the reason why there are several competing methods of handling the loading of applications and in my opinion none totally successfully. I think that RISC OS should stick to the simplest methods where possible, which ordinary users can understand. I could imagine that a regularly standardised Linux OS with application directories could be more user friendly and straight forward too. Regarding Perl, maybe the fault is in the application which exits after running the first script?

Edward

emf on 03/10/03 2:32PM [ Reply | Permalink | Report ]

But it's not philosophical at all :-)

it's an entirely practical problem, both for reasons I've already laid out, and for some you have too.

The distribution and bundling of shared libraries is an important issue, but not to be confused with the excellent reasons for, and the mechanics of, a given shared library system.

As for Perl - you're suggested it should stay resident in memory all the time; perhaps like Basic? In other words, you're suggesting Perl becomes a shared library - good idea :-)

mrchocky on 04/10/03 10:36AM [ Reply | Permalink | Report ]

So, can anyone suggest how I should go about linking shared libraries to actual executables? (This is the reason why I haven't really progressed since the original announcement.)

One idea is to get a static linker to insert code and data to be executed before main() to cause the libraries to be loaded, analogous to (or augmenting) the SharedCLib stubs. How difficult would this be? It would need to insert a symbol table and relocation directives into the executable, so that the libraries and the main application could refer to each other by name.

Another is to have some sort of AOF loader (okay, maybe an ELF one later, but I've got AOF ready now). It would probably have to be a module, one that was OS_Module-2 entered. Would it be able to make use of the C env provided by SharedCLib without clashing with its own intentions for application space?

Any more concrete ideas?

Cheers!

jools on 05/10/03 6:32PM [ Reply | Permalink | Report ]

You could modify Unixlib or GCC's stubs if you need anything run before main().

mrchocky on 05/10/03 6:52PM [ Reply | Permalink | Report ]

A-ha, I see a call to main() in unixlib/source/unix/unix.c in the old gccsdk I've been using. Is that the right place?

Will drlink -aof incorporate any static libraries, so I can easily determine all the provided and required symbols in a single format I'm already familiar with? I guess I'll try it anyway...

Cheers again.

jools on 05/10/03 8:16PM [ Reply | Permalink | Report ]

Anyone still reading this?

Well, I think I've done it.

jools on 09/12/03 00:00AM [ Reply | Permalink | Report ]

<Applause!>

anon/81.131.208.22 on 09/12/03 01:45AM [ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Create a new account
Forgot your password?

Search this website

This week's poll

Recent developments have left me feeling...

Assured ROS will appear on new hardware		55%
Pleased OS desktop features are being developed		10%
ROL and ROOL will eventually kiss and make up		5%
App developments are critical		10%
Dave Holden sleeps easy at night		19%

Discuss this | Archives