DeskLib and GCCSDK

[Steve Fryatt]

I've been attempting to build a version of the current DeskLib for use in
the GCCSDK, based on the sources at https://www.riscos.info/websvn/

A minor syntactical tweak to Makefile.unix notwithstanding, it seems to do
the right kinds of things, and

make -f Makefile.unix SCL=true install

puts the expected files into ~/gccsdk/env/...

If I then try to use it to compile an application (in this case WinEd from
the same source as above), then again it seems to do the correct sorts of
thing (except that WinEd's Makefile requires a lot of modification to make
it happy with the GCCSDK), but the process soon hits several problems.

The first, which I would like to sort out before moving on to the rest, is
that the DeskLib headers installed by the process above contain several

#include "DeskLib:Core.h"

lines and similar, which GCCSDK can't sensibly resolve. I can make things
build to a point where I'm looking at a handful of genuine-looking missing
or conflicting source files in WinEd by doing a search and replace to remove
the <DeskLib$Path> references from within ~/gccsdk/env/include/DeskLib/, but
this seems sub-optimal. Not least because the DeskLib docs refer to the
library being prepped for use in the GCCSDK, which suggests that this should
"just work". :-)

Is there some way to make GCCSDK happy with the files as they stand,
"DeskLib:Core.h" and the like included?

Also, where's the best place to ask about DeskLib nowadays. The last SVN
commit was 2012, and the Google Group that the documentation recommends for
support doesn't exist. Is anyone maintaining it?

--
Steve Fryatt

st...@stevefryatt.org.uk
http://www.stevefryatt.org.uk/

[Theo]

Steve Fryatt <st...@stevefryatt.org.uk> wrote:
> The first, which I would like to sort out before moving on to the rest, is
> that the DeskLib headers installed by the process above contain several
>
> #include "DeskLib:Core.h"
>
> lines and similar, which GCCSDK can't sensibly resolve. I can make things
> build to a point where I'm looking at a handful of genuine-looking missing
> or conflicting source files in WinEd by doing a search and replace to remove
> the <DeskLib$Path> references from within ~/gccsdk/env/include/DeskLib/, but
> this seems sub-optimal. Not least because the DeskLib docs refer to the
> library being prepped for use in the GCCSDK, which suggests that this should
> "just work". :-)
>
> Is there some way to make GCCSDK happy with the files as they stand,
> "DeskLib:Core.h" and the like included?
>
> Also, where's the best place to ask about DeskLib nowadays. The last SVN
> commit was 2012, and the Google Group that the documentation recommends for
> support doesn't exist. Is anyone maintaining it?

I don't think anyone is maintaining it. I think the GCCSDK mailing list is
probably the place to ask, as there are at least some people with commit
access to the repo.

On pathnames, I have a feeling this has come up before but noone has
addressed it - Google is not being my friend today.

I think the canonical would be #include "DeskLib/Core.h" which should work
in GCC as a cross compiler and natively if you are supplying the right
-I flag. I think a recent version of the DDE should also handle that.

When cross-compiling, looking at the source:
https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Fcommon%2Friscosify.c
https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Fcommon%2Funixify.c
I think #include "DeskLib:/Core.h"
would look for the file in /DeskLib:/Core.h
so if /DeskLib: were to be a symlink to the right place it might work.
I'm not familiar with the GCC internals as to whether it does anything
beyond this, maybe it does.

I think asking on the list would be an idea since someone might know, but
otherwise you could submit a patch?

Theo

[Steve Fryatt]

On 12 May, Theo wrote in message
<8En*Qm...@news.chiark.greenend.org.uk>:

> On pathnames, I have a feeling this has come up before but noone has
> addressed it - Google is not being my friend today.

I thought similar, but almost a day on Google (on and off) found me nothing.

