Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Software news

By Chris Williams. Published: 24th Nov 2005, 08:22:41 | Permalink | Printable

Shared libraries in GCC, new freeware and updated software

News in briefElectronic engineers and hobbyists are invited to test drive a new design package called SchemEd. The circuit drafting application has been developed by Howard Dawson and is still in development.

An experimental version of GCC that supports dynamic linking is available now from Lee Noar's website. Lee's work allows the C/C++ compiler package to create software that loads support libraries dynamically, rather than building them into one complete executable. This means if, for example, an application is built with a library that supports https website connections and this library is updated, the user can dynamically load the replacement version rather than having to recompile the whole program or wait for someone else to do it. There are other benefits including the fact that it uses the ELF file format, as found on other platforms.

Chat application Grapevine development could be spurred if users cough up extra cash. R-Comp, who publish the instant messaging software, reportedly told users: "If we assume an upgrade would cost 20ukp, we'll need at least 50 upgrades to cover the time necessary for significant new development. If there is that level of interest, then I am sure R-Comp will be happy to push forward with Grapevine."

Martin Wuethner's AppDock software is now RISC OS Select and Adjust compatible. ArtWorks 2.53 is also available to fix a bug with the Draw file output of blends between CMYK colours and correct incorrect values in the header of exported CMYK TIFF files. Exported Draw files can also optionally have a "_d" added to the filename to prevent the original ArtWorks file from being over-written.

Another bugfix update is ready for Star Fighter 3000 to download and install. Shareware game Mijas Sudoku can now solve and generate Sudoku puzzles. Steve Potts has recompiled his software with RISCOS Ltd.'s StubsG library and updated his list of MassFS device definitions to support more USB gadgets. Bringing back memories of RISC OS 2, Jon Welch has bought a second hand StrongARM RiscPC and restored his Xtree software. Updated utility WaitUntil can pause Obey scripts files until a particular event, such as a system variable change, occurs. Mike Sandells has created two new tools: SprSplit, which turns a multi-sprite spritefile into a directory of individual images, and PalChange, which replaces all the 16 colour palettes in a multi-sprite spritefile with one specific palette.

A new application to create HTML based photo galleries online has been developed by Robert Hampton. He's also written KwikZip, which is a front end to the zip archive support in RISC OS Select. RiscLua 3.3 has been updated, as has bug fixed utility HelpScan.

And finally
The organisers of the South West Show are willing to offer 'enthusiast' developers a special discount rate to exhibit at the event in February. It sounds like an interesting deal, and hopefully not too many programmers contacted by John Stonier at the start of the week noticed that the highly personalised email started with "Hi *".

The more astute of you will have found by now the recently created Iyonix Ltd which shares the same address as Castle and two of the Iyonix manufacturer's directors.

Links

News? Comments?

Previous: Could A9 be a digital oasis in a desert of PCs and Macs?
Next: Companies flock to Christmas road show

Discussion

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

WRT the GCC thingy: Now, as i understand it, when I compile an SDL program it compiles all the necesary stuff into the resulting binary, this creates issues with the LGPL if i wish to distribute an SDL program for a fee, so by using this i keep the actual SDL gubbins seperate and distributing my binary for a fee is no-longer an issue with the LGPL? as long as i relese the gubbins seperate from my program binary with the appropriate licence text files? is there likley to be any loss in performance running libraries not compiled into the program?

 is a RISC OS Usernex on 24/11/05 10:49AM
[ Reply | Permalink | Report ]

nex:

Distributing a program for a fee or not has no bearing on LGPL compliance.

When linking against LGPL code (and distributing the result) you must:

a) Provide the source code for any changes you made to the LGPLed code (i.e any code in SDL, in this case)

and

b) Provide a mechanism by which the end-user can replace the LGPLed component.

In the case of static linking, this means that you (as a minimum) need to provide the compiled intermediate object files such that they can be linked against another version of the LGPLed component.

