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?
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:
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?
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.
On 12 May, Theo wrote in message
<8En*QmSRx@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 #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 <steve@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.
In message <8En*QmSRx@news.chiark.greenend.org.uk>
Theo <theom+news@chiark.greenend.org.uk> wrote:
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
Desklib is part of RISC OS source code, downloadable from RISC OS OPEN.
In article <mpro.qa8lq705byd6o01x4.news@stevefryatt.org.uk>,
Steve Fryatt <news@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.
In article <mpro.qa8lq705byd6o01x4.news@stevefryatt.org.uk>,
Steve Fryatt <news@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.
The GUI is *very* unstable, to the point of being useless, on a
Titanium.
On 12 May, News wrote in message
<586fb42428chrisjohnson@spamcop.net>:
In article <mpro.qa8lq705byd6o01x4.news@stevefryatt.org.uk>,
Steve Fryatt <news@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.
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.
On 13 May, Jean-Michel wrote in message
<ab06e16f58.jmb@jmc.bruck.orange.fr>:
Unless you are only looking for a GCC version only, I think Rick Murray
did 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?
On 13 May, Jean-Michel wrote in message
<ab06e16f58.jmb@jmc.bruck.orange.fr>:
In message <8En*QmSRx@news.chiark.greenend.org.uk>
Theo <theom+news@chiark.greenend.org.uk> wrote:
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
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 <news@stevefryatt.org.uk> wrote:
On 12 May, Theo wrote in message
<8En*QmSRx@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?
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.
On 13 May in article <mpro.qa9ji90172vg40c85.news@stevefryatt.org.uk>,
Steve Fryatt <news@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.
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.
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 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.
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.
Steve Fryatt <news@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?
The other thing I'd try is changing the order on the link line so that it detects the right one first.
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...
On 16 Jun, Theo wrote in message
<Coy*RGJUx@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.
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.
It might be useful... :-)
I've already got access to the Tokenize repo, although it's been a while since I used it.
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!
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.
I've given you access to the WinEd and DeskLib repos, have fun :)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 294 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 245:39:51 |
| Calls: | 6,626 |
| Calls today: | 2 |
| Files: | 12,175 |
| Messages: | 5,320,569 |