> I think the canonical would be #include "DeskLib/Core.h" which should work
> in GCC as a cross compiler and natively if you are supplying the right -I
> flag. I think a recent version of the DDE should also handle that.
>
> When cross-compiling, looking at the source:
>
https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Fcommon%2Friscosify.c
>
https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Fcommon%2Funixify.c
> I think #include "DeskLib:/Core.h" would look for the file in
> /DeskLib:/Core.h so if /DeskLib: were to be a symlink to the right place
> it might work. I'm not familiar with the GCC internals as to whether it
> does anything beyond this, maybe it does.

Aha. Thanks; I'll have a play at some point.

The other option which had occurred to me, given that the library builds
fine but then causes apps which try to include it to choke, was that the
install process for GCCSDK could do some suitable search and replace of the
various header files.

The problem is that as a non-desklib user, I've no real idea what "correct
behaviour" is...

> I think asking on the list would be an idea since someone might know, but
> otherwise you could submit a patch?

That was somewhere on the plan, if I could decide what the correct thing was
to do.

I may as well admit that the aim of this was to get to a position where I
could try and identify some of the more interesting crashiness of WinEd on
modern hardware, and submit some fixes.

:-)

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

[Theo]

Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> On 12 May, Theo wrote in message
> <8En*Qm...@news.chiark.greenend.org.uk>:
>
> > On pathnames, I have a feeling this has come up before but noone has
> > addressed it - Google is not being my friend today.
>
> I thought similar, but almost a day on Google (on and off) found me nothing.

I have a vague recollection David Higton might have been involved, perhaps
he can remember?

> > I think #include "DeskLib:/Core.h" would look for the file in
> > /DeskLib:/Core.h so if /DeskLib: were to be a symlink to the right place
> > it might work. I'm not familiar with the GCC internals as to whether it
> > does anything beyond this, maybe it does.
>
> Aha. Thanks; I'll have a play at some point.

(oops, typo - that should be #include "DeskLib:Core.h" in the above
paragraph, in case it was unclear)

> The other option which had occurred to me, given that the library builds
> fine but then causes apps which try to include it to choke, was that the
> install process for GCCSDK could do some suitable search and replace of the
> various header files.
>
> The problem is that as a non-desklib user, I've no real idea what "correct
> behaviour" is...

It would be possible, but compilers should be able to handle the canonical
form without source modification. It's especially important if you don't
know if you're cross compiling or not, and makes a mess of eg checking out a
new copy from a source repo or comparing hashes to see if anything changed.

Picking a random piece of RISC OS source:
https://gitlab.riscosopen.org/RiscOS/Sources/Toolbox/Window/-/blob/master/c/events
that does have
#include "objects/toolbox.h"
which indicates that Norcroft is happy with that syntax.

I think therefore the right thing to do would be to patch the headers to be
in the
#include "DeskLib/Wimp.h"
format, and then Makefiles need -IDeskLib:
and the path structure should be !DeskLib.DeskLib.h.Wimp
and in !Boot you have:
*Set DeskLib$Path <Obey$Dir>.

I don't know if this would break existing Makefiles though, or are they
already broken?

> > I think asking on the list would be an idea since someone might know, but
> > otherwise you could submit a patch?
>
> That was somewhere on the plan, if I could decide what the correct thing was
> to do.

It might be worth having this discussion on the list, in case anyone
disagrees?

> I may as well admit that the aim of this was to get to a position where I
> could try and identify some of the more interesting crashiness of WinEd on
> modern hardware, and submit some fixes.

If you would like commit access to the WinEd repo, do drop me a line...

Theo

[News]

In article <mpro.qa8lq705...@stevefryatt.org.uk>,

Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> I may as well admit that the aim of this was to get to a position
> where I could try and identify some of the more interesting
> crashiness of WinEd on modern hardware, and submit some fixes.

I use WinEd with all the David Pilling software I play with, because
it is all template based. I haven't noticed any problems. I was
editing some of the DPScan templates over the last week or so without
problem.

Can you give an idea of what the problems are - I would find that
useful.