Dynamic linking does not change the requirements placed on you by the LGPL. However, as the linking step occurs at run-time (rather than at compile time), there should be no need to provide intermediate object files.

As for the performance aspect, there should be little impact on the program. The first call to each library function may be slightly slower; subsequent calls should have no overhead.

 is a RISC OS Userjmb on 24/11/05 11:17AM
[ Reply | Permalink | Report ]

RISC OS now seems to have a profusion of Web Album creators (or at least, I can think of four: AlbumWWW, ThumbCat, Pic_Index and WebWonder - are there any others?) Perhaps drobe could run a comparative review? I'd certainly be interested.

I'm also intrigued by the "Iyonix Ltd" move. Perhaps someone with more business knowledge than me could explain why you might want to do something like this?

 is a RISC OS Userflypig on 24/11/05 11:25AM
[ Reply | Permalink | Report ]

WRT the GCC item above, I'll have to admit to being a little puzzled as to why we've always had to do a linking step. Is ths specific to RISCOS or to C/C++? (You'll probably guess from that that I don't program in C.)

The system I work on (VME) uses a dynamic loader. When any module is loaded, the very first thing it does, before it even starts executing, is to dynamically cascade load everything it (thinks it) is going to need. And everything each of those items need. It's all very efficient especially during development.

 is a RISC OS UserDS1 on 24/11/05 11:35AM
[ Reply | Permalink | Report ]

flypig - Webgen2

 is a RISC OS UserDS1 on 24/11/05 11:35AM
[ Reply | Permalink | Report ]

DS1:

Ah yes, another one to add to the list (apologies for missing it off!).

Personally I've only used ThumbCat, but now I'm thinking I should have dug around a bit and seen what the others had to offer as well.

 is a RISC OS Userflypig on 24/11/05 11:53AM
[ Reply | Permalink | Report ]

DS1:

And how does each module on your VME system know what external modules it needs?

As a close approximation, the linking step performed when compiling C/C++ collates all the intermediate object files into a single binary along with library information.

In the case of static linking the required components of each library are included in the final binary.

Under a dynamic linking scheme, references to the required libraries are stored in the binary. These are then processed by a dynamic linker at runtime which then loads the required libraries for the application.

As for why binaries on RISC OS have traditionally been statically linked, this is generally due to a lack of tools and the need to hack around with AIF. That's not to say that noone's tried to perform dynamic linking on RISC OS before; those solutions seem not to have gained widespread support.

The difference with this new solution is that it goes hand-in-hand with the GCCSDK developers' intent to move entirely to producing ELF binaries with future releases (I believe there's still an intention to do one final AOF release). Therefore, dynamically loaded libraries will essentially come "for free" with no extra effort required on the part of software developers.

 is a RISC OS Userjmb on 24/11/05 12:05PM
[ Reply | Permalink | Report ]

jmb - there's an 'external reference' for each called module. The loader simply loads all those external references, and then repeatedly finds the external references in those modules and loads those in turn. It's called a cascade load.

Basically it sounds the same as what will be happening in the new GCC.

 is a RISC OS UserDS1 on 24/11/05 12:23PM
[ Reply | Permalink | Report ]

flypig - No worries. I didn't know about webwonder.

I've got a load of changes I want to make to webgen2. Maybe this will prompt me into starting work on them!

 is a RISC OS UserDS1 on 24/11/05 12:24PM
[ Reply | Permalink | Report ]

DS1: you've not really answered jmb's partially rhetorical question. The linking step is required to ensure that all the symbols exist prior to running. And even when dynamic linking, it's usually the case that some of the code is statically linked - even if that's just to provide a valid header or call the loader (the name of the runtime linker under binutils).

Only in languages like Java, where a lot more typing information is available and linking occurs as late as possible can a compile time linking step be avoided.