--
Chris Johnson

[Jean-Michel]

In message <8En*Qm...@news.chiark.greenend.org.uk>

Theo <theom...@chiark.greenend.org.uk> wrote:

> Steve Fryatt <st...@stevefryatt.org.uk> wrote:
>> The first, which I would like to sort out before moving on to the rest, is
>> that the DeskLib headers installed by the process above contain several
>>
>> #include "DeskLib:Core.h"
>>
>> lines and similar, which GCCSDK can't sensibly resolve. I can make things
>> build to a point where I'm looking at a handful of genuine-looking missing
>> or conflicting source files in WinEd by doing a search and replace to remove
>> the <DeskLib$Path> references from within ~/gccsdk/env/include/DeskLib/, but
>> this seems sub-optimal. Not least because the DeskLib docs refer to the
>> library being prepped for use in the GCCSDK, which suggests that this should
>> "just work". :-)
>>
>> Is there some way to make GCCSDK happy with the files as they stand,
>> "DeskLib:Core.h" and the like included?
>>
>> Also, where's the best place to ask about DeskLib nowadays. The last SVN
>> commit was 2012, and the Google Group that the documentation recommends for
>> support doesn't exist. Is anyone maintaining it?

> I don't think anyone is maintaining it. I think the GCCSDK mailing list is
> probably the place to ask, as there are at least some people with commit
> access to the repo.

Unless you are only looking for a GCC version only, I think Rick Murray
did it and Desklib is part of RISC OS source code, downloadable from RISC
OS OPEN.

Bonne journée.


--
Jean-Michel

[Steve Fryatt]

On 13 May, Jean-Michel wrote in message
<ab06e16...@jmc.bruck.orange.fr>:

Rick has a hacked around version of an older version, I think. It claims to
be based on a 2004 vintage, which would mean that it misses many of the
changes of the current version in SVN, but then appears to have some
different changes of Rick's own devising.

> Desklib is part of RISC OS source code, downloadable from RISC OS OPEN.

Have you got a link to that?

[Steve Fryatt]

On 12 May, News wrote in message
<586fb42428c...@spamcop.net>:

The GUI is *very* unstable, to the point of being useless, on a Titanium.
For example, load WinEd, and open a new template browser. Click on the
Create Window button in the toolbar, then immediately click on Cancel.

"WinEd may have gone wrong...", which is an abort on data transfer in the
Menu_Show function (which I think is DeskLib).

There are many other examples, which tend to catch me just before I save a
file. These days, I only use it under RISC OS 5 on RPCEmu, where it is
indeed very stable. Given the age of the software, my guess is ARMv7 issues.

This is version 3.20 (September 2008). The latest that I'm aware of is 3.21
(alpha), if you build from source.

[Alan Adams]

In message <586fb42428c...@spamcop.net>

I use it a lot too. The only problem I've ever encountered is on a couple
of occasions it's refused to open a template it previously created. I
don't know whether I still have an example around. If I find one, I'll let
you know.

--
Alan Adams, from Northamptonshire
al...@adamshome.org.uk
http://www.nckc.org.uk/

[Martin]

On 13 May in article <mpro.qa9ji901...@stevefryatt.org.uk>,

I would love to see WinEd made a little more stable, as it is my
favourite template editor. Currently using a Titanium, previously
RPi3 and Iyonix.

Mind you, it only occasionally crashes for me ... and in the Load ->
New -> Create Win -> Cancel scenario it 'only' creates 128 ZeroPain
logs here. menu_Show does seem implicated, when r14 is -1 , and an
LDM from r3 at &14 in steps up to &BEC fails.

But I maybe have the advantage of having v3.22a (Oct 2008) here!
I was feeding back issues and suggestions to Adam before he lost
interest, so it may be worth trying to contact hime if you have not
already tried.

Martin

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

[News]

In article <mpro.qa9ji901...@stevefryatt.org.uk>,

Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> The GUI is *very* unstable, to the point of being useless, on a
> Titanium.

Odd - I do all my development on a Titanium machine. I cannot
remember having problems editing existing template files, although it
is a few years since I created a completely new template file.

I'll take more notice of what is going on.

--
Chris Johnson

[Theo]

Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> On 13 May, Jean-Michel wrote in message
> <ab06e16...@jmc.bruck.orange.fr>:

> > Unless you are only looking for a GCC version only, I think Rick Murray
> > did it

Aha, that was it.

> Rick has a hacked around version of an older version, I think. It claims to
> be based on a 2004 vintage, which would mean that it misses many of the
> changes of the current version in SVN, but then appears to have some
> different changes of Rick's own devising.
>
> > Desklib is part of RISC OS source code, downloadable from RISC OS OPEN.
>
> Have you got a link to that?

Looks like you found the thread:
https://www.riscosopen.org/forum/forums/12/topics/3405

and a previous thread on the header issue:
https://www.riscosopen.org/forum/forums/11/topics/6322
which links to another thread here:
https://groups.google.com/forum/#!topic/comp.sys.acorn.programmer/6e_j4_nGjzE

I'm happy to give commit access to anyone who wants to sort it out, as it
looks like the problem has been around for a while.

Theo

[David Higton]

In message <+En*DK...@news.chiark.greenend.org.uk>

Theo <theom...@chiark.greenend.org.uk> wrote:

> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> > On 12 May, Theo wrote in message
> > <8En*Qm...@news.chiark.greenend.org.uk>:
> >
> > > On pathnames, I have a feeling this has come up before but noone has
> > > addressed it - Google is not being my friend today.
> >
> > I thought similar, but almost a day on Google (on and off) found me
> > nothing.
>
> I have a vague recollection David Higton might have been involved, perhaps
> he can remember?

The only person I can recall as having done any development on DeskLib
in years is Rick Murray.

I did try to use it some years ago, but I couldn't get it to build and
work for me. I apologise, it's so long ago that I cannot remember any
of the details.

It must be well over a decade, maybe even two, since I actually used
DeskLib successfully. But, if you can get it to build with the tools
that you want to use, I remember that it does make an app's
infrastructure very easy to create.

David

[Jean-Michel]

In message <mpro.qa9joi01...@stevefryatt.org.uk>

I have an ARMX6 and I downloaded OMAP4Dev
from:
https://www.riscosopen.org/content/downloads/risc-os-tarballs

In RiscOs.sources.lib there is a lib named Desk (not desklib)
Comparing the directoriy of headers with that of Rick desklib, it seems to
me that it is the same library. and more complete.
With Desk (from ROOL) there is no source, just the headers and the
library.

I use DDE and so I added Desk to my libraries, but I mostly use OsLib as
in your documentation: "wimp Programming in C" on your website.
Thanks for this tutorial, it should help Risc OS programmers get started.
DDE + ToolBox + Risc OS libraries and documentation are now affordable.
It's just my opinion.


--
Jean-Michel

[Steve Fryatt]

On 13 May, Jean-Michel wrote in message

<d7040f7...@jmc.bruck.orange.fr>:

> In RiscOs.sources.lib there is a lib named Desk (not desklib) Comparing
> the directoriy of headers with that of Rick desklib, it seems to me that
> it is the same library. and more complete.
> With Desk (from ROOL) there is no source, just the headers and the
> library.

Desk was a "reimagining" of DeskLib sometime in the early 1990s by one of
the original developers, which involved some significant namespace and API
changes. To differentiate it from DeskLib (then at around 2.00, IIRC), it
got the version number 3.00 and the trendy name "Desk".

The idea was that everyone would upgrade, so this made sense. The
improvements made a lot of sense, too, from what I remember. Upgrading a
project to use Desk was a lot of work. Most developers didn't bother.

Now it seems that DeskLib has reached version 3.00 itself, which isn't at
all confusing.