As for this version of GCC, Lee's made available several versions of this over the last year, so it's hardly news. The hard part is fully testing it and integrating into the mainstream GCCSDK work.

 is a RISC OS Usermrchocky on 24/11/05 3:46PM
[ Reply | Permalink | Report ]

mrchocky - yeah sorry, I suppose I wasn't very clear. When any piece of code is compiled to an OMF, there is a special area in the code that maintains all the external references. In a very small number of cases it may be necessary for called modules to be on the loading environment when compiling a calling module. In general though, all modules can be compiled completely independently and in complete isolation and they'll all just load and run (normal bugs not withstanding) when the top level module is called at run time.

I suppose what I was really trying to work out was how what I know and understand matches what's coming, and to a lesser extent try and understand why C on RISCOS requires a linking process when C on VME doesn't. (I don't actually use C at all, but I do know that on VME it works the same way as all other languages on VME)

 is a RISC OS UserDS1 on 24/11/05 4:20PM
[ Reply | Permalink | Report ]

What would the "significant" development of Grapevine entail ? I think it would need to handle video and audio as all others do these days.

 is a RISC OS Usermripley on 24/11/05 4:41PM
[ Reply | Permalink | Report ]

DS1:

Under a system that supports dynamic linking, the "special area in the code that maintains all the external references" is exactly what the static linker creates. These references are then resolved at runtime by the dynamic linker (by loading the appropriate libraries).

Previously, RISC OS has not had this facility. Therefore, the output of the static linker was a static binary which had no external dependencies.

I'm not aware of any system under which C does not have a linking process. At the very least, it's needed to output the binary in a format the system can load. In most cases, this linker step is carried out automatically (as it is under C compilers on RISC OS).

 is a RISC OS Userjmb on 24/11/05 4:52PM
[ Reply | Permalink | Report ]

C on _all_ systems requires a linking process; although it might not be immediately obvious, or called by that name. But since you say you don't use C yourself; speculation is causing much of your confusion. I know it's not intentional, but users making assertions about systems they do not understand is a constant headache for RO developers.

There is one exception; it may be that the assembler can directly generate a binary from a C source file which contains no external references; but this case is rarely useful, and would not strictly be a C program, since it would not contain a main (or if it did, you would have to point the start symbol at it).

 is a RISC OS Usermrchocky on 24/11/05 6:00PM
[ Reply | Permalink | Report ]

Any program that consists of more than one source module must be linked. It is fundamentally impossible to exclude this step unlees the program consists of a single source module with no external references. Many C++ programmers will arrange to have a separate C++ and header file for each class, which will result in the compiler generating a separate object file for each class.. A linking process is therefore necessary to combine these object files into a functional program, irrespective of any external library references (which will normally be required if the program is to do anything useful), and irrespective of whether static or dynamic linking is used for the libraries.

 is a RISC OS Usermrtd on 25/11/05 9:17AM
[ Reply | Permalink | Report ]

SchemEd was the long awaited software for me!

Big thank to Howard Dawson, that he begun to write SchemEd. Looks allready very good to me, even it is alpha. No errors found yet.

Now i finally could move from Atari-ST to Riscos for drawing my electronic-circuits.

 is a RISC OS Usercrow on 25/11/05 10:52AM
[ Reply | Permalink | Report ]

On the subject of sudoku, you'll find my attempt at [link]

It will solve and create puzzles and the C source is provided for your amusement.

 is a RISC OS Userjeffd on 25/11/05 10:57AM
[ Reply | Permalink | Report ]

mripley: "What would the "significant" development of Grapevine entail ?"

Hopefully fixing the onorthodox user interface, redesigning the icons, having a chat face in MSN, etc... Most important, fixing those little annoying bugs here and there which, by the way, were in there since I bought a copy. That was more than 2 years ago and was version 2.00. Current version is 2.04... so development seems slow.

"I think it would need to handle video and audio as all others do these days."

I'm not sure if RiscPC's could handle real-time audio transmission, video is probably out of the question. Perhaps the Iyonix could handle video. Besides I'm not sure if there is sufficient support in RISC OS itself for that...

I just wish somebody would port GAIM and the platform would have a decent multi-protocol chat client, which has become a necessity on all platforms nowadays. Anyway, I am happy to pay some money, if R-Comp would outline the new functionality planned and it is worth it for me.

 is a RISC OS UserhEgelia on 25/11/05 1:03PM
[ Reply | Permalink | Report ]

hEgalia, you have still not sent me his updated icons that I requested when this came up on Iconbar.com. If users don't provide feedback, it is no wonder that the things they want don't happen! All the enhancements from 2.00 onwards have come from users making requests. I will remind you that there are less than 100 users interested in instant-messaging on RISC OS, which is about enough to pay for 2-3 months of programmer time tops. I have supported GV for all this time because of my own interest in the technology, as a way of keeping in touch with overseas customers.

If/when we do GV3, it will probably involve moving to the latest MSN protocol versions which are necessary for Nudge, user pictures, and so on. We'd also probably implement another protocol, and adjust the UI to make it easier to deal with multiple protocols. But it would need to sell more than 10 copies :<

 is a RISC OS Userarawnsley on 25/11/05 2:23PM
[ Reply | Permalink | Report ]

arawnsley: What are you talking about?! Hey, I am not aware of anything you 'requested' from me! I did download an emoticon set from the GAIM site, because they are far better. In fact, the standard Grapevine emoticons are awful, especially for a commercial offering. Another GV user liked them, so I decided to offer them to GV's programmer. He said he had probably forwarded them to R-Comp, so I guess you should have them by now. You have my e-mail address, you could have simply asked for them. Please be more careful next time.

Several users, including me, have provided lots of feedback on the GV mailing list! AFAIK the reason "things don't happen" is because, according to the author, he does multiple projects and need to share his time between them. As I understood it, in the end things are up to R-Comp. But several users have repeatedly given feedback, please don't say otherwise!

 is a RISC OS UserhEgelia on 25/11/05 3:23PM
[ Reply | Permalink | Report ]

arawnsley: "I will remind you that there are less than 100 users interested in instant-messaging on RISC OS, which is about enough to pay for 2-3 months of programmer time tops."

Well, I guess there probably are far more users interested in instant-messaging on RISC OS, but maybe not more than a 100 of them are interested in Grapevine as it is.

"I have supported GV for all this time because of my own interest in the technology, as a way of keeping in touch with overseas customers."

That's nice, but I would hope you also supported it for all this time because of us, the purchasers of the program?

"If/when we do GV3, it will probably involve moving to the latest MSN protocol versions which are necessary for Nudge, user pictures, and so on. We'd also probably implement another protocol, and adjust the UI to make it easier to deal with multiple protocols. But it would need to sell more than 10 copies :<"

Yes, I understand. Well, that sounds really good to me! So I hope you'll sell a lot more than 10 copies! I believe Grapevine itself is a good program (apart from the little bugs here and there), only its presentation and User Interface is, IMHO, not terribly attractive to say the least. When/If you change that and add the functionality you mentioned, I'd be happy to support the initiative.

 is a RISC OS UserhEgelia on 25/11/05 3:40PM
[ Reply | Permalink | Report ]

hEgelia, I have Grapevine 2 but this is the first I have heard of a Grapevine mailing list. How does one join?

 is a RISC OS Usersa110 on 25/11/05 4:06PM
[ Reply | Permalink | Report ]

To hEgelia: "I just wish somebody would port GAIM and the platform would have a decent multi-protocol chat client, which has become a necessity on all platforms nowadays."

It looks like a nice project for someone willing to spend sometime with GCCSDK Autobuilder. I think most, if not all, libraries have been built before with autobuilder so cross-compiling GAIM look reasonable feasible to me. Any volunteers ?

 is a RISC OS Userjoty on 25/11/05 5:05PM
[ Reply | Permalink | Report ]

For the record, the GV mailing list is not an R-Comp thing, and is intended as a self help group. If you want to ensure we see your feedback, please email direct. The GV programmer does try and read the mailing list, which is obviously helpful, but it is recommended to route feature requests here.

As I said on iconbar.com, 2.06 should be ready before Christmas as a free update. It addresses several points raised by customers with us (eg. slow IRC logon, MIRC colour codes, a couple of ICQ issues and more). It will also sort out a problem with MSN sessions timing out if users don't reply. We are also looking into the issue of emoticons.

 is a RISC OS Userarawnsley on 25/11/05 5:12PM
[ Reply | Permalink | Report ]

sa110: "I have Grapevine 2 but this is the first I have heard of a Grapevine mailing list. How does one join?"

It is an unofficial list, but AFAIK the author always replies to questions or suggestions, so it is quite helpful. Check out:

[link]

joty: That's very interesting to hear. I'll keep my fingers crossed. Most people I know use GAIM or Trillian. It would be terrific to have GAIM run natively on RISC OS.

arawnsley: Thanks for pointing that out. I checked the Iconbar report and I did see your comment below, so now I know what you to referred earlier. GV 2.06 would be a very nice Christmas gift :) Perhaps R-Comp can send all current GV customers an e-mail to ask if they are willing to invest in a GV3? It would be helpful if you'd add a list of planned new features for that release.

 is a RISC OS UserhEgelia on 25/11/05 6:00PM