> I use DDE and so I added Desk to my libraries, but I mostly use OsLib as
> in your documentation: "wimp Programming in C" on your website. Thanks for
> this tutorial, it should help Risc OS programmers get started.

No problem; it's grown a bit in the past few weeks, thanks to lock-down.

:-)

[Steve Fryatt]

Well, I finally got back to looking at this...

I can now mostly build WinEd from source, although I've had to comment
some code out for now to make it compile.

One oddity is that it seems to include an Error.c source file which GCC
thinks duplicates the Error.c in DeskLib. This appears to be to allow
WinEd to set its own error box titles, but there seems to be no way to
get the linker to pick WinEd's Error.o over the one in DeskLib (although
the DeskLib notes suggest that this is what should be done).

On 2020-05-13, Martin <New...@avisoft.f9.co.uk> wrote:

> On 13 May in article <mpro.qa9ji901...@stevefryatt.org.uk>,
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
>> This is version 3.20 (September 2008). The latest that I'm aware of
>> is 3.21 (alpha), if you build from source.
>
> I would love to see WinEd made a little more stable, as it is my
> favourite template editor. Currently using a Titanium, previously
> RPi3 and Iyonix.

[snip]

> But I maybe have the advantage of having v3.22a (Oct 2008) here!

I don't suppose that you have the source to it and the associated
DeskLib? Even the 3.20 tag from SVN references what I take to be a
DeskLib function call (Pointer_SetPosition) which isn't in the DeskLib
sources in SVN; it's not used in the 3.10 tag of WinEd, so it looks like
a newish feature.

It doesn't look like a big deal to recreate, but having the original
code would be better.

Also, the version of WinEd in SVN reports itself to be 3.21a, so
presumably there are some other code mods that never made it into SVN.

> I was feeding back issues and suggestions to Adam before he lost
> interest, so it may be worth trying to contact hime if you have not
> already tried.

I managed to find an address today which didn't bounce back immediately,
so fingers crossed.

[Theo]

Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> Well, I finally got back to looking at this...
>
> I can now mostly build WinEd from source, although I've had to comment
> some code out for now to make it compile.
>
> One oddity is that it seems to include an Error.c source file which GCC
> thinks duplicates the Error.c in DeskLib. This appears to be to allow
> WinEd to set its own error box titles, but there seems to be no way to
> get the linker to pick WinEd's Error.o over the one in DeskLib (although
> the DeskLib notes suggest that this is what should be done).

I'm a bit puzzled by that - normally linking is done on a per-function
basis, rather than a per-file basis. In other words you might have foo.o
twice but if the functions don't overlap it's not a problem.

I assume you're doing -lDeskLib rather than trying to link all the *.o from
Desklib? Where does it talk about this in the Desklib notes?

The other thing I'd try is changing the order on the link line so that it
detects the right one first.

Quick test (on a Mac):

$ cat > test1.c
int foo(int x) { return x*2; }
$ mkdir subdir
$ cat > subdir/test1.c
int bar(int x) { return x*4; }
$ cat > main.c
int main(void) { return foo(bar(99)); }
$ gcc -o test1 main.c test1.c subdir/test1.c
[warnings about no prototypes for foo and bar]
2 warnings generated.
[succeeded]

If I make a static library:

$ gcc -c -o subdir/test1.o subdir/test1.c
$ ar -r libtest1.a subdir/test1.o
ar: creating archive libtest1.a
$ gcc -o test1 main.c test1.c libtest1.a
[succeeded]

$ gcc -o test1 -L. main.c test1.c -ltest1
[succeeded]

It is possible to have 'weak symbols' by which the linker will pick a
fallback function if one isn't explicitly declared - perhaps this is what
it's talking about?
https://en.wikipedia.org/wiki/Weak_symbol
(Unixlib has used them for years, but I'm not sure if Norcroft supports
them)