[ Reply | Permalink | Report ]

On the Mac there is a message client called Adium, which uses the Gaim libraries. Is there any way this could be done for RISC OS?

Could GV3 do this, or is it outside the scope of the licence?

 is a RISC OS Userjess on 26/11/05 9:13AM
[ Reply | Permalink | Report ]

The title says Shared Libraries yet the various messages talk about dynamically loaded code. Shared to me means that the code can be shared between executable. Are we talking about true shared libraries or just dynamic loaded code.

 is a RISC OS UserJwoody on 26/11/05 10:06AM
[ Reply | Permalink | Report ]

JWoody:

The former. The libraries get loaded into the RMA (on 32bit machines, this will probably be changed to use a dynamic area, locked down to be read-only) and their code is shared between all clients. Each client gets its own copy of the data area for the library (this is copied into the client's WimpSlot by the runtime loader).

 is a RISC OS Userjmb on 26/11/05 10:42AM
[ Reply | Permalink | Report ]

"Chat application Grapevine development could be spurred if users cough up extra cash"

GV2 does all what I want it to do, apart from dropping the connection too frequently. However, I would be happy to pay for an upgrade. Don't know if this is possible but one thing I would like is to be able to add to, or change the "status" texts. At moment I "go to lunch" several times a day:) Another function I use at work is whiteboard sharing. Could this be done via Paint?

 is a RISC OS UserJohnR on 28/11/05 2:44PM
[ Reply | Permalink | Report ]

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

Search the archives

Today's featured article

  • How to upgrade an A9home's hard disc
    Don't try this at home
     9 comments, latest by ROHC on 30/10/06 10:18PM. Published: 29 Oct 2006

  • Random article

  • BASIC V guide reprint touted
    Classic book returns [Updated]
     11 comments, latest by flypig on 15/2/05 6:38PM. Published: 12 Feb 2005

  • Useful links

    News and media:
    IconbarMyRISCOSArcSiteRISCOScodeANSC.S.A.AnnounceArchiveQercusRiscWorldDrag'n'DropGAG-News

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    Dealers:
    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster

    Usergroups:
    WROCCRONENKACCIRUGSASAUGROUGOLRONWUGMUGWAUGGAGRISCOS.be

    Useful:
    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign


    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "No comment. No comment. I said, no comment!"
    Page generated in 0.1005 seconds.