> I don't suppose that you have the source to it and the associated
> DeskLib? Even the 3.20 tag from SVN references what I take to be a
> DeskLib function call (Pointer_SetPosition) which isn't in the DeskLib
> sources in SVN; it's not used in the 3.10 tag of WinEd, so it looks like
> a newish feature.
>
> It doesn't look like a big deal to recreate, but having the original
> code would be better.
>
> Also, the version of WinEd in SVN reports itself to be 3.21a, so
> presumably there are some other code mods that never made it into SVN.

If anyone wants commit access to SVN to tidy things up, I'm happy to arrange
that...

Theo

[Martin]

On 16 Jun in article <slrnrehln...@stevefryatt.org.uk>, Steve

Fryatt <ne...@stevefryatt.org.uk> wrote:
> > But I maybe have the advantage of having v3.22a (Oct 2008) here!

> I don't suppose that you have the source to it and the associated
> DeskLib? Even the 3.20 tag from SVN references what I take to be a
> DeskLib function call (Pointer_SetPosition) which isn't in the
> DeskLib sources in SVN; it's not used in the 3.10 tag of WinEd, so
> it looks like a newish feature.

> It doesn't look like a big deal to recreate, but having the
> original code would be better.

No, sorry. Although I have lots of emails from 2008/9 about bugs and
developments, and several different beta versions, the last source I
have is v3.20

When you get to the stage of having a compilable working version I
would be happy to dig out any info about bugs & changes after that
point in development - and even to beta test it, if that would help.
There are certainly some ZeroPain bugs which could do with sorting!

Adam's snowstone riscos website page is still available, so I would
have expected the associated emails to still work - but maybe not.

I hope you manage to make progress!

[Steve Fryatt]

On 16 Jun, Theo wrote in message
<Coy*RG...@news.chiark.greenend.org.uk>:

> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> > One oddity is that it seems to include an Error.c source file which GCC
> > thinks duplicates the Error.c in DeskLib. This appears to be to allow
> > WinEd to set its own error box titles, but there seems to be no way to
> > get the linker to pick WinEd's Error.o over the one in DeskLib (although
> > the DeskLib notes suggest that this is what should be done).
>
> I'm a bit puzzled by that - normally linking is done on a per-function
> basis, rather than a per-file basis. In other words you might have foo.o
> twice but if the functions don't overlap it's not a problem.
>
> I assume you're doing -lDeskLib rather than trying to link all the *.o
> from Desklib? Where does it talk about this in the Desklib notes?

Yes, that's what I thought... The Error.h in DeskLib says

: This header provides centralised error reporting routines, and a few
: macros to help with error reporting.

: This idea is that if you want to replace these with your own error
: reporting routines you can just link against your set instead and keep the
: function prototypes the same. An example of this is linking against
: Desklib:o.Other.SmError which provides command-line output of errors by
: writing them to stderr.

Then WinEd has its own Error.c file, which contains duplicates of some of
the routines defined in DeskLib's Error.c and Error.h, which appear to do
most of the same things in different ways.

> The other thing I'd try is changing the order on the link line so that it
> detects the right one first.

The Makefile does

linkflags = -mlibscl -o ../!RunImage,ff8
libraries = -L$(GCCSDK_INSTALL_ENV)/lib -lDesk-scl -lFlexLib32

# Default rule
../!RunImage,ff8 : $(objects)
$(CC) $(linkflags) $(objects) $(libraries)

The order of $(objects) $(libraries) in the parameter list just affects
which of the two definitions GCC reports as being the original. $(objects)
contains the Error.o from WinEd, amongst the other WinEd object files.

> > Also, the version of WinEd in SVN reports itself to be 3.21a, so
> > presumably there are some other code mods that never made it into SVN.
>
> If anyone wants commit access to SVN to tidy things up, I'm happy to
> arrange that...

It might be useful... :-)

I've already got access to the Tokenize repo, although it's been a while
since I used it.

[Theo]

Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> On 16 Jun, Theo wrote in message
> <Coy*RG...@news.chiark.greenend.org.uk>:

> Yes, that's what I thought... The Error.h in DeskLib says
>
> : This header provides centralised error reporting routines, and a few
> : macros to help with error reporting.
>
> : This idea is that if you want to replace these with your own error
> : reporting routines you can just link against your set instead and keep the
> : function prototypes the same. An example of this is linking against
> : Desklib:o.Other.SmError which provides command-line output of errors by
> : writing them to stderr.
>
> Then WinEd has its own Error.c file, which contains duplicates of some of
> the routines defined in DeskLib's Error.c and Error.h, which appear to do
> most of the same things in different ways.

Hmm, so SmError comes from:
!DLUser.Libraries.SmallError.Error/c
in websvn:
http://www.riscos.info/websvn/listing.php?repname=DeskLib&path=%2Ftrunk%2F%21DLUser%2FLibraries%2FSmallError%2F&#a0df80822861e2ae3e282c05e0ce1f455

However that just puts it in a library and doesn't link with anything.

> The Makefile does
>
> linkflags = -mlibscl -o ../!RunImage,ff8
> libraries = -L$(GCCSDK_INSTALL_ENV)/lib -lDesk-scl -lFlexLib32
>
> # Default rule
> ../!RunImage,ff8 : $(objects)
> $(CC) $(linkflags) $(objects) $(libraries)
>
> The order of $(objects) $(libraries) in the parameter list just affects
> which of the two definitions GCC reports as being the original. $(objects)
> contains the Error.o from WinEd, amongst the other WinEd object files.

I wonder if Norcroft will pick the first function it finds and ignore the
others. For GCC you can try:
-Wl,--allow-multiple-definition

which will pass that the --allow-multiple-definition flag to the linker.

> It might be useful... :-)
>
> I've already got access to the Tokenize repo, although it's been a while
> since I used it.

I've given you access to the WinEd and DeskLib repos, have fun :)

Theo

[Steve Fryatt]

On 16 Jun, Martin wrote in message
<5881986a...@avisoft.f9.co.uk>:

> No, sorry. Although I have lots of emails from 2008/9 about bugs and
> developments, and several different beta versions, the last source I have
> is v3.20

I've made contact with Adam; he was very helpful, but doesn't have the
sources any more. There's a chance that he didn't commit the DeskLib changes
needed by WinEd 3.20 and later, but it was a long time ago!

That said, I think I've now filled in the missing function[1], so with the
Error.c file removed from WinEd's makefile and one other hack to get around
what the WinEd source describes as a "bodge", I can build an apparently
working version 3.21a.

It still crashes on my system in the usual places, however!

> When you get to the stage of having a compilable working version I would
> be happy to dig out any info about bugs & changes after that point in
> development - and even to beta test it, if that would help. There are
> certainly some ZeroPain bugs which could do with sorting!

If you have any info, it would be useful. I'm not going to promise to
recreate 3.22a, but knowing what was being done might be handy.

For now, I'll go hunting an Abort on Data Transfer. :-)


1. I won't lie: it wasn't a difficult one. :-)

[Steve Fryatt]

On 16 Jun, Theo wrote in message

<Coy*D4...@news.chiark.greenend.org.uk>:

> I wonder if Norcroft will pick the first function it finds and ignore the
> others. For GCC you can try: -Wl,--allow-multiple-definition
>
> which will pass that the --allow-multiple-definition flag to the linker.

That's brilliant... thank you! It sorts all of the linker errors, apart from
the missing DeskLib function. :-)

With that, plus Lee's help on the GCCSDK list with the <DeskLib$Path> stuff,
I'm down to one problem with AsAsm, which I can look into further.

> I've given you access to the WinEd and DeskLib repos, have fun :)

Thanks!

I've branched both, stuck the missing Pointer_ function into DeskLib and
will start committing the the necessary changes to WinEd once I've sorted
out the remaining little niggles with the build.