> 1) OS_DynamicArea returns an error. This could happen if the memory
> request was too big, for example, but seems unlikely.
>
> 2) Only 8 mmap sections at any one time are supported. That includes
> those that malloc may create for large requests, however, malloc
> falls back to its normal allocation routines if there are already
> 8 mmaps. Attempting to create a 9th will result in ENOMEM.
> memalign uses malloc and so will suffer the same limitations.
>
> I usually replace any mmap calls with my own dynamic area memory
> allocator.
>
OK I am not sure , but I belive this is the frist one. Will hunt for others
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Wednesday, 28 November 2018
Re: [gccsdk] mmap
On 28/11/2018 12:33, Michael Grunditz wrote:
> On Wed, 28 Nov 2018 at 11:42, Lee Noar <leenoar@sky.com> wrote:
>>
>> On 26/11/2018 15:53, Michael Grunditz wrote:
>>> void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
>>> PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
>>>
>>> Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
>>>
>>> This error is from my "new" OWB codebase. Exactly the same mmap
>>> succeeds in old code.
>>>
>>> I have experimented with wimpslot , but no luck.
>>
>> That error is not from Unixlib. Best thing to do is to search your
>> code base for the error and see what leads to it being generated.
>>
>> Lee.
>
> memalign also fails in the same way. How can I allocate memory inside
> a shared lib? The same code works just find in a standalone file. btw
> it is "perror" that prints the errmessage,
Ok, there are 2 reasons why mmap can fail:
1) OS_DynamicArea returns an error. This could happen if the memory
request was too big, for example, but seems unlikely.
2) Only 8 mmap sections at any one time are supported. That includes
those that malloc may create for large requests, however, malloc
falls back to its normal allocation routines if there are already
8 mmaps. Attempting to create a 9th will result in ENOMEM.
memalign uses malloc and so will suffer the same limitations.
I usually replace any mmap calls with my own dynamic area memory
allocator.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> On Wed, 28 Nov 2018 at 11:42, Lee Noar <leenoar@sky.com> wrote:
>>
>> On 26/11/2018 15:53, Michael Grunditz wrote:
>>> void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
>>> PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
>>>
>>> Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
>>>
>>> This error is from my "new" OWB codebase. Exactly the same mmap
>>> succeeds in old code.
>>>
>>> I have experimented with wimpslot , but no luck.
>>
>> That error is not from Unixlib. Best thing to do is to search your
>> code base for the error and see what leads to it being generated.
>>
>> Lee.
>
> memalign also fails in the same way. How can I allocate memory inside
> a shared lib? The same code works just find in a standalone file. btw
> it is "perror" that prints the errmessage,
Ok, there are 2 reasons why mmap can fail:
1) OS_DynamicArea returns an error. This could happen if the memory
request was too big, for example, but seems unlikely.
2) Only 8 mmap sections at any one time are supported. That includes
those that malloc may create for large requests, however, malloc
falls back to its normal allocation routines if there are already
8 mmaps. Attempting to create a 9th will result in ENOMEM.
memalign uses malloc and so will suffer the same limitations.
I usually replace any mmap calls with my own dynamic area memory
allocator.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] mmap
On Wed, 28 Nov 2018 at 11:42, Lee Noar <leenoar@sky.com> wrote:
>
> On 26/11/2018 15:53, Michael Grunditz wrote:
> > void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
> > PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
> >
> > Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
> >
> > This error is from my "new" OWB codebase. Exactly the same mmap
> > succeeds in old code.
> >
> > I have experimented with wimpslot , but no luck.
>
> That error is not from Unixlib. Best thing to do is to search your
> code base for the error and see what leads to it being generated.
>
> Lee.
memalign also fails in the same way. How can I allocate memory inside
a shared lib? The same code works just find in a standalone file. btw
it is "perror" that prints the errmessage,
Michael
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
>
> On 26/11/2018 15:53, Michael Grunditz wrote:
> > void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
> > PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
> >
> > Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
> >
> > This error is from my "new" OWB codebase. Exactly the same mmap
> > succeeds in old code.
> >
> > I have experimented with wimpslot , but no luck.
>
> That error is not from Unixlib. Best thing to do is to search your
> code base for the error and see what leads to it being generated.
>
> Lee.
memalign also fails in the same way. How can I allocate memory inside
a shared lib? The same code works just find in a standalone file. btw
it is "perror" that prints the errmessage,
Michael
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] mmap
On 26/11/2018 15:53, Michael Grunditz wrote:
> void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
> PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
>
> Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
>
> This error is from my "new" OWB codebase. Exactly the same mmap
> succeeds in old code.
>
> I have experimented with wimpslot , but no luck.
That error is not from Unixlib. Best thing to do is to search your
code base for the error and see what leads to it being generated.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
> PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
>
> Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
>
> This error is from my "new" OWB codebase. Exactly the same mmap
> succeeds in old code.
>
> I have experimented with wimpslot , but no luck.
That error is not from Unixlib. Best thing to do is to search your
code base for the error and see what leads to it being generated.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Monday, 26 November 2018
[gccsdk] mmap
void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
This error is from my "new" OWB codebase. Exactly the same mmap
succeeds in old code.
I have experimented with wimpslot , but no luck.
Please CC me when replying.
Michael
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
This error is from my "new" OWB codebase. Exactly the same mmap
succeeds in old code.
I have experimented with wimpslot , but no luck.
Please CC me when replying.
Michael
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Sunday, 25 November 2018
Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)
On Thu, Nov 22, 2018 at 07:32:32PM +0000, Matthew Howkins wrote:
> I have previously done some work integrating Slirp with RPCEmu, and got
> further than you, because I can send and receive network packets :)
That's good to know. I'm sure your proof-of-concept is better than mine :)
(I have previously dug out the QEMU networking code on another project, but
quite a lot of QEMU came with it. We should be releasing this in a few
weeks, but I don't think the codebase will necessarily be helpful here)
> I expect that there's still a lot to do on networking, but the long-term
> plan is definitely to go with Slirp (or if not Slirp, something
> equivalent). This would become the recommended networking option, and the
> most portable option.
That sounds like a good plan. It would seem to make more sense to work on
that rather than platform-specific TUN/TAP code.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> I have previously done some work integrating Slirp with RPCEmu, and got
> further than you, because I can send and receive network packets :)
That's good to know. I'm sure your proof-of-concept is better than mine :)
(I have previously dug out the QEMU networking code on another project, but
quite a lot of QEMU came with it. We should be releasing this in a few
weeks, but I don't think the codebase will necessarily be helpful here)
> I expect that there's still a lot to do on networking, but the long-term
> plan is definitely to go with Slirp (or if not Slirp, something
> equivalent). This would become the recommended networking option, and the
> most portable option.
That sounds like a good plan. It would seem to make more sense to work on
that rather than platform-specific TUN/TAP code.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Thursday, 22 November 2018
Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)
QEMU uses a library called SLIRP, which contains its own ethernet stack,
including servers to do DHCP, DNS, etc. When a QEMU VM wants to use the network,
the default mode is to push packets into SLIRP which will NAT them and emit
them from the QEMU app as if they were native connections. This enables
no-setup networking for QEMU VMs, and it's the default way that QEMU uses.
In principle, doing the same for RPCEmu would allow no-setup networking
across all the platforms it supports.
I have previously done some work integrating Slirp with RPCEmu, and got further than you, because I can send and receive network packets :)
There's a lot to think about before integrating and releasing the code as is, but the ultimate aim is to get user-friendly networking with the absolute minimum number of configuration steps.
One of the challenges of incorporating Slirp was that there are so many derivatives of the original code base, and they tend to differ in their suitability. Here are some of the things I've considered when selecting which Slirp code to integrate:
* Not all Slirp derivatives are easy to extract and integrate with RPCEmu. The copies in QEMU and VirtualBox are fully-featured, but are very difficult to integrate.
* Not all Slirp code is portable to 64-bit platforms or Windows, as the original code was only for Unix.
* Only some Slirp code has good support for DHCP.
* Only some Slirp codebases support port-forwarding, which I consider a highly desirable feature.
* Few Slirp codebases support DNS proxying, and this I consider an essential feature (see below).
The DNS proxying I consider an essential feature, because without it the user would not only have to manually configure DNS (which would seem odd given that the rest of the config would be automatic), but they would have to change their RISC OS config every time they moved to another network, which laptop users would be very likely to do.
I got to the point of having Slirp integrated and working on Linux, though without support for the DNS proxying feature. However, testing showed up deficiencies and bugs in the other parts of the network code including the EtherRPCEm driver, and that is where most of the recent effort has been expended.
I expect that there's still a lot to do on networking, but the long-term plan is definitely to go with Slirp (or if not Slirp, something equivalent). This would become the recommended networking option, and the most portable option.
Matthew
Wednesday, 21 November 2018
Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)
On Wed, Nov 21, 2018 at 02:07:11PM +0000, David Gee wrote:
> The Mac emulator BasiliskII uses slirp for networking. It doesn't require
> setting up. It's open source so it may be easier than QEMU (or it may
> just use the same code).
Thanks. It appears to use an earlier fork of the same code, without the
library-ification.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> The Mac emulator BasiliskII uses slirp for networking. It doesn't require
> setting up. It's open source so it may be easier than QEMU (or it may
> just use the same code).
Thanks. It appears to use an earlier fork of the same code, without the
library-ification.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)
The Mac emulator BasiliskII uses slirp for networking. It doesn't require setting up. It's open source so it may be easier than QEMU (or it may just use the same code).
David Gee
David Gee
Gateshead
On Tue, Nov 20, 2018 at 10:08:40PM +0000, Theo Markettos wrote:
There are also things like: https://github.com/zhuhaow/NEKit that build on
top of NETunnelProvider and handle the entitlement, like you do with
Tunnelblick.
Shortly after writing that post, I had a better idea.
QEMU uses a library called SLIRP, which contains its own ethernet stack,
including servers to do DHCP, DNS, etc. When a QEMU VM wants to use the network,
the default mode is to push packets into SLIRP which will NAT them and emit
them from the QEMU app as if they were native connections. This enables
no-setup networking for QEMU VMs, and it's the default way that QEMU uses.
In principle, doing the same for RPCEmu would allow no-setup networking
across all the platforms it supports.
QEMU's source code is not pleasant to work with (I have the scars), but
somebody has done libslirp, which is the SLIRP code ripped out into a
separate library with an easy-to-use interface:
https://github.com/rd235/libslirp
(it's mostly GPL as RPCEmu is)
Since I had a spare couple of hours, I plugged libslirp into RPCEmu as a new
'NAT' networking type, just in the Linux code for now as a proof of concept.
Currently it doesn't work - transmitted packets go into libslirp but none
are received from it as network_plt_rx() is never called to fetch them,
probably because I need to understand how the RPCEmu network card does
interrupts. libslirp can either do a synchronous receive call, or a file
descriptor via poll() or select().
As I don't know when I'll next get time to work on this, I've put the
code up here:
https://bitbucket.org/caliston/rpcemu-libslirp/
in case anyone gets around to taking a look before me.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)
On Tue, Nov 20, 2018 at 10:08:40PM +0000, Theo Markettos wrote:
> There are also things like: https://github.com/zhuhaow/NEKit that build on
> top of NETunnelProvider and handle the entitlement, like you do with
> Tunnelblick.
Shortly after writing that post, I had a better idea.
QEMU uses a library called SLIRP, which contains its own ethernet stack,
including servers to do DHCP, DNS, etc. When a QEMU VM wants to use the network,
the default mode is to push packets into SLIRP which will NAT them and emit
them from the QEMU app as if they were native connections. This enables
no-setup networking for QEMU VMs, and it's the default way that QEMU uses.
In principle, doing the same for RPCEmu would allow no-setup networking
across all the platforms it supports.
QEMU's source code is not pleasant to work with (I have the scars), but
somebody has done libslirp, which is the SLIRP code ripped out into a
separate library with an easy-to-use interface:
https://github.com/rd235/libslirp
(it's mostly GPL as RPCEmu is)
Since I had a spare couple of hours, I plugged libslirp into RPCEmu as a new
'NAT' networking type, just in the Linux code for now as a proof of concept.
Currently it doesn't work - transmitted packets go into libslirp but none
are received from it as network_plt_rx() is never called to fetch them,
probably because I need to understand how the RPCEmu network card does
interrupts. libslirp can either do a synchronous receive call, or a file
descriptor via poll() or select().
As I don't know when I'll next get time to work on this, I've put the
code up here:
https://bitbucket.org/caliston/rpcemu-libslirp/
in case anyone gets around to taking a look before me.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> There are also things like: https://github.com/zhuhaow/NEKit that build on
> top of NETunnelProvider and handle the entitlement, like you do with
> Tunnelblick.
Shortly after writing that post, I had a better idea.
QEMU uses a library called SLIRP, which contains its own ethernet stack,
including servers to do DHCP, DNS, etc. When a QEMU VM wants to use the network,
the default mode is to push packets into SLIRP which will NAT them and emit
them from the QEMU app as if they were native connections. This enables
no-setup networking for QEMU VMs, and it's the default way that QEMU uses.
In principle, doing the same for RPCEmu would allow no-setup networking
across all the platforms it supports.
QEMU's source code is not pleasant to work with (I have the scars), but
somebody has done libslirp, which is the SLIRP code ripped out into a
separate library with an easy-to-use interface:
https://github.com/rd235/libslirp
(it's mostly GPL as RPCEmu is)
Since I had a spare couple of hours, I plugged libslirp into RPCEmu as a new
'NAT' networking type, just in the Linux code for now as a proof of concept.
Currently it doesn't work - transmitted packets go into libslirp but none
are received from it as network_plt_rx() is never called to fetch them,
probably because I need to understand how the RPCEmu network card does
interrupts. libslirp can either do a synchronous receive call, or a file
descriptor via poll() or select().
As I don't know when I'll next get time to work on this, I've put the
code up here:
https://bitbucket.org/caliston/rpcemu-libslirp/
in case anyone gets around to taking a look before me.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Tuesday, 20 November 2018
Re: [Rpcemu] Patch for 0.9.1 - Mac keyboard support
On Tue, Nov 20, 2018 at 09:38:56PM +0000, lists@maemagel.com wrote:
> My hacked version would have been pretty awful, even if it had worked.
> Kernel extensions need to be signed in newer versions of OS X and I'm
> not a registered developer, so I ended up downloading an application
> called "Tunnelblick" and borrowing its Tun/Tap kernel extensions, which
> were signed. The emulator would randomly stall during !Boot when
> setting up networking, so I decided to cut my losses and gave it up as a
> bad job. I'll have a look at "networkextension", just to see, though
> I'm not too experienced when it comes to OS X development.
Using Tunnelblick's TUN/TAP was what I did - it worked, but it wasn't exactly
user friendly. I don't think I've tried it on anything post Mavericks,
though.
Apple does say:
The com.apple.developer.networking.networkextension entitlement is required
in order to use the NETunnelProvider class. Enable this entitlement when
creating an App ID in your developer account.
but according to StackOverflow (which must be true) that's no longer the
case. (It may still apply to iOS). There are also things like:
https://github.com/zhuhaow/NEKit
that build on top of NETunnelProvider and handle the entitlement, like you
do with Tunnelblick.
> Peter did ask me whether I'd be prepared to create Mac binaries when I
> emailed him previously off-list, and I "umm"ed and "ah"ed about it. It
> really depends on how much work there is, and whether there are any
> other oddities thrown up by OS X that need to be worked around (such as
> the keyboard and networking). It would be nice to have a proper
> installer as well (there is an installer builder in QT apparently,
> though I've not investigated in any detail).
I don't think there's much to do beyond putting the files in a .app bundle
inside a .dmg archive? I don't think there's any need for an installer,
users open the .dmg and just drag RPCEmu.app to /Applications. You'd
probably put the Qt libraries inside the .app so there's no system
dependencies, or even statically link.
Looks like this is the tool to make a bundle including Qt libraries:
http://doc.qt.io/qt-5/osx-deployment.html
A wizard that's roughly 'what ROM image do you want', 'where do you want
your hostfs to go' etc would be nice, but not critical.
My Allegro binaries were pretty much fire-and-forget - I got a few people
asking about stuff, but not a lot.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> My hacked version would have been pretty awful, even if it had worked.
> Kernel extensions need to be signed in newer versions of OS X and I'm
> not a registered developer, so I ended up downloading an application
> called "Tunnelblick" and borrowing its Tun/Tap kernel extensions, which
> were signed. The emulator would randomly stall during !Boot when
> setting up networking, so I decided to cut my losses and gave it up as a
> bad job. I'll have a look at "networkextension", just to see, though
> I'm not too experienced when it comes to OS X development.
Using Tunnelblick's TUN/TAP was what I did - it worked, but it wasn't exactly
user friendly. I don't think I've tried it on anything post Mavericks,
though.
Apple does say:
The com.apple.developer.networking.networkextension entitlement is required
in order to use the NETunnelProvider class. Enable this entitlement when
creating an App ID in your developer account.
but according to StackOverflow (which must be true) that's no longer the
case. (It may still apply to iOS). There are also things like:
https://github.com/zhuhaow/NEKit
that build on top of NETunnelProvider and handle the entitlement, like you
do with Tunnelblick.
> Peter did ask me whether I'd be prepared to create Mac binaries when I
> emailed him previously off-list, and I "umm"ed and "ah"ed about it. It
> really depends on how much work there is, and whether there are any
> other oddities thrown up by OS X that need to be worked around (such as
> the keyboard and networking). It would be nice to have a proper
> installer as well (there is an installer builder in QT apparently,
> though I've not investigated in any detail).
I don't think there's much to do beyond putting the files in a .app bundle
inside a .dmg archive? I don't think there's any need for an installer,
users open the .dmg and just drag RPCEmu.app to /Applications. You'd
probably put the Qt libraries inside the .app so there's no system
dependencies, or even statically link.
Looks like this is the tool to make a bundle including Qt libraries:
http://doc.qt.io/qt-5/osx-deployment.html
A wizard that's roughly 'what ROM image do you want', 'where do you want
your hostfs to go' etc would be nice, but not critical.
My Allegro binaries were pretty much fire-and-forget - I got a few people
asking about stuff, but not a lot.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Patch for 0.9.1 - Mac keyboard support
On 19 Nov 2018, at 21:49, Theo Markettos <theo@markettos.org.uk> wrote:
I'd imagine that most of the US keyboard layout will work, though I've not tried it myself. The code works by defining a base keyboard layout (UK) and you can add additional layouts to the code by telling it which keys are handled differently - so for French, for example, I've told it that "Y" and "Z" are different. It reads the current keyboard layout in when the application starts and goes from there (all in the "src/qt5/keyboard_macosx.c" file). It's probably not the best solution, but it does work. If there are keys on a US layout that are different, it would be trivial to add in the relevant mappings, whilst allowing other layouts to work unaffected. None of this would be needed if you could obtain scan codes from OS X, but you have do make do with virtual keys, handle modifiers separately and handle CAPS LOCK even more separately.
My hacked version would have been pretty awful, even if it had worked. Kernel extensions need to be signed in newer versions of OS X and I'm not a registered developer, so I ended up downloading an application called "Tunnelblick" and borrowing its Tun/Tap kernel extensions, which were signed. The emulator would randomly stall during !Boot when setting up networking, so I decided to cut my losses and gave it up as a bad job. I'll have a look at "networkextension", just to see, though I'm not too experienced when it comes to OS X development.
Peter did ask me whether I'd be prepared to create Mac binaries when I emailed him previously off-list, and I "umm"ed and "ah"ed about it. It really depends on how much work there is, and whether there are any other oddities thrown up by OS X that need to be worked around (such as the keyboard and networking). It would be nice to have a proper installer as well (there is an installer builder in QT apparently, though I've not investigated in any detail).
Cheers
Tim
On Mon, Nov 19, 2018 at 07:43:18PM +0000, Timothy Coltman wrote:
Hello all
Please find attached a ZIP archive (169K) containing a patch for RPCEmu
0.9.1 that implements keyboard support for OS X/macOS. The file contains
a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder
("macosx") containing the icons for the Mac's dock. This should be
unpacked in the "src" folder and the patch applied from there.
That's great. It looked so good until I came across the Qt keyboard
problem, so fixing that should improve the RPCEmu Mac experience a lot.
4. The patch uses virtual key codes and assumes a UK keyboard layout.
There is support for other keyboard layouts, but needs these to be defined
in the "keyboard_macosx.c" file (there is a very basic French layout
defined that swaps "Y" and "Z").
I've had no end of problems with things getting keyboard layouts wrong on
MacOS (usually with remote connections to other machines where the other end
is set differently) so it wouldn't be the first time.
Does your layout handle US keyboards (it's usually \|~`#@" that get
into trouble)?
I'd imagine that most of the US keyboard layout will work, though I've not tried it myself. The code works by defining a base keyboard layout (UK) and you can add additional layouts to the code by telling it which keys are handled differently - so for French, for example, I've told it that "Y" and "Z" are different. It reads the current keyboard layout in when the application starts and goes from there (all in the "src/qt5/keyboard_macosx.c" file). It's probably not the best solution, but it does work. If there are keys on a US layout that are different, it would be trivial to add in the relevant mappings, whilst allowing other layouts to work unaffected. None of this would be needed if you could obtain scan codes from OS X, but you have do make do with virtual keys, handle modifiers separately and handle CAPS LOCK even more separately.
I usually use the 'British PC' layout on a Macbook Pro which is additional
fun because the keys are now moved around compared to the Apple layout.
Please note that there is no networking support. I did try and get it up
and running, using some of the code from the "Caliston" builds of Francis
Devereux and whilst it did look promising at one point (I could ping from
one end), I wasn't able to get it to work fully.
Those are my builds, and I never got networking to play nicely.
I wonder whether, instead of using TUN/TAP, on MacOS it might be worth
investigating NETunnelProvider as a native API for networking?
https://developer.apple.com/documentation/networkextension
That would make a much nicer user experience.
My hacked version would have been pretty awful, even if it had worked. Kernel extensions need to be signed in newer versions of OS X and I'm not a registered developer, so I ended up downloading an application called "Tunnelblick" and borrowing its Tun/Tap kernel extensions, which were signed. The emulator would randomly stall during !Boot when setting up networking, so I decided to cut my losses and gave it up as a bad job. I'll have a look at "networkextension", just to see, though I'm not too experienced when it comes to OS X development.
Any comments and suggestions would be appreciated. If anyone wants
binaries (so they don't have to compile), please let me know and I'll make
some available in due course.
Peter may have other opinions, but AIUI he doesn't have any means of
producing Mac builds. It sounds like you're set up to do that, so you could
take over producing them from me - I didn't have any special infrastructure
for that beyond a very hacked up Xcode with Snow Leopard libraries - I was
just making random builds on my laptop from time to time. (and running any
kind of CI with MacOS is a pain, so they're not straightforward to automate)
Peter did ask me whether I'd be prepared to create Mac binaries when I emailed him previously off-list, and I "umm"ed and "ah"ed about it. It really depends on how much work there is, and whether there are any other oddities thrown up by OS X that need to be worked around (such as the keyboard and networking). It would be nice to have a proper installer as well (there is an installer builder in QT apparently, though I've not investigated in any detail).
Theo
Cheers
Tim
Re: [Rpcemu] Keyboard layout 'UK international with dead keys'
Hi Frank.
I think the issue with dead keys on all operating systems was caused by the switch to Qt. As per the site, the fix was only for Windows unfortunately. I did write an experimental patch to fix it on Linux/X11 but it was never tested as I'm just running Windows here. I think I included it in the patches I sent to Matthew but I don't know if my approach was the right one as it may well have stopped the normal host-side keyboard shortcuts working thereby requiring a workaround for the workaround!
Kind Regards,
James
On Tue, Nov 20, 2018 at 5:16 PM Frank de Bruijn <rpcemu1-sub@aconet.org> wrote:
Finally got round to compiling RPCEmu 0.9.1 (Debian Testing with XFCE).
Noticed the dead keys still didn't work. From the release notes:
"Dead keys are used to compose accented characters, and are not found on
the UK keyboard layout"
Say what?
Somebody missed the layout 'UK international with dead keys' which has
been available for decades? It worked like a charm with the 0.8.x
versions.
May be an idea to keep this in mind for a next version...
Regards,
Frank
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Keyboard layout 'UK international with dead keys'
Finally got round to compiling RPCEmu 0.9.1 (Debian Testing with XFCE).
Noticed the dead keys still didn't work. From the release notes:
"Dead keys are used to compose accented characters, and are not found on
the UK keyboard layout"
Say what?
Somebody missed the layout 'UK international with dead keys' which has
been available for decades? It worked like a charm with the 0.8.x
versions.
May be an idea to keep this in mind for a next version...
Regards,
Frank
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Noticed the dead keys still didn't work. From the release notes:
"Dead keys are used to compose accented characters, and are not found on
the UK keyboard layout"
Say what?
Somebody missed the layout 'UK international with dead keys' which has
been available for decades? It worked like a charm with the 0.8.x
versions.
May be an idea to keep this in mind for a next version...
Regards,
Frank
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Monday, 19 November 2018
Re: [Rpcemu] Patch for 0.9.1 - Mac keyboard support
On Mon, Nov 19, 2018 at 07:43:18PM +0000, Timothy Coltman wrote:
> Hello all
>
> Please find attached a ZIP archive (169K) containing a patch for RPCEmu
> 0.9.1 that implements keyboard support for OS X/macOS. The file contains
> a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder
> ("macosx") containing the icons for the Mac's dock. This should be
> unpacked in the "src" folder and the patch applied from there.
That's great. It looked so good until I came across the Qt keyboard
problem, so fixing that should improve the RPCEmu Mac experience a lot.
> 4. The patch uses virtual key codes and assumes a UK keyboard layout.
> There is support for other keyboard layouts, but needs these to be defined
> in the "keyboard_macosx.c" file (there is a very basic French layout
> defined that swaps "Y" and "Z").
I've had no end of problems with things getting keyboard layouts wrong on
MacOS (usually with remote connections to other machines where the other end
is set differently) so it wouldn't be the first time.
Does your layout handle US keyboards (it's usually \|~`#@" that get
into trouble)?
I usually use the 'British PC' layout on a Macbook Pro which is additional
fun because the keys are now moved around compared to the Apple layout.
> Please note that there is no networking support. I did try and get it up
> and running, using some of the code from the "Caliston" builds of Francis
> Devereux and whilst it did look promising at one point (I could ping from
> one end), I wasn't able to get it to work fully.
Those are my builds, and I never got networking to play nicely.
I wonder whether, instead of using TUN/TAP, on MacOS it might be worth
investigating NETunnelProvider as a native API for networking?
https://developer.apple.com/documentation/networkextension
That would make a much nicer user experience.
> Any comments and suggestions would be appreciated. If anyone wants
> binaries (so they don't have to compile), please let me know and I'll make
> some available in due course.
Peter may have other opinions, but AIUI he doesn't have any means of
producing Mac builds. It sounds like you're set up to do that, so you could
take over producing them from me - I didn't have any special infrastructure
for that beyond a very hacked up Xcode with Snow Leopard libraries - I was
just making random builds on my laptop from time to time. (and running any
kind of CI with MacOS is a pain, so they're not straightforward to automate)
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Hello all
>
> Please find attached a ZIP archive (169K) containing a patch for RPCEmu
> 0.9.1 that implements keyboard support for OS X/macOS. The file contains
> a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder
> ("macosx") containing the icons for the Mac's dock. This should be
> unpacked in the "src" folder and the patch applied from there.
That's great. It looked so good until I came across the Qt keyboard
problem, so fixing that should improve the RPCEmu Mac experience a lot.
> 4. The patch uses virtual key codes and assumes a UK keyboard layout.
> There is support for other keyboard layouts, but needs these to be defined
> in the "keyboard_macosx.c" file (there is a very basic French layout
> defined that swaps "Y" and "Z").
I've had no end of problems with things getting keyboard layouts wrong on
MacOS (usually with remote connections to other machines where the other end
is set differently) so it wouldn't be the first time.
Does your layout handle US keyboards (it's usually \|~`#@" that get
into trouble)?
I usually use the 'British PC' layout on a Macbook Pro which is additional
fun because the keys are now moved around compared to the Apple layout.
> Please note that there is no networking support. I did try and get it up
> and running, using some of the code from the "Caliston" builds of Francis
> Devereux and whilst it did look promising at one point (I could ping from
> one end), I wasn't able to get it to work fully.
Those are my builds, and I never got networking to play nicely.
I wonder whether, instead of using TUN/TAP, on MacOS it might be worth
investigating NETunnelProvider as a native API for networking?
https://developer.apple.com/documentation/networkextension
That would make a much nicer user experience.
> Any comments and suggestions would be appreciated. If anyone wants
> binaries (so they don't have to compile), please let me know and I'll make
> some available in due course.
Peter may have other opinions, but AIUI he doesn't have any means of
producing Mac builds. It sounds like you're set up to do that, so you could
take over producing them from me - I didn't have any special infrastructure
for that beyond a very hacked up Xcode with Snow Leopard libraries - I was
just making random builds on my laptop from time to time. (and running any
kind of CI with MacOS is a pain, so they're not straightforward to automate)
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Patch for 0.9.1 - Mac keyboard support
Hello all
Please find attached a ZIP archive (169K) containing a patch for RPCEmu 0.9.1 that implements keyboard support for OS X/macOS. The file contains a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder ("macosx") containing the icons for the Mac's dock. This should be unpacked in the "src" folder and the patch applied from there.
This is a development of the same patch that I had previously posted on the Stardot forums (where I used to post as "VincentVega"), and incorporates some of the suggestions made there.
Once compiled, a Mac RPCEmu application will appear in the top-level "rpcemu-0.9.x" folder. Double-click in the normal way to run. You can compile the interpreter or dynamic recompilation versions - both work on a Mac. The patch has been developed on "Sierra" 10.12.6 - it should hopefully work on all later versions.
When you run the application for the first time, it will prompt you to configure a directory where the emulator can expect to find the various files it needs to run, such as the RISC OS ROMs, hard drive images and so on. This allows you to copy the RPCEmu application into the "/Applications" folder if you want, but keep the other files in a separate location in your home folder. Once you've selected a folder with the "Select" button and pressed "OK" the emulated machine will start as normal. If you want to change the folder at a later date, hold down the "Cmd" key as the application starts. You can also delete the "~/Library/Preferences/org.marutan.rpcemu.plist" file.
There are a few things to note:
1. The keyboard mimics that of a RISC PC, so the key to the left of "Z" is blackslash/pipe and the one to the left of RETURN is hash/tilde.
2. There are a few quirks with the keyboard: SHIFT-3 produces an anged bar; pilcrow (to left of "1") produces a pound sign.
3. F13/F14/F15 on a standard Apple aluminium keyboard are mapped to "Print Screen/SysRq", "Scroll Lock" and "BREAK". "Fn" should be mapped to "INSERT".
4. The patch uses virtual key codes and assumes a UK keyboard layout. There is support for other keyboard layouts, but needs these to be defined in the "keyboard_macosx.c" file (there is a very basic French layout defined that swaps "Y" and "Z").
Please note that there is no networking support. I did try and get it up and running, using some of the code from the "Caliston" builds of Francis Devereux and whilst it did look promising at one point (I could ping from one end), I wasn't able to get it to work fully.
Any comments and suggestions would be appreciated. If anyone wants binaries (so they don't have to compile), please let me know and I'll make some available in due course.
Many thanks.
Tim
Please find attached a ZIP archive (169K) containing a patch for RPCEmu 0.9.1 that implements keyboard support for OS X/macOS. The file contains a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder ("macosx") containing the icons for the Mac's dock. This should be unpacked in the "src" folder and the patch applied from there.
This is a development of the same patch that I had previously posted on the Stardot forums (where I used to post as "VincentVega"), and incorporates some of the suggestions made there.
Once compiled, a Mac RPCEmu application will appear in the top-level "rpcemu-0.9.x" folder. Double-click in the normal way to run. You can compile the interpreter or dynamic recompilation versions - both work on a Mac. The patch has been developed on "Sierra" 10.12.6 - it should hopefully work on all later versions.
When you run the application for the first time, it will prompt you to configure a directory where the emulator can expect to find the various files it needs to run, such as the RISC OS ROMs, hard drive images and so on. This allows you to copy the RPCEmu application into the "/Applications" folder if you want, but keep the other files in a separate location in your home folder. Once you've selected a folder with the "Select" button and pressed "OK" the emulated machine will start as normal. If you want to change the folder at a later date, hold down the "Cmd" key as the application starts. You can also delete the "~/Library/Preferences/org.marutan.rpcemu.plist" file.
There are a few things to note:
1. The keyboard mimics that of a RISC PC, so the key to the left of "Z" is blackslash/pipe and the one to the left of RETURN is hash/tilde.
2. There are a few quirks with the keyboard: SHIFT-3 produces an anged bar; pilcrow (to left of "1") produces a pound sign.
3. F13/F14/F15 on a standard Apple aluminium keyboard are mapped to "Print Screen/SysRq", "Scroll Lock" and "BREAK". "Fn" should be mapped to "INSERT".
4. The patch uses virtual key codes and assumes a UK keyboard layout. There is support for other keyboard layouts, but needs these to be defined in the "keyboard_macosx.c" file (there is a very basic French layout defined that swaps "Y" and "Z").
Please note that there is no networking support. I did try and get it up and running, using some of the code from the "Caliston" builds of Francis Devereux and whilst it did look promising at one point (I could ping from one end), I wasn't able to get it to work fully.
Any comments and suggestions would be appreciated. If anyone wants binaries (so they don't have to compile), please let me know and I'll make some available in due course.
Many thanks.
Tim
Re: [gccsdk] SimpleGit (!Nettle & ssh keys)
On Mon, 19 Nov 2018, Alan Williams wrote:
> It might be worthwhile storing the keys somewhere consistent so pre-shared
> keys stored for the git client can also be used by !nettle. I used
> !Nettle's hot list 'command' field to pass in the key file name, and at
> present use Nettle choices directory to store sshid_dsa and sshid_dsa/pub
The openssh package that's currently on riscos.info tries to use keys from
a /ssh folder in Choices. I say "tries" because it looks like some
filename translation issues stop it from working properly.
This was on a system without UnixHome installed - possibly it works a bit
better if that's present (ISTR that an older version of ssh did use
UnixHome).
Regardless, Choices:/ssh seems like a reasonable place to me for storing
SSH keys.
Cheers,
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> It might be worthwhile storing the keys somewhere consistent so pre-shared
> keys stored for the git client can also be used by !nettle. I used
> !Nettle's hot list 'command' field to pass in the key file name, and at
> present use Nettle choices directory to store sshid_dsa and sshid_dsa/pub
The openssh package that's currently on riscos.info tries to use keys from
a /ssh folder in Choices. I say "tries" because it looks like some
filename translation issues stop it from working properly.
This was on a system without UnixHome installed - possibly it works a bit
better if that's present (ISTR that an older version of ssh did use
UnixHome).
Regardless, Choices:/ssh seems like a reasonable place to me for storing
SSH keys.
Cheers,
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Building OWB
On Fri, 9 Nov 2018 at 15:26, Michael Grunditz
<michael.grunditz@gmail.com> wrote:
> I must miss something ..
Thanks for the reply. I can't see it using gmal. so please cc me.
-fPIC was the main problem.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
<michael.grunditz@gmail.com> wrote:
> I must miss something ..
Thanks for the reply. I can't see it using gmal. so please cc me.
-fPIC was the main problem.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Sunday, 18 November 2018
Re: [gccsdk] SimpleGit (!Nettle & ssh keys)
> I think Nettle's SSH support [not NettleSSH] manages to use keys and uses
> libssh2 on RISC OS, BICBW.
I believe the stock !Nettle only does user/pass. I worked on this a while
ago and I built a version that would use pre shared keys. It worked ok on
Virtual Acorn but crashed on my pi so I abandoned it and went back to the
stock one. Recently I have updated my RISC OS builder VM with the current
GCC-SDK with a mind to fix this.
It might be worthwhile storing the keys somewhere consistent so pre-shared
keys stored for the git client can also be used by !nettle. I used
!Nettle's hot list 'command' field to pass in the key file name, and at
present use Nettle choices directory to store sshid_dsa and sshid_dsa/pub
Alan
On 19/11/18, 10:00 am, "Theo Markettos" <gcc-bounces@gccsdk.riscos.info on
behalf of theo@markettos.org.uk> wrote:
>On Sun, Nov 18, 2018 at 10:41:33PM +0000, Jeffrey Lee wrote:
>> Also, a quick look through the libssh2 source suggests that it'll try
>>to get
>> your public/private key by using a Unix domain socket to connect to the
>>ssh
>> agent - which obviously won't exist on RISC OS. So it might be that that
>> error message is indicative of that failure, or it might be that there
>>are
>> two problems to solve.
>
>That's SSH agent authentication. I'm not sure whether RISC OS/Unixlib
>will handle
>Unix domain sockets (RISC OS doesn't really do IPC as there's no P to
>speak
>of), but if not is there a way to make it use use key files
>($HOME/.ssh/id_rsa and similar)?
>
>I think Nettle's SSH support [not NettleSSH] manages to use keys and uses
>libssh2 on RISC OS, BICBW.
>
>> I've added a !Help file which covers common operations and RISC OS
>>specific
>> usage info. It's a bit awkward to use, but since "awkward git client" is
>> better than "no git client", I think it's probably in a suitable state
>>for
>> us to make a first release.
>
>I'll try and turn the handle manually when I get a minute, unless anyone
>gets there first.
>
>Thanks for the patches,
>Theo
>
>_______________________________________________
>GCCSDK mailing list gcc@gccsdk.riscos.info
>Bugzilla: http://www.riscos.info/bugzilla/index.cgi
>List Info: http://www.riscos.info/mailman/listinfo/gcc
>Main Page: http://www.riscos.info/index.php/GCCSDK
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> libssh2 on RISC OS, BICBW.
I believe the stock !Nettle only does user/pass. I worked on this a while
ago and I built a version that would use pre shared keys. It worked ok on
Virtual Acorn but crashed on my pi so I abandoned it and went back to the
stock one. Recently I have updated my RISC OS builder VM with the current
GCC-SDK with a mind to fix this.
It might be worthwhile storing the keys somewhere consistent so pre-shared
keys stored for the git client can also be used by !nettle. I used
!Nettle's hot list 'command' field to pass in the key file name, and at
present use Nettle choices directory to store sshid_dsa and sshid_dsa/pub
Alan
On 19/11/18, 10:00 am, "Theo Markettos" <gcc-bounces@gccsdk.riscos.info on
behalf of theo@markettos.org.uk> wrote:
>On Sun, Nov 18, 2018 at 10:41:33PM +0000, Jeffrey Lee wrote:
>> Also, a quick look through the libssh2 source suggests that it'll try
>>to get
>> your public/private key by using a Unix domain socket to connect to the
>>ssh
>> agent - which obviously won't exist on RISC OS. So it might be that that
>> error message is indicative of that failure, or it might be that there
>>are
>> two problems to solve.
>
>That's SSH agent authentication. I'm not sure whether RISC OS/Unixlib
>will handle
>Unix domain sockets (RISC OS doesn't really do IPC as there's no P to
>speak
>of), but if not is there a way to make it use use key files
>($HOME/.ssh/id_rsa and similar)?
>
>I think Nettle's SSH support [not NettleSSH] manages to use keys and uses
>libssh2 on RISC OS, BICBW.
>
>> I've added a !Help file which covers common operations and RISC OS
>>specific
>> usage info. It's a bit awkward to use, but since "awkward git client" is
>> better than "no git client", I think it's probably in a suitable state
>>for
>> us to make a first release.
>
>I'll try and turn the handle manually when I get a minute, unless anyone
>gets there first.
>
>Thanks for the patches,
>Theo
>
>_______________________________________________
>GCCSDK mailing list gcc@gccsdk.riscos.info
>Bugzilla: http://www.riscos.info/bugzilla/index.cgi
>List Info: http://www.riscos.info/mailman/listinfo/gcc
>Main Page: http://www.riscos.info/index.php/GCCSDK
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] SimpleGit
On Sun, 18 Nov 2018, Theo Markettos wrote:
> On Sun, Nov 18, 2018 at 10:41:33PM +0000, Jeffrey Lee wrote:
>> Also, a quick look through the libssh2 source suggests that it'll try to get
>> your public/private key by using a Unix domain socket to connect to the ssh
>> agent - which obviously won't exist on RISC OS. So it might be that that
>> error message is indicative of that failure, or it might be that there are
>> two problems to solve.
>
> That's SSH agent authentication. I'm not sure whether RISC OS/Unixlib will handle
> Unix domain sockets (RISC OS doesn't really do IPC as there's no P to speak
> of), but if not is there a way to make it use use key files
> ($HOME/.ssh/id_rsa and similar)?
libgit2 does allow programs to provide the keys directly in memory, it's
just not hooked up to sgit. So that would probably be the easiest way of
getting it working.
Cheers,
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> On Sun, Nov 18, 2018 at 10:41:33PM +0000, Jeffrey Lee wrote:
>> Also, a quick look through the libssh2 source suggests that it'll try to get
>> your public/private key by using a Unix domain socket to connect to the ssh
>> agent - which obviously won't exist on RISC OS. So it might be that that
>> error message is indicative of that failure, or it might be that there are
>> two problems to solve.
>
> That's SSH agent authentication. I'm not sure whether RISC OS/Unixlib will handle
> Unix domain sockets (RISC OS doesn't really do IPC as there's no P to speak
> of), but if not is there a way to make it use use key files
> ($HOME/.ssh/id_rsa and similar)?
libgit2 does allow programs to provide the keys directly in memory, it's
just not hooked up to sgit. So that would probably be the easiest way of
getting it working.
Cheers,
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] SimpleGit
On Sun, Nov 18, 2018 at 10:41:33PM +0000, Jeffrey Lee wrote:
> Also, a quick look through the libssh2 source suggests that it'll try to get
> your public/private key by using a Unix domain socket to connect to the ssh
> agent - which obviously won't exist on RISC OS. So it might be that that
> error message is indicative of that failure, or it might be that there are
> two problems to solve.
That's SSH agent authentication. I'm not sure whether RISC OS/Unixlib will handle
Unix domain sockets (RISC OS doesn't really do IPC as there's no P to speak
of), but if not is there a way to make it use use key files
($HOME/.ssh/id_rsa and similar)?
I think Nettle's SSH support [not NettleSSH] manages to use keys and uses
libssh2 on RISC OS, BICBW.
> I've added a !Help file which covers common operations and RISC OS specific
> usage info. It's a bit awkward to use, but since "awkward git client" is
> better than "no git client", I think it's probably in a suitable state for
> us to make a first release.
I'll try and turn the handle manually when I get a minute, unless anyone
gets there first.
Thanks for the patches,
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Also, a quick look through the libssh2 source suggests that it'll try to get
> your public/private key by using a Unix domain socket to connect to the ssh
> agent - which obviously won't exist on RISC OS. So it might be that that
> error message is indicative of that failure, or it might be that there are
> two problems to solve.
That's SSH agent authentication. I'm not sure whether RISC OS/Unixlib will handle
Unix domain sockets (RISC OS doesn't really do IPC as there's no P to speak
of), but if not is there a way to make it use use key files
($HOME/.ssh/id_rsa and similar)?
I think Nettle's SSH support [not NettleSSH] manages to use keys and uses
libssh2 on RISC OS, BICBW.
> I've added a !Help file which covers common operations and RISC OS specific
> usage info. It's a bit awkward to use, but since "awkward git client" is
> better than "no git client", I think it's probably in a suitable state for
> us to make a first release.
I'll try and turn the handle manually when I get a minute, unless anyone
gets there first.
Thanks for the patches,
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] SimpleGit
On Sat, 10 Nov 2018, Theo Markettos wrote:
> On Sat, Nov 10, 2018 at 10:07:03PM +0000, Jeffrey Lee wrote:
>> Cheers. I'll hopefully have an update tomorrow that tidies up the package a
>> bit (e.g. proper version number), so if uploading the built version to
>> riscos.info is a manual thing then it's probably best to hold off on that
>> for the time being.
>
> It is, until I get some time to redo the CI system, entirely manual.
>
> When it's stable enough for us to advertise builds, do let us know.
I tested out https and git (ssh) push support today. https works, but ssh
(using public/private key pairs) appears to be broken - generating a
rather un-useful message of "libgit error: No detailed error message!". So
that'll need some debugging to find out where & why it's being generated.
Also, a quick look through the libssh2 source suggests that it'll try to
get your public/private key by using a Unix domain socket to connect to
the ssh agent - which obviously won't exist on RISC OS. So it might be
that that error message is indicative of that failure, or it might be that
there are two problems to solve.
I've added a !Help file which covers common operations and RISC OS
specific usage info. It's a bit awkward to use, but since "awkward git
client" is better than "no git client", I think it's probably in a
suitable state for us to make a first release.
Cheers,
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> On Sat, Nov 10, 2018 at 10:07:03PM +0000, Jeffrey Lee wrote:
>> Cheers. I'll hopefully have an update tomorrow that tidies up the package a
>> bit (e.g. proper version number), so if uploading the built version to
>> riscos.info is a manual thing then it's probably best to hold off on that
>> for the time being.
>
> It is, until I get some time to redo the CI system, entirely manual.
>
> When it's stable enough for us to advertise builds, do let us know.
I tested out https and git (ssh) push support today. https works, but ssh
(using public/private key pairs) appears to be broken - generating a
rather un-useful message of "libgit error: No detailed error message!". So
that'll need some debugging to find out where & why it's being generated.
Also, a quick look through the libssh2 source suggests that it'll try to
get your public/private key by using a Unix domain socket to connect to
the ssh agent - which obviously won't exist on RISC OS. So it might be
that that error message is indicative of that failure, or it might be that
there are two problems to solve.
I've added a !Help file which covers common operations and RISC OS
specific usage info. It's a bit awkward to use, but since "awkward git
client" is better than "no git client", I think it's probably in a
suitable state for us to make a first release.
Cheers,
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Thursday, 15 November 2018
Re: [Rpcemu] Mount other Harddrives
In article
<CANc9Z=x2_V7Q4xvbu06vUvcXZDzfysty5rt4WOPMCuwU41zBgw@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
[Snip]
> Instructions
> Use the windows filesystem link tool to create a subfolder inside hostfs
> that points to a different location on windows.
> mklink /d FoldernameinHostFS PathToItemYouWantToLink
> Open windows command prompt as administrator
> cd c:/path/to/RPCEmu/hostfs
> mklink /d C C:\
> mklink /d D D:\
> mklink /d X X:\
> You will now have three directories inside your hostfs root folder that
> link directly to the windows drives.
> > Q2) I have a portable USB SSD drive (R:), is there a way to either
> > access or mount that SSD in RPCEmu.
> I believe this should work the same way as above but haven't tested it.
> mklink /d R R:\
> Peter
Thanks for that info Peter, appreciated.
ATM. very busy with other stuff, but later I'll give that a try and
comment afterwards on the result.
Thanks
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CANc9Z=x2_V7Q4xvbu06vUvcXZDzfysty5rt4WOPMCuwU41zBgw@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
[Snip]
> Instructions
> Use the windows filesystem link tool to create a subfolder inside hostfs
> that points to a different location on windows.
> mklink /d FoldernameinHostFS PathToItemYouWantToLink
> Open windows command prompt as administrator
> cd c:/path/to/RPCEmu/hostfs
> mklink /d C C:\
> mklink /d D D:\
> mklink /d X X:\
> You will now have three directories inside your hostfs root folder that
> link directly to the windows drives.
> > Q2) I have a portable USB SSD drive (R:), is there a way to either
> > access or mount that SSD in RPCEmu.
> I believe this should work the same way as above but haven't tested it.
> mklink /d R R:\
> Peter
Thanks for that info Peter, appreciated.
ATM. very busy with other stuff, but later I'll give that a try and
comment afterwards on the result.
Thanks
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Mount other Harddrives
> Q1) In RPCEmu Is there a way to Mount the Harddrives in the Host machine
> so they can be accessed from the icon bar as can be done in VRPC?
With multiple icons on the iconbar, no. However there is a workaround, but please read and understand these caveats first
1) The webpage states "and all files used with it should be well backed up before using them with RPCEmu.", this will now include any folders you access via hostfs.
2) Due to the different way that windows/linux and RISC OS deal with filetype information, windows/linux files that do not have a risc os filetype that are loaded by a risc os app are often assigned one, this will rename the file on the windows/linux filesystem. As you can imagine renaming files that are used by windows/linux programs or the system can render them unusable. (This is the same behaviour as VRPC).
3) If and when it all goes wrong, do not whinge here, you got warned, which is more than VRPC has ever done.
Instructions
Use the windows filesystem link tool to create a subfolder inside hostfs that points to a different location on windows.
mklink /d FoldernameinHostFS PathToItemYouWantToLink
Open windows command prompt as administrator
cd c:/path/to/RPCEmu/hostfs
mklink /d C C:\
mklink /d D D:\
mklink /d X X:\
You will now have three directories inside your hostfs root folder that link directly to the windows drives.
> Q2) I have a portable USB SSD drive (R:), is there a way to either access
> or mount that SSD in RPCEmu.
I believe this should work the same way as above but haven't tested it.
mklink /d R R:\
> so they can be accessed from the icon bar as can be done in VRPC?
With multiple icons on the iconbar, no. However there is a workaround, but please read and understand these caveats first
1) The webpage states "and all files used with it should be well backed up before using them with RPCEmu.", this will now include any folders you access via hostfs.
2) Due to the different way that windows/linux and RISC OS deal with filetype information, windows/linux files that do not have a risc os filetype that are loaded by a risc os app are often assigned one, this will rename the file on the windows/linux filesystem. As you can imagine renaming files that are used by windows/linux programs or the system can render them unusable. (This is the same behaviour as VRPC).
3) If and when it all goes wrong, do not whinge here, you got warned, which is more than VRPC has ever done.
Instructions
Use the windows filesystem link tool to create a subfolder inside hostfs that points to a different location on windows.
mklink /d FoldernameinHostFS PathToItemYouWantToLink
Open windows command prompt as administrator
cd c:/path/to/RPCEmu/hostfs
mklink /d C C:\
mklink /d D D:\
mklink /d X X:\
You will now have three directories inside your hostfs root folder that link directly to the windows drives.
> Q2) I have a portable USB SSD drive (R:), is there a way to either access
> or mount that SSD in RPCEmu.
I believe this should work the same way as above but haven't tested it.
mklink /d R R:\
Peter
Re: [Rpcemu] Any fixes for certain games?
> Leigh Randle <LeighRandle@hotmail.com> hat am 14. November 2018 um 21:15 geschrieben:
>
>
> Hi
>
> I'm a new user to RPCEmu and have been able to get some game
> ROMS to work. But one game I particularly wanted to work is
> 4th Dimension's Apocalypse.
>
>
> Hi
>
> I'm a new user to RPCEmu and have been able to get some game
> ROMS to work. But one game I particularly wanted to work is
> 4th Dimension's Apocalypse.
For Gaming purposes, for classic games, it is often better to
use Arculator instead of RPCEmu. Not all classic games are
Risc PC compatible, some are timing-sensitive, and RPCEmu is
not cycle-exact.
> However, I've seen this game working on YouTube with RPCEmu
> specifically, with the same RISK version but older version of RPCEmu.
My guess would be that there are multiple versions of
Apocalypse out there, with a new version possibly patched to
work on a Risc PC, while the original version possibly only
worked on Archimedes/RISC OS 3.1 machines.
I know that a lot of 4th Dimension games have multiple
versions out there - often "RISC OS 3.1x only" vs. "Risc PC compatible"
vs. "StrongARM compatible".
Another possibility would be that someone used GameOn or
StrongGuard to get Apocalypse running on RPCEmu.
The StrongGuard Game database however
https://armclub.org.uk/products/strongguard/
does not mark Apocalypse as being made compatible.
> Are there any solutions to this? Or perhaps any other places I can go to ask?
The Stardot forums are a good place to ask, also the JASPP forum.
Jon Abbott of JASPP will know if there are multiple versions of
Apocalypse floating around, he has catalgued every game in every
variant under the sun.
Have fun
hubersn
--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Wednesday, 14 November 2018
Evaluating NetSurf for project
Hello,
I have recently started investigating the possible use of NetSurf for use in my project which is being built on Ubuntu 18.04 and has a majority of it already written in C++ but now need to integrate some features for which NetSurf seems to be a perfect fit.
Currently, I have been able to compile & run the "nsgtk" browser which runs nicely.
Additionally, I have been able to complie the "nsfb" (framebuffer) frontend example which seems to compile just fine, but when I try to run it, I keep getting the same error messages:
--------------------------------------------
~/scraping$ ./nsfb
Message translations failed to load
Unable to initialise framebuffer
--------------------------------------------
I have tired to place the "framebuffer/res" and "netsurf/resources" folders in various locations as described in the documentation, but still I get the same message above.
I think that the nsfb is the starting point that I need, but would like to see it function as the build went well, but just the placement of some files seems to be the problem, although I am not completely sure.
Actually, it would be good to just have the needed "res" folder relative to the nsfb application which seems simplest to me but that is for later.
can you please assist?
Best Regards,
Lonnie T. Cumberland, PhD.
Email: Lonnie.Cumberland@Outstep.com
[Rpcemu] Any fixes for certain games?
Hi
I'm a new user to RPCEmu and have been able to get some game ROMS to work. But one game I particularly wanted to work is 4th Dimension's Apocalypse.
Currently it won't run, regardless of the ROM I use or the settings I use for RPCEmu. First disk is fine, but I can't get the second disk to load up.
However, I've seen this game working on YouTube with RPCEmu specifically, with the same RISK version but older version of RPCEmu.
Are there any solutions to this? Or perhaps any other places I can go to ask?
Best wishes 😊
Leigh.
Sent from Mail for Windows 10
Re: [Rpcemu] RPCEmu (linux) Hangs on seeing uniboot (RO 3.71)
On 26/10/2018 10:39, Richard Walker wrote:
> On Thu, 25 Oct 2018, at 04:38, Bryan Hogan wrote:
>> In message <a7b85a11-151e-bbb7-ba8d-ae4d388f8a38@dewberryfields.co.uk>
>> Michael Howard <mike@dewberryfields.co.uk> wrote:
>>
>>> Using any cpu configuration other that SA causes the emulator to hang as
>>> soon as it 'sees' the uniboot !Boot folder.
>> IIRC this is caused by the StrongARM version of the BootVars program
>> failing on any other cpu type. Maybe you could use a copy of BootVars
>> from an earlier uniboot?
> If there is an issue with BootVars, then I suspect later (post-Acorn?) builds
> will be fine.
>
> You can use the RISC OS 5 disc image (including the boot sequence) on
> versions of RISC OS right back to 3.1.
>
> Apart from historical interest, I'm not sure there is much reason to use
> the old Acorn boot sequence.
Revisiting this ....
> On Thu, 25 Oct 2018, at 04:38, Bryan Hogan wrote:
>> In message <a7b85a11-151e-bbb7-ba8d-ae4d388f8a38@dewberryfields.co.uk>
>> Michael Howard <mike@dewberryfields.co.uk> wrote:
>>
>>> Using any cpu configuration other that SA causes the emulator to hang as
>>> soon as it 'sees' the uniboot !Boot folder.
>> IIRC this is caused by the StrongARM version of the BootVars program
>> failing on any other cpu type. Maybe you could use a copy of BootVars
>> from an earlier uniboot?
> If there is an issue with BootVars, then I suspect later (post-Acorn?) builds
> will be fine.
>
> You can use the RISC OS 5 disc image (including the boot sequence) on
> versions of RISC OS right back to 3.1.
>
> Apart from historical interest, I'm not sure there is much reason to use
> the old Acorn boot sequence.
Revisiting this ....
Although the 'ARM710' option can indeed be used with the latest RISC OS
5 disc image, networking doesn't then work with that image. An ip
address, netmask, route etc can be assigned but no external connectivity
exists.
The only apparent error when setting up networking is that in the 'Host
names' dialog box, only the 'Host name' textbox is editable (the
nameserver boxes are greyed out) and the 'Reset now' button doesn't work
in the final dialog box.
Networking works with the RISC OS 3.7 Uniboot setup, but 'ARM710' does not.
So, my question is, as the only configuration setting that works here
with Uniboot is 'StrongARM', is RPCemu meant to be fully compatible
with 'ARM710' and RISC OS 3.7? If so, how do I achieve it?
Using different versions of BootVars does not resolve the issue. I tried
the newer version from the RISC OS 5 disc image (5.33 I think) and I
can't find any versions older than the one included in Uniboot (5.0).
--
Mike Howard
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Monday, 12 November 2018
[Rpcemu] Mount other Harddrives
Q1) In RPCEmu Is there a way to Mount the Harddrives in the Host machine
so they can be accessed from the icon bar as can be done in VRPC?
ATM: I have three drives. C:, D:, and X: (D and X are partitions on a
single spinning rust...
Q2) I have a portable USB SSD drive (R:), is there a way to either access
or mount that SSD in RPCEmu.
Thanks
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
so they can be accessed from the icon bar as can be done in VRPC?
ATM: I have three drives. C:, D:, and X: (D and X are partitions on a
single spinning rust...
Q2) I have a portable USB SSD drive (R:), is there a way to either access
or mount that SSD in RPCEmu.
Thanks
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [gccsdk] SimpleGit
On Sun, 11 Nov 2018, Jeffrey Lee wrote:
> The other things I want to do are to enable libssh2 (for git: protocol
> support) and test pushing via https & git. After that I'll send my updated
> recipes and we can probably upload a proper release.
I didn't really have the time to do anything today, but since Chris has
sorted out the libgit2 compatibility & libssh2, I've gone ahead and
committed the changes I was sitting on for tidying up the packages (also
thanks to Theo for getting me commit access!)
Cheers,
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> The other things I want to do are to enable libssh2 (for git: protocol
> support) and test pushing via https & git. After that I'll send my updated
> recipes and we can probably upload a proper release.
I didn't really have the time to do anything today, but since Chris has
sorted out the libgit2 compatibility & libssh2, I've gone ahead and
committed the changes I was sitting on for tidying up the packages (also
thanks to Theo for getting me commit access!)
Cheers,
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Sunday, 11 November 2018
Re: [gccsdk] SimpleGit
On Sun, Nov 11, 2018 at 08:33:53PM +0000, Jeffrey Lee wrote:
> However, there is still at least one problem with the simplegit-libgit2
> package: When I pulled in Chris's changes I also ended up pulling in the
> change to autobuilder/fetch-program from rev 7196. This means that instead
> of using libgit2-0.27.4 from the testing distro, the autobuilder now uses
> libgit2-0.24.6 from the stable distro, which is older than the libgit2 that
> simplegit supports, causing at least one build error due to API changes
> (simplegit's integrated version claims to be 0.26.3).
The reason for switching from 'testing stable' to 'stable oldstable' Debian
releases is that a lot of the autobuilder packages date from older Debian
releases. When Debian release a new version they bump 'stable' to new
codebases, which causes us a lot of work to keep up (and in some cases,
packages can't be fixed). Since we don't have the manpower to keep up with
Debian versions, I dropped the sources back to the version before the most
recent Debian release where more things worked.
If you need a particularly current source tree, using an explicit reference
to git sources is the thing to do. Either a particular tag/branch (for
stability), or master if you are optimistic that upstream won't break
something.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> However, there is still at least one problem with the simplegit-libgit2
> package: When I pulled in Chris's changes I also ended up pulling in the
> change to autobuilder/fetch-program from rev 7196. This means that instead
> of using libgit2-0.27.4 from the testing distro, the autobuilder now uses
> libgit2-0.24.6 from the stable distro, which is older than the libgit2 that
> simplegit supports, causing at least one build error due to API changes
> (simplegit's integrated version claims to be 0.26.3).
The reason for switching from 'testing stable' to 'stable oldstable' Debian
releases is that a lot of the autobuilder packages date from older Debian
releases. When Debian release a new version they bump 'stable' to new
codebases, which causes us a lot of work to keep up (and in some cases,
packages can't be fixed). Since we don't have the manpower to keep up with
Debian versions, I dropped the sources back to the version before the most
recent Debian release where more things worked.
If you need a particularly current source tree, using an explicit reference
to git sources is the thing to do. Either a particular tag/branch (for
stability), or master if you are optimistic that upstream won't break
something.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] SimpleGit
On Sun, 11 Nov 2018, Chris Gransden wrote:
> In article <alpine.WNT.2.00.1811102200330.8924@Jeffrey-PC>,
> Jeffrey Lee <me@phlamethrower.co.uk> wrote:
>> On Sat, 10 Nov 2018, Theo Markettos wrote:
>
>>> Now committed - I renamed it to 'simplegit' because most of the other
>>> packages are lower case. (I'm not sure we have a policy on that)
>
>> Cheers. I'll hopefully have an update tomorrow that tidies up the package
>> a bit (e.g. proper version number), so if uploading the built version to
>> riscos.info is a manual thing then it's probably best to hold off on that
> Hope it's OK. I've checked in some changes to the standalone libgit2 so it
> uses UnixLib MMAP. Seems to work OK now. Also changed settings to be saved
> in Choices$Write.
That's great, thanks. "sgit status" seems to be a lot faster in this new
version, so it gets my approval!
However, there is still at least one problem with the simplegit-libgit2
package: When I pulled in Chris's changes I also ended up pulling in the
change to autobuilder/fetch-program from rev 7196. This means that instead
of using libgit2-0.27.4 from the testing distro, the autobuilder now uses
libgit2-0.24.6 from the stable distro, which is older than the libgit2
that simplegit supports, causing at least one build error due to API
changes (simplegit's integrated version claims to be 0.26.3).
Possibly the solution there is to switch to fetching libgit2 straight from
its git repo. I'll try and sort that out in the next day or two, unless
someone objects. Plus, changing it to pull the sources from git will make
it easier if/when we fork the repo and start adding our own patches.
The other things I want to do are to enable libssh2 (for git: protocol
support) and test pushing via https & git. After that I'll send my updated
recipes and we can probably upload a proper release.
Cheers,
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> In article <alpine.WNT.2.00.1811102200330.8924@Jeffrey-PC>,
> Jeffrey Lee <me@phlamethrower.co.uk> wrote:
>> On Sat, 10 Nov 2018, Theo Markettos wrote:
>
>>> Now committed - I renamed it to 'simplegit' because most of the other
>>> packages are lower case. (I'm not sure we have a policy on that)
>
>> Cheers. I'll hopefully have an update tomorrow that tidies up the package
>> a bit (e.g. proper version number), so if uploading the built version to
>> riscos.info is a manual thing then it's probably best to hold off on that
> Hope it's OK. I've checked in some changes to the standalone libgit2 so it
> uses UnixLib MMAP. Seems to work OK now. Also changed settings to be saved
> in Choices$Write.
That's great, thanks. "sgit status" seems to be a lot faster in this new
version, so it gets my approval!
However, there is still at least one problem with the simplegit-libgit2
package: When I pulled in Chris's changes I also ended up pulling in the
change to autobuilder/fetch-program from rev 7196. This means that instead
of using libgit2-0.27.4 from the testing distro, the autobuilder now uses
libgit2-0.24.6 from the stable distro, which is older than the libgit2
that simplegit supports, causing at least one build error due to API
changes (simplegit's integrated version claims to be 0.26.3).
Possibly the solution there is to switch to fetching libgit2 straight from
its git repo. I'll try and sort that out in the next day or two, unless
someone objects. Plus, changing it to pull the sources from git will make
it easier if/when we fork the repo and start adding our own patches.
The other things I want to do are to enable libssh2 (for git: protocol
support) and test pushing via https & git. After that I'll send my updated
recipes and we can probably upload a proper release.
Cheers,
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] SimpleGit
In article <alpine.WNT.2.00.1811102200330.8924@Jeffrey-PC>,
Jeffrey Lee <me@phlamethrower.co.uk> wrote:
> On Sat, 10 Nov 2018, Theo Markettos wrote:
> > Now committed - I renamed it to 'simplegit' because most of the other
> > packages are lower case. (I'm not sure we have a policy on that)
> Cheers. I'll hopefully have an update tomorrow that tidies up the package
> a bit (e.g. proper version number), so if uploading the built version to
> riscos.info is a manual thing then it's probably best to hold off on that
Hope it's OK. I've checked in some changes to the standalone libgit2 so it
uses UnixLib MMAP. Seems to work OK now. Also changed settings to be saved
in Choices$Write.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Jeffrey Lee <me@phlamethrower.co.uk> wrote:
> On Sat, 10 Nov 2018, Theo Markettos wrote:
> > Now committed - I renamed it to 'simplegit' because most of the other
> > packages are lower case. (I'm not sure we have a policy on that)
> Cheers. I'll hopefully have an update tomorrow that tidies up the package
> a bit (e.g. proper version number), so if uploading the built version to
> riscos.info is a manual thing then it's probably best to hold off on that
Hope it's OK. I've checked in some changes to the standalone libgit2 so it
uses UnixLib MMAP. Seems to work OK now. Also changed settings to be saved
in Choices$Write.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Saturday, 10 November 2018
Re: [gccsdk] SimpleGit
On Sat, Nov 10, 2018 at 10:07:03PM +0000, Jeffrey Lee wrote:
> Cheers. I'll hopefully have an update tomorrow that tidies up the package a
> bit (e.g. proper version number), so if uploading the built version to
> riscos.info is a manual thing then it's probably best to hold off on that
> for the time being.
It is, until I get some time to redo the CI system, entirely manual.
When it's stable enough for us to advertise builds, do let us know.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Cheers. I'll hopefully have an update tomorrow that tidies up the package a
> bit (e.g. proper version number), so if uploading the built version to
> riscos.info is a manual thing then it's probably best to hold off on that
> for the time being.
It is, until I get some time to redo the CI system, entirely manual.
When it's stable enough for us to advertise builds, do let us know.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] SimpleGit
On Sun, 11 Nov 2018, Ron wrote:
> Good to have examples of AB_GIT and cmake useage too.
> A quick look inside the debian src for libgit2 -dev, namely unix/map.c
> shows
>
> #if !defined(GIT_WIN32) && !defined(NO_MMAP)
>
> indicating at least for that file NO_MMAP can be defined.
> could be worth exporting from the setvars file
That's the problem - you turn off mmap and then libgit2's own mmap
emulation moans at you :-)
Possibly it would work with UnixLib's mmap emulation, so that might be
worth trying if we can't work out how to fix libgit2 properly.
Cheers,
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Good to have examples of AB_GIT and cmake useage too.
> A quick look inside the debian src for libgit2 -dev, namely unix/map.c
> shows
>
> #if !defined(GIT_WIN32) && !defined(NO_MMAP)
>
> indicating at least for that file NO_MMAP can be defined.
> could be worth exporting from the setvars file
That's the problem - you turn off mmap and then libgit2's own mmap
emulation moans at you :-)
Possibly it would work with UnixLib's mmap emulation, so that might be
worth trying if we can't work out how to fix libgit2 properly.
Cheers,
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] SimpleGit
On Sat, 10 Nov 2018, Theo Markettos wrote:
> Now committed - I renamed it to 'simplegit' because most of the other
> packages are lower case. (I'm not sure we have a policy on that)
Cheers. I'll hopefully have an update tomorrow that tidies up the package
a bit (e.g. proper version number), so if uploading the built version to
riscos.info is a manual thing then it's probably best to hold off on that
for the time being.
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Now committed - I renamed it to 'simplegit' because most of the other
> packages are lower case. (I'm not sure we have a policy on that)
Cheers. I'll hopefully have an update tomorrow that tidies up the package
a bit (e.g. proper version number), so if uploading the built version to
riscos.info is a manual thing then it's probably best to hold off on that
for the time being.
- Jeffrey
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] SimpleGit
On Sat, Nov 10, 2018 at 12:46:10AM +0000, Jeffrey Lee wrote:
> Hi,
>
> Attached is a first-pass autobuilder recipe for SimpleGit
> (https://github.com/sba1/simplegit). The resulting binary seems to work well
> enough to clone repositories via https - I haven't tested it much beyond
> that.
Neat! I wasn't expecting anyone to take my bait so soon :)
Now committed - I renamed it to 'simplegit' because most of the other
packages are lower case. (I'm not sure we have a policy on that)
I also committed the other version as 'simplegit-libgit2' with some warnings
at build time - probably better to keep track of the code in the SVN tree
than in a list attachment that will likely get lost.
I'd be really interested how this build works out - I'd quite like to move
more riscos.info stuff towards git in due course.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Hi,
>
> Attached is a first-pass autobuilder recipe for SimpleGit
> (https://github.com/sba1/simplegit). The resulting binary seems to work well
> enough to clone repositories via https - I haven't tested it much beyond
> that.
Neat! I wasn't expecting anyone to take my bait so soon :)
Now committed - I renamed it to 'simplegit' because most of the other
packages are lower case. (I'm not sure we have a policy on that)
I also committed the other version as 'simplegit-libgit2' with some warnings
at build time - probably better to keep track of the code in the SVN tree
than in a list attachment that will likely get lost.
I'd be really interested how this build works out - I'd quite like to move
more riscos.info stuff towards git in due course.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Patch to update libpng to the latest version
On Fri, Nov 09, 2018 at 03:31:47PM +0000, Cameron Cawley wrote:
> Hi
>
> It appears that the new files added by the patch weren't added as part of
> the commit.
Apologies, I didn't notice there were new files and used 'patch -p0' instead
of 'svn patch'. Now commited as r7209.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Hi
>
> It appears that the new files added by the patch weren't added as part of
> the commit.
Apologies, I didn't notice there were new files and used 'patch -p0' instead
of 'svn patch'. Now commited as r7209.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] SimpleGit
In article <alpine.WNT.2.00.1811101643001.8924@Jeffrey-PC>,
Jeffrey Lee <me@phlamethrower.co.uk> wrote:
> On Sat, 10 Nov 2018, Jeffrey Lee wrote:
> > This recipe builds libgit2 from the submodule that's imported by SimpleGit.
> > But I also have patches for building libgit2 from the upstream libgit2 git
> > repo, so I might experiment with them to produce a libgit2 recipe which
> > SimpleGit can then use instead.
> After a bit of trial and error I managed to get it building in this
> manner - however the upstream libgit2 seems to be broken on systems which
> don't support mmap.
> https://github.com/libgit2/libgit2/issues/4281
> I'm not planning on looking into this any time soon (I'll be sticking to
> the version with the integrated libgit2) - but I have attached the updated
> recipes, just in case anyone else finds them useful. There is a basic
> recipe for http-parser in there which might be useful for other projects.
Good to have examples of AB_GIT and cmake useage too.
A quick look inside the debian src for libgit2 -dev, namely unix/map.c
shows
#if !defined(GIT_WIN32) && !defined(NO_MMAP)
indicating at least for that file NO_MMAP can be defined.
could be worth exporting from the setvars file
Thanks for simplegit
Ron M
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Jeffrey Lee <me@phlamethrower.co.uk> wrote:
> On Sat, 10 Nov 2018, Jeffrey Lee wrote:
> > This recipe builds libgit2 from the submodule that's imported by SimpleGit.
> > But I also have patches for building libgit2 from the upstream libgit2 git
> > repo, so I might experiment with them to produce a libgit2 recipe which
> > SimpleGit can then use instead.
> After a bit of trial and error I managed to get it building in this
> manner - however the upstream libgit2 seems to be broken on systems which
> don't support mmap.
> https://github.com/libgit2/libgit2/issues/4281
> I'm not planning on looking into this any time soon (I'll be sticking to
> the version with the integrated libgit2) - but I have attached the updated
> recipes, just in case anyone else finds them useful. There is a basic
> recipe for http-parser in there which might be useful for other projects.
Good to have examples of AB_GIT and cmake useage too.
A quick look inside the debian src for libgit2 -dev, namely unix/map.c
shows
#if !defined(GIT_WIN32) && !defined(NO_MMAP)
indicating at least for that file NO_MMAP can be defined.
could be worth exporting from the setvars file
Thanks for simplegit
Ron M
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] SimpleGit
On Sat, 10 Nov 2018, Jeffrey Lee wrote:
> This recipe builds libgit2 from the submodule that's imported by SimpleGit.
> But I also have patches for building libgit2 from the upstream libgit2 git
> repo, so I might experiment with them to produce a libgit2 recipe which
> SimpleGit can then use instead.
After a bit of trial and error I managed to get it building in this
manner - however the upstream libgit2 seems to be broken on systems which
don't support mmap.
https://github.com/libgit2/libgit2/issues/4281
I'm not planning on looking into this any time soon (I'll be sticking to
the version with the integrated libgit2) - but I have attached the updated
recipes, just in case anyone else finds them useful. There is a basic
recipe for http-parser in there which might be useful for other projects.
Cheers,
- Jeffrey
> This recipe builds libgit2 from the submodule that's imported by SimpleGit.
> But I also have patches for building libgit2 from the upstream libgit2 git
> repo, so I might experiment with them to produce a libgit2 recipe which
> SimpleGit can then use instead.
After a bit of trial and error I managed to get it building in this
manner - however the upstream libgit2 seems to be broken on systems which
don't support mmap.
https://github.com/libgit2/libgit2/issues/4281
I'm not planning on looking into this any time soon (I'll be sticking to
the version with the integrated libgit2) - but I have attached the updated
recipes, just in case anyone else finds them useful. There is a basic
recipe for http-parser in there which might be useful for other projects.
Cheers,
- Jeffrey
Friday, 9 November 2018
[gccsdk] SimpleGit
Hi,
Attached is a first-pass autobuilder recipe for SimpleGit
(https://github.com/sba1/simplegit). The resulting binary seems to work
well enough to clone repositories via https - I haven't tested it much
beyond that.
Issues are likely to be:
* Filename translation might need tweaking to allow easy control over the
rules that are used for each repository
* Likewise filetype translation is likely to need tweaking (e.g. support
for ,xxx suffixes in the repository).
* It's a bit slow - although a lot of that is likely to be due to
deficiencies in RISC OS.
* It's had minimal testing
* The recipe is a bit rough around the edges
I'll try and find the time to work on it a bit more over the next few
days/weeks, but figured it was a good idea to share it now while it's
still in this early state just in case someone else is eager to have a
play around.
This recipe builds libgit2 from the submodule that's imported by
SimpleGit. But I also have patches for building libgit2 from the
upstream libgit2 git repo, so I might experiment with them to produce a
libgit2 recipe which SimpleGit can then use instead.
Cheers,
- Jeffrey
Attached is a first-pass autobuilder recipe for SimpleGit
(https://github.com/sba1/simplegit). The resulting binary seems to work
well enough to clone repositories via https - I haven't tested it much
beyond that.
Issues are likely to be:
* Filename translation might need tweaking to allow easy control over the
rules that are used for each repository
* Likewise filetype translation is likely to need tweaking (e.g. support
for ,xxx suffixes in the repository).
* It's a bit slow - although a lot of that is likely to be due to
deficiencies in RISC OS.
* It's had minimal testing
* The recipe is a bit rough around the edges
I'll try and find the time to work on it a bit more over the next few
days/weeks, but figured it was a good idea to share it now while it's
still in this early state just in case someone else is eager to have a
play around.
This recipe builds libgit2 from the submodule that's imported by
SimpleGit. But I also have patches for building libgit2 from the
upstream libgit2 git repo, so I might experiment with them to produce a
libgit2 recipe which SimpleGit can then use instead.
Cheers,
- Jeffrey
Re: [gccsdk] Building OWB
On 09/11/2018 14:26, Michael Grunditz wrote:
> Hi
>
> I am trying to build Origyn Web Browser which uses webkit and SDL: It
> is all c++. I have problems with global variables and especially in
> the main client file. It crashes right on access and even more odd I
> need to malloc local class variables before I can give the,m objct
> values from the library.
>
> I must miss something ..
Make sure that any source files that are a part of the executable
are *not* compiled with -fPIC, otherwise it will crash when accessing
global variables.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Hi
>
> I am trying to build Origyn Web Browser which uses webkit and SDL: It
> is all c++. I have problems with global variables and especially in
> the main client file. It crashes right on access and even more odd I
> need to malloc local class variables before I can give the,m objct
> values from the library.
>
> I must miss something ..
Make sure that any source files that are a part of the executable
are *not* compiled with -fPIC, otherwise it will crash when accessing
global variables.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Patch to update libpng to the latest version
Hi
It appears that the new files added by the patch weren't added as part of the commit.
Regards
Cameron
On Thu, 8 Nov 2018 22:08 Theo Markettos <theo@markettos.org.uk wrote:
On Wed, Nov 07, 2018 at 07:14:55PM +0000, Cameron Cawley wrote:
> Hi
>
> Attached is a patch to update libpng to the latest version. To simplify the
> patch, this adds a separate recipe for the new version, rather than
> attempting to rename the old recipe. I haven't tested every program that
> requires libpng, however, I've been using this patch for several months now
> and haven't encountered any problems, so this should hopefully be fine.
Thanks, I've committed that as r7207.
More generally, there are probably some other cases that Debian's 'stretch'
source release broke things that previously worked in 'jessie', but I think
this is the most important one.
Theo
[gccsdk] Building OWB
Hi
I am trying to build Origyn Web Browser which uses webkit and SDL: It
is all c++. I have problems with global variables and especially in
the main client file. It crashes right on access and even more odd I
need to malloc local class variables before I can give the,m objct
values from the library.
I must miss something ..
MIchael
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
I am trying to build Origyn Web Browser which uses webkit and SDL: It
is all c++. I have problems with global variables and especially in
the main client file. It crashes right on access and even more odd I
need to malloc local class variables before I can give the,m objct
values from the library.
I must miss something ..
MIchael
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Set PKG_CONFIG_LIBDIR in the CMake toolchain file.
On Thu, Nov 08, 2018 at 11:38:23PM +0000, Cameron Cawley wrote:
> Hi
>
> Attached is a patch that sets the "PKG_CONFIG_LIBDIR" environment variable
> in the CMake toolchain file.
Thanks, that's r7208.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Hi
>
> Attached is a patch that sets the "PKG_CONFIG_LIBDIR" environment variable
> in the CMake toolchain file.
Thanks, that's r7208.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Thursday, 8 November 2018
[gccsdk] Set PKG_CONFIG_LIBDIR in the CMake toolchain file.
Index: porting-scripts/toolchain-riscos.cmake
===================================================================
--- porting-scripts/toolchain-riscos.cmake (revision 7200)
+++ porting-scripts/toolchain-riscos.cmake (working copy)
@@ -15,3 +15,5 @@
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
+
+SET(ENV{PKG_CONFIG_LIBDIR} GCCSDK_ENV/lib/pkgconfig:GCCSDK_ENV/share/pkgconfig)
===================================================================
--- porting-scripts/toolchain-riscos.cmake (revision 7200)
+++ porting-scripts/toolchain-riscos.cmake (working copy)
@@ -15,3 +15,5 @@
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
+
+SET(ENV{PKG_CONFIG_LIBDIR} GCCSDK_ENV/lib/pkgconfig:GCCSDK_ENV/share/pkgconfig)
Hi
Attached is a patch that sets the "PKG_CONFIG_LIBDIR" environment variable in the CMake toolchain file.
Best regards
Cameron
Re: [gccsdk] Patch to update libpng to the latest version
On Wed, Nov 07, 2018 at 07:14:55PM +0000, Cameron Cawley wrote:
> Hi
>
> Attached is a patch to update libpng to the latest version. To simplify the
> patch, this adds a separate recipe for the new version, rather than
> attempting to rename the old recipe. I haven't tested every program that
> requires libpng, however, I've been using this patch for several months now
> and haven't encountered any problems, so this should hopefully be fine.
Thanks, I've committed that as r7207.
More generally, there are probably some other cases that Debian's 'stretch'
source release broke things that previously worked in 'jessie', but I think
this is the most important one.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Hi
>
> Attached is a patch to update libpng to the latest version. To simplify the
> patch, this adds a separate recipe for the new version, rather than
> attempting to rename the old recipe. I haven't tested every program that
> requires libpng, however, I've been using this patch for several months now
> and haven't encountered any problems, so this should hopefully be fine.
Thanks, I've committed that as r7207.
More generally, there are probably some other cases that Debian's 'stretch'
source release broke things that previously worked in 'jessie', but I think
this is the most important one.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Wednesday, 7 November 2018
[gccsdk] Patch to update libpng to the latest version
Index: browser/firefox2/depends
===================================================================
--- browser/firefox2/depends (revision 7206)
+++ browser/firefox2/depends (working copy)
@@ -6,5 +6,5 @@
libexpat1
libidl
libjpeg8
-libpng12-0
+libpng16-16
zlib1g
Index: browser/firefox2-riscpc/depends
===================================================================
--- browser/firefox2-riscpc/depends (revision 7206)
+++ browser/firefox2-riscpc/depends (working copy)
@@ -6,5 +6,5 @@
libexpat1
libidl
libjpeg8
-libpng12-0
+libpng16-16
zlib1g
Index: browser/otterbrowser/setvars
===================================================================
--- browser/otterbrowser/setvars (revision 7206)
+++ browser/otterbrowser/setvars (working copy)
@@ -30,7 +30,7 @@
$AB_HOME/add-riscpkg -copyrightfile COPYING -package otter-browser -name Otter-browser \
-depends SharedLibs-C++2 -depends Qt5Webkit \
- -depends Qt5Svg -depends Qt5XmlPatterns -depends LibPNG12-0 \
+ -depends Qt5Svg -depends Qt5XmlPatterns -depends LibPNG16-16 \
-depends ZLib1g -depends LibJPEG8 -depends LibSQLite3 -depends LibPcre3 \
-depends LibFontConfig1 -depends LibFreeType6 -depends LibExpat1 -depends LibGCrypt20 \
-depends LibGPG-Error -depends LibICU52 -depends LibSSL -depver 1.0.2d-2 -depends LibLevelDB \
Index: browser/qupzilla/setvars
===================================================================
--- browser/qupzilla/setvars (revision 7206)
+++ browser/qupzilla/setvars (working copy)
@@ -36,7 +36,7 @@
$AB_HOME/add-riscpkg -copyrightfile COPYRIGHT -package qupzilla -name QupZilla \
-depends SharedLibs-C++2 -depends Qt5Webkit \
- -depends Qt5Svg -depends Qt5XmlPatterns -depends LibPNG12-0 \
+ -depends Qt5Svg -depends Qt5XmlPatterns -depends LibPNG16-16 \
-depends ZLib1g -depends LibJPEG8 -depends LibSQLite3 -depends LibPcre3 \
-depends LibFontConfig1 -depends LibFreeType6 -depends LibExpat1 \
-depends LibICU52 -depends LibSSL -depver 1.0.2d-2 -depends LibLevelDB \
Index: games/neverball/depends
===================================================================
--- games/neverball/depends (revision 7206)
+++ games/neverball/depends (working copy)
@@ -1,5 +1,5 @@
gettext
libsdl2
-libpng12-0
+libpng16-16
libsdl2-ttf
libvorbis0a
Index: graphics/gnuplot/depends
===================================================================
--- graphics/gnuplot/depends (revision 7206)
+++ graphics/gnuplot/depends (working copy)
@@ -1,4 +1,4 @@
libgd2
-libpng12-0
+libpng16-16
zlib1g
oslib
\ No newline at end of file
Index: libraries/Qt/Qt5Base/ReadMe
===================================================================
--- libraries/Qt/Qt5Base/ReadMe (revision 7206)
+++ libraries/Qt/Qt5Base/ReadMe (working copy)
@@ -8,7 +8,7 @@
Library dependencies:
libz
-libpng12
+libpng16
icu (libicui18n, libicuuc, libicudata)
libfontconfig
libfreetype
Index: libraries/Qt/Qt5Base/depends
===================================================================
--- libraries/Qt/Qt5Base/depends (revision 7206)
+++ libraries/Qt/Qt5Base/depends (working copy)
@@ -1,4 +1,4 @@
-libpng12-0
+libpng16-16
oslib
libjpeg8
libsqlite3-0
Index: libraries/Qt/Qt5Base/mkspecs.arm-riscos-clang.qmake.conf
===================================================================
--- libraries/Qt/Qt5Base/mkspecs.arm-riscos-clang.qmake.conf (revision 7206)
+++ libraries/Qt/Qt5Base/mkspecs.arm-riscos-clang.qmake.conf (working copy)
@@ -13,7 +13,7 @@
QMAKE_INCDIR = $(GCCSDK_INSTALL_ENV)/include
QMAKE_LIBDIR = $(GCCSDK_INSTALL_ENV)/lib
-QMAKE_LIBS = -ldl -lz -lpng12 -lOSLib32
+QMAKE_LIBS = -ldl -lz -lpng16 -lOSLib32
QMAKE_CFLAGS_STATIC_LIB =
QMAKE_CFLAGS_APP =
Index: libraries/Qt/Qt5Base/mkspecs.arm-riscos-g++.qmake.conf
===================================================================
--- libraries/Qt/Qt5Base/mkspecs.arm-riscos-g++.qmake.conf (revision 7206)
+++ libraries/Qt/Qt5Base/mkspecs.arm-riscos-g++.qmake.conf (working copy)
@@ -13,7 +13,7 @@
QMAKE_INCDIR = $(GCCSDK_INSTALL_ENV)/include
QMAKE_LIBDIR = $(GCCSDK_INSTALL_ENV)/lib
-QMAKE_LIBS = -ldl -lz -lpng12 -lOSLib32 -Wl,-rpath-link,$(GCCSDK_INSTALL_ENV)/lib
+QMAKE_LIBS = -ldl -lz -lpng16 -lOSLib32 -Wl,-rpath-link,$(GCCSDK_INSTALL_ENV)/lib
QMAKE_CFLAGS_STATIC_LIB =
QMAKE_CFLAGS_APP =
Index: libraries/Qt/Qt5Base/mkspecs.arm-riscos-vfp-g++.qmake.conf
===================================================================
--- libraries/Qt/Qt5Base/mkspecs.arm-riscos-vfp-g++.qmake.conf (revision 7206)
+++ libraries/Qt/Qt5Base/mkspecs.arm-riscos-vfp-g++.qmake.conf (working copy)
@@ -14,7 +14,7 @@
QMAKE_INCDIR = $(GCCSDK_INSTALL_ENV)/vfp/include $(GCCSDK_INSTALL_ENV)/include
QMAKE_LIBDIR = $(GCCSDK_INSTALL_ENV)/vfp/lib $(GCCSDK_INSTALL_ENV)/lib
-#QMAKE_LIBS = -ldl -lz -lpng12
+#QMAKE_LIBS = -ldl -lz -lpng16
QMAKE_LFLAGS += -mfpu=vfp
QMAKE_RPATHLINKDIR += :$(GCCSDK_INSTALL_ENV)/vfp/lib:$(GCCSDK_INSTALL_ENV)/lib
Index: libraries/Qt/Qt5Base/setvars
===================================================================
--- libraries/Qt/Qt5Base/setvars (revision 7206)
+++ libraries/Qt/Qt5Base/setvars (working copy)
@@ -197,7 +197,7 @@
AB_COMPONENTS=""
$AB_HOME/add-riscpkg -package qt5base -name Qt5Base \
- -depends SharedLibs -depends LibPNG12-0 -depends ZLib1g \
+ -depends SharedLibs -depends LibPNG16-16 -depends ZLib1g \
-depends LibJPEG8 -depends LibSQLite3 -depends LibPcre3 \
-depends LibFontConfig1 -depends LibFreeType6 -depends LibExpat1 \
-depends LibICU52 -depends LibSSL \
Index: libraries/Qt/Qt5Webkit/!QtTestBrowser/!ReadMe
===================================================================
--- libraries/Qt/Qt5Webkit/!QtTestBrowser/!ReadMe (revision 7206)
+++ libraries/Qt/Qt5Webkit/!QtTestBrowser/!ReadMe (working copy)
@@ -16,7 +16,7 @@
Qt5Base
LevelDB
libz
-libpng12
+libpng16
icu (libicui18n, libicuuc, libicudata)
libfontconfig
libfreetype
Index: libraries/graphics/libpng16-16/!LibPNG/!Boot,feb
===================================================================
--- libraries/graphics/libpng16-16/!LibPNG/!Boot,feb (nonexistent)
+++ libraries/graphics/libpng16-16/!LibPNG/!Boot,feb (working copy)
@@ -0,0 +1,6 @@
+| Boot file for LibPNG
+|
+If "<LibPNG$Dir>" = "" Then Set LibPNG$Dir <Obey$Dir>
+If "<LibPNG$Path>" = "" Then Set LibPNG$Path <Obey$Dir>.,<Obey$Dir>.libpng16.
+
+IconSprites <LibPNG$Dir>.!Sprites
Index: libraries/graphics/libpng16-16/!LibPNG/!Help
===================================================================
--- libraries/graphics/libpng16-16/!LibPNG/!Help (nonexistent)
+++ libraries/graphics/libpng16-16/!LibPNG/!Help (working copy)
@@ -0,0 +1,19 @@
+LibPNG - Portable Network Graphics Library
+
+This RISC OS version was created by the GCCSDK
+Autobuilder.
+
+See the "doc" and "man" subdirectories for more documentation.
+
+To include in your C programs:
+
+#include "png.h"
+
+and add the include flag
+ -ILibPNG:
+
+Link with:
+ -LLibPNG: -lpng
+
+This library requires also requires a version
+of the ZLib1g library.
Index: libraries/graphics/libpng16-16/!LibPNG/!Run,feb
===================================================================
--- libraries/graphics/libpng16-16/!LibPNG/!Run,feb (nonexistent)
+++ libraries/graphics/libpng16-16/!LibPNG/!Run,feb (working copy)
@@ -0,0 +1,6 @@
+| Run file for LibPNG
+
+IconSprites <Obey$Dir>.!Sprites
+
+Set LibPNG$Dir <Obey$Dir>
+Set LibPNG$Path <Obey$Dir>.,<Obey$Dir>.libpng16.
Index: libraries/graphics/libpng16-16/!LibPNG/!Sprites,ff9
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: libraries/graphics/libpng16-16/!LibPNG/!Sprites,ff9
===================================================================
--- libraries/graphics/libpng16-16/!LibPNG/!Sprites,ff9 (nonexistent)
+++ libraries/graphics/libpng16-16/!LibPNG/!Sprites,ff9 (working copy)
===================================================================
--- browser/firefox2/depends (revision 7206)
+++ browser/firefox2/depends (working copy)
@@ -6,5 +6,5 @@
libexpat1
libidl
libjpeg8
-libpng12-0
+libpng16-16
zlib1g
Index: browser/firefox2-riscpc/depends
===================================================================
--- browser/firefox2-riscpc/depends (revision 7206)
+++ browser/firefox2-riscpc/depends (working copy)
@@ -6,5 +6,5 @@
libexpat1
libidl
libjpeg8
-libpng12-0
+libpng16-16
zlib1g
Index: browser/otterbrowser/setvars
===================================================================
--- browser/otterbrowser/setvars (revision 7206)
+++ browser/otterbrowser/setvars (working copy)
@@ -30,7 +30,7 @@
$AB_HOME/add-riscpkg -copyrightfile COPYING -package otter-browser -name Otter-browser \
-depends SharedLibs-C++2 -depends Qt5Webkit \
- -depends Qt5Svg -depends Qt5XmlPatterns -depends LibPNG12-0 \
+ -depends Qt5Svg -depends Qt5XmlPatterns -depends LibPNG16-16 \
-depends ZLib1g -depends LibJPEG8 -depends LibSQLite3 -depends LibPcre3 \
-depends LibFontConfig1 -depends LibFreeType6 -depends LibExpat1 -depends LibGCrypt20 \
-depends LibGPG-Error -depends LibICU52 -depends LibSSL -depver 1.0.2d-2 -depends LibLevelDB \
Index: browser/qupzilla/setvars
===================================================================
--- browser/qupzilla/setvars (revision 7206)
+++ browser/qupzilla/setvars (working copy)
@@ -36,7 +36,7 @@
$AB_HOME/add-riscpkg -copyrightfile COPYRIGHT -package qupzilla -name QupZilla \
-depends SharedLibs-C++2 -depends Qt5Webkit \
- -depends Qt5Svg -depends Qt5XmlPatterns -depends LibPNG12-0 \
+ -depends Qt5Svg -depends Qt5XmlPatterns -depends LibPNG16-16 \
-depends ZLib1g -depends LibJPEG8 -depends LibSQLite3 -depends LibPcre3 \
-depends LibFontConfig1 -depends LibFreeType6 -depends LibExpat1 \
-depends LibICU52 -depends LibSSL -depver 1.0.2d-2 -depends LibLevelDB \
Index: games/neverball/depends
===================================================================
--- games/neverball/depends (revision 7206)
+++ games/neverball/depends (working copy)
@@ -1,5 +1,5 @@
gettext
libsdl2
-libpng12-0
+libpng16-16
libsdl2-ttf
libvorbis0a
Index: graphics/gnuplot/depends
===================================================================
--- graphics/gnuplot/depends (revision 7206)
+++ graphics/gnuplot/depends (working copy)
@@ -1,4 +1,4 @@
libgd2
-libpng12-0
+libpng16-16
zlib1g
oslib
\ No newline at end of file
Index: libraries/Qt/Qt5Base/ReadMe
===================================================================
--- libraries/Qt/Qt5Base/ReadMe (revision 7206)
+++ libraries/Qt/Qt5Base/ReadMe (working copy)
@@ -8,7 +8,7 @@
Library dependencies:
libz
-libpng12
+libpng16
icu (libicui18n, libicuuc, libicudata)
libfontconfig
libfreetype
Index: libraries/Qt/Qt5Base/depends
===================================================================
--- libraries/Qt/Qt5Base/depends (revision 7206)
+++ libraries/Qt/Qt5Base/depends (working copy)
@@ -1,4 +1,4 @@
-libpng12-0
+libpng16-16
oslib
libjpeg8
libsqlite3-0
Index: libraries/Qt/Qt5Base/mkspecs.arm-riscos-clang.qmake.conf
===================================================================
--- libraries/Qt/Qt5Base/mkspecs.arm-riscos-clang.qmake.conf (revision 7206)
+++ libraries/Qt/Qt5Base/mkspecs.arm-riscos-clang.qmake.conf (working copy)
@@ -13,7 +13,7 @@
QMAKE_INCDIR = $(GCCSDK_INSTALL_ENV)/include
QMAKE_LIBDIR = $(GCCSDK_INSTALL_ENV)/lib
-QMAKE_LIBS = -ldl -lz -lpng12 -lOSLib32
+QMAKE_LIBS = -ldl -lz -lpng16 -lOSLib32
QMAKE_CFLAGS_STATIC_LIB =
QMAKE_CFLAGS_APP =
Index: libraries/Qt/Qt5Base/mkspecs.arm-riscos-g++.qmake.conf
===================================================================
--- libraries/Qt/Qt5Base/mkspecs.arm-riscos-g++.qmake.conf (revision 7206)
+++ libraries/Qt/Qt5Base/mkspecs.arm-riscos-g++.qmake.conf (working copy)
@@ -13,7 +13,7 @@
QMAKE_INCDIR = $(GCCSDK_INSTALL_ENV)/include
QMAKE_LIBDIR = $(GCCSDK_INSTALL_ENV)/lib
-QMAKE_LIBS = -ldl -lz -lpng12 -lOSLib32 -Wl,-rpath-link,$(GCCSDK_INSTALL_ENV)/lib
+QMAKE_LIBS = -ldl -lz -lpng16 -lOSLib32 -Wl,-rpath-link,$(GCCSDK_INSTALL_ENV)/lib
QMAKE_CFLAGS_STATIC_LIB =
QMAKE_CFLAGS_APP =
Index: libraries/Qt/Qt5Base/mkspecs.arm-riscos-vfp-g++.qmake.conf
===================================================================
--- libraries/Qt/Qt5Base/mkspecs.arm-riscos-vfp-g++.qmake.conf (revision 7206)
+++ libraries/Qt/Qt5Base/mkspecs.arm-riscos-vfp-g++.qmake.conf (working copy)
@@ -14,7 +14,7 @@
QMAKE_INCDIR = $(GCCSDK_INSTALL_ENV)/vfp/include $(GCCSDK_INSTALL_ENV)/include
QMAKE_LIBDIR = $(GCCSDK_INSTALL_ENV)/vfp/lib $(GCCSDK_INSTALL_ENV)/lib
-#QMAKE_LIBS = -ldl -lz -lpng12
+#QMAKE_LIBS = -ldl -lz -lpng16
QMAKE_LFLAGS += -mfpu=vfp
QMAKE_RPATHLINKDIR += :$(GCCSDK_INSTALL_ENV)/vfp/lib:$(GCCSDK_INSTALL_ENV)/lib
Index: libraries/Qt/Qt5Base/setvars
===================================================================
--- libraries/Qt/Qt5Base/setvars (revision 7206)
+++ libraries/Qt/Qt5Base/setvars (working copy)
@@ -197,7 +197,7 @@
AB_COMPONENTS=""
$AB_HOME/add-riscpkg -package qt5base -name Qt5Base \
- -depends SharedLibs -depends LibPNG12-0 -depends ZLib1g \
+ -depends SharedLibs -depends LibPNG16-16 -depends ZLib1g \
-depends LibJPEG8 -depends LibSQLite3 -depends LibPcre3 \
-depends LibFontConfig1 -depends LibFreeType6 -depends LibExpat1 \
-depends LibICU52 -depends LibSSL \
Index: libraries/Qt/Qt5Webkit/!QtTestBrowser/!ReadMe
===================================================================
--- libraries/Qt/Qt5Webkit/!QtTestBrowser/!ReadMe (revision 7206)
+++ libraries/Qt/Qt5Webkit/!QtTestBrowser/!ReadMe (working copy)
@@ -16,7 +16,7 @@
Qt5Base
LevelDB
libz
-libpng12
+libpng16
icu (libicui18n, libicuuc, libicudata)
libfontconfig
libfreetype
Index: libraries/graphics/libpng16-16/!LibPNG/!Boot,feb
===================================================================
--- libraries/graphics/libpng16-16/!LibPNG/!Boot,feb (nonexistent)
+++ libraries/graphics/libpng16-16/!LibPNG/!Boot,feb (working copy)
@@ -0,0 +1,6 @@
+| Boot file for LibPNG
+|
+If "<LibPNG$Dir>" = "" Then Set LibPNG$Dir <Obey$Dir>
+If "<LibPNG$Path>" = "" Then Set LibPNG$Path <Obey$Dir>.,<Obey$Dir>.libpng16.
+
+IconSprites <LibPNG$Dir>.!Sprites
Index: libraries/graphics/libpng16-16/!LibPNG/!Help
===================================================================
--- libraries/graphics/libpng16-16/!LibPNG/!Help (nonexistent)
+++ libraries/graphics/libpng16-16/!LibPNG/!Help (working copy)
@@ -0,0 +1,19 @@
+LibPNG - Portable Network Graphics Library
+
+This RISC OS version was created by the GCCSDK
+Autobuilder.
+
+See the "doc" and "man" subdirectories for more documentation.
+
+To include in your C programs:
+
+#include "png.h"
+
+and add the include flag
+ -ILibPNG:
+
+Link with:
+ -LLibPNG: -lpng
+
+This library requires also requires a version
+of the ZLib1g library.
Index: libraries/graphics/libpng16-16/!LibPNG/!Run,feb
===================================================================
--- libraries/graphics/libpng16-16/!LibPNG/!Run,feb (nonexistent)
+++ libraries/graphics/libpng16-16/!LibPNG/!Run,feb (working copy)
@@ -0,0 +1,6 @@
+| Run file for LibPNG
+
+IconSprites <Obey$Dir>.!Sprites
+
+Set LibPNG$Dir <Obey$Dir>
+Set LibPNG$Path <Obey$Dir>.,<Obey$Dir>.libpng16.
Index: libraries/graphics/libpng16-16/!LibPNG/!Sprites,ff9
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: libraries/graphics/libpng16-16/!LibPNG/!Sprites,ff9
===================================================================
--- libraries/graphics/libpng16-16/!LibPNG/!Sprites,ff9 (nonexistent)
+++ libraries/graphics/libpng16-16/!LibPNG/!Sprites,ff9 (working copy)
Property changes on: libraries/graphics/libpng16-16/!LibPNG/!Sprites,ff9
___________________________________________________________________
Added: svn:mime-type
## -0,0 +1 ##
+application/octet-stream
\ No newline at end of property
Index: libraries/graphics/libpng16-16/depends
===================================================================
--- libraries/graphics/libpng16-16/depends (nonexistent)
+++ libraries/graphics/libpng16-16/depends (working copy)
@@ -0,0 +1 @@
+zlib1g
Index: libraries/graphics/libpng16-16/preprocess
===================================================================
--- libraries/graphics/libpng16-16/preprocess (nonexistent)
+++ libraries/graphics/libpng16-16/preprocess (working copy)
@@ -0,0 +1,2 @@
+png_version=$(echo $AB_FULLNAME | sed -e s#$AB_PACKAGE-## -e "s/[^-]*-//" -e "s/~//")
+wget -qO- https://sourceforge.net/projects/libpng-apng/files/libpng16/$png_version/libpng-$png_version-apng.patch.gz/download | gzip -d | patch -p1
Index: libraries/graphics/libpng16-16/scripts.makefile.gcc.gccsdk-3.4.6.p
===================================================================
--- libraries/graphics/libpng16-16/scripts.makefile.gcc.gccsdk-3.4.6.p (nonexistent)
+++ libraries/graphics/libpng16-16/scripts.makefile.gcc.gccsdk-3.4.6.p (working copy)
@@ -0,0 +1,28 @@
+--- scripts/makefile.gcc.orig 2008-05-28 04:12:37.000000000 +0200
++++ scripts/makefile.gcc 2008-05-28 04:14:03.000000000 +0200
+@@ -4,8 +4,8 @@
+ # For conditions of distribution and use, see copyright notice in png.h
+
+ # Location of the zlib library and include files
+-ZLIBINC = ../zlib
+-ZLIBLIB = ../zlib
++ZLIBINC = $(GCCSDK_INSTALL_ENV)/include
++ZLIBLIB = $(GCCSDK_INSTALL_ENV)/lib
+
+ # Compiler, linker, lib and other tools
+ CC = gcc
+@@ -51,6 +51,14 @@
+ $(AR_RC) $@ $(OBJS)
+ $(RANLIB) $@
+
++install:
++ mkdir -p $(GCCSDK_INSTALL_ENV)/lib/pkgconfig
++ cp libpng$(A) $(GCCSDK_INSTALL_ENV)/lib
++ cp libpng.pc $(GCCSDK_INSTALL_ENV)/lib/pkgconfig
++ mkdir -p $(GCCSDK_INSTALL_ENV)/include/libpng16
++ cp png.h pngconf.h $(GCCSDK_INSTALL_ENV)/include/libpng16
++ cp png.h pngconf.h $(GCCSDK_INSTALL_ENV)/include
++
+ test: pngtest$(EXEEXT)
+ ./pngtest$(EXEEXT)
+
Index: libraries/graphics/libpng16-16/setvars
===================================================================
--- libraries/graphics/libpng16-16/setvars (nonexistent)
+++ libraries/graphics/libpng16-16/setvars (working copy)
@@ -0,0 +1,51 @@
+AB_ROVERSION=3
+AB_INSTALL=yes
+
+export ECHO=echo
+
+ab_make() {
+ if [ "$AB_ELFBUILD" != "yes" ] ; then
+ # GCCSDK 3.4.6 support
+ cp scripts/makefile.gcc Makefile
+ fi
+ $AB_MAKE
+}
+
+ab_package() {
+ ab_create_app LibPNG Apps/Library libpng16-dev
+
+ cat $S/libpng-manual.txt >> $A/\!Help,fff
+
+ HERE=`pwd`
+ cd $A
+
+ unzip $AB_OUTPUTLIB/$RO_PKG.zip
+
+ mv include/libpng16 libpng16
+ rm -rf include
+
+ mv lib/*.a .
+ rm -rf lib
+
+ cd doc
+ docdir=`echo *`
+ mv $docdir/* .
+ rm -rf $docdir
+
+ rm -rf bin
+
+ cd $HERE
+
+ # Downloaded version can include a character that is invalid
+ # for a riscpkg version number so replace it
+ AB_PVERSION=`echo "$AB_PVERSION" | sed "s/~/-/"`
+
+ $AB_HOME/add-riscpkg -unixlib -name LibPNG16-Dev -depends "ZLib1g-Dev"
+
+ if [ "$RO_SHAREDLIBS" == "yes" ] ; then
+ ab_create_sharedlib_skeleton libpng16-16
+ ab_add_sharedlib $S/.libs libpng16.so.16
+
+ $AB_HOME/add-riscpkg -package libpng16-16 -name LibPNG16-16 -depends "ZLib1g"
+ fi
+}
Index: libraries/gtk/cairo-gtk2/depends
===================================================================
--- libraries/gtk/cairo-gtk2/depends (revision 7206)
+++ libraries/gtk/cairo-gtk2/depends (working copy)
@@ -2,6 +2,6 @@
libfontconfig1
zlib1g
libxrender1
-libpng12-0
+libpng16-16
libpixman-1-0
libexpat1
Index: libraries/gtk/harfbuzz/depends
===================================================================
--- libraries/gtk/harfbuzz/depends (revision 7206)
+++ libraries/gtk/harfbuzz/depends (working copy)
@@ -1,5 +1,5 @@
zlib1g
-libpng12-0
+libpng16-16
libfreetype6
libglib2.0-0
libpcre3
Index: libraries/gtk/libcairo2/depends
===================================================================
--- libraries/gtk/libcairo2/depends (revision 7206)
+++ libraries/gtk/libcairo2/depends (working copy)
@@ -1,5 +1,5 @@
zlib1g
-libpng12-0
+libpng16-16
libpixman-1-0
gdk-pixbuf
fontconfig
Index: libraries/gtk/libcairo2/setvars
===================================================================
--- libraries/gtk/libcairo2/setvars (revision 7206)
+++ libraries/gtk/libcairo2/setvars (working copy)
@@ -53,7 +53,7 @@
$AB_HOME/add-riscpkg -package "libcairo2" -name LibCairo2 \
-depends SharedLibs -depends LibFontConfig1 -depends LibFreeType6 \
- -depends LibPixman-1-0 -depends LibPNG12-0 -suggests UnixFont
+ -depends LibPixman-1-0 -depends LibPNG16-16 -suggests UnixFont
# Don't overwrite the original !SharedLibs.!Boot.
fi
Index: libraries/gtk/libpango1.0-0/depends
===================================================================
--- libraries/gtk/libpango1.0-0/depends (revision 7206)
+++ libraries/gtk/libpango1.0-0/depends (working copy)
@@ -6,6 +6,6 @@
libffi5
gettext
libpixman-1-0
-libpng12-0
+libpng16-16
zlib1g
harfbuzz
Index: libraries/libfreetype6/depends
===================================================================
--- libraries/libfreetype6/depends (revision 7206)
+++ libraries/libfreetype6/depends (working copy)
@@ -1,3 +1,3 @@
-libpng12-0
+libpng16-16
libbz2-1.0
zlib1g
Index: libraries/libfreetype6/setvars
===================================================================
--- libraries/libfreetype6/setvars (revision 7206)
+++ libraries/libfreetype6/setvars (working copy)
@@ -50,7 +50,8 @@
cd $HERE
$AB_HOME/add-riscpkg -package libfreetype6-dev -name LibFreeType6-Dev -unixlib \
- -depends "ZLib1g-Dev" -depends "LibBZ2-Dev" -copyrightfile $S/docs/GPLv2.TXT
+ -depends "ZLib1g-Dev" -depends "LibBZ2-Dev" -depends "LibPNG16-Dev" \
+ -copyrightfile $S/docs/GPLv2.TXT
if [ "$RO_SHAREDLIBS" == "yes" ] ; then
ab_create_sharedlib_skeleton libfreetype6
@@ -57,7 +58,7 @@
ab_add_sharedlib $S/objs/.libs libfreetype.so.6
$AB_HOME/add-riscpkg -package libfreetype6 -name LibFreeType6 -section Library \
- -depends ZLib1g -depends LibBZ2-1.0 -depends LibPNG12-0 -copyrightfile $S/docs/GPLv2.TXT
+ -depends ZLib1g -depends LibBZ2-1.0 -depends LibPNG16-16 -copyrightfile $S/docs/GPLv2.TXT
fi
}
Index: libraries/libharu/depends
===================================================================
--- libraries/libharu/depends (revision 7206)
+++ libraries/libharu/depends (working copy)
@@ -1,3 +1,3 @@
zlib1g
-libpng12-0
+libpng16-16
Index: libraries/riscos/netsurf-libraries/depends
===================================================================
--- libraries/riscos/netsurf-libraries/depends (revision 7206)
+++ libraries/riscos/netsurf-libraries/depends (working copy)
@@ -3,11 +3,10 @@
libssl1.0.2
libcurl3
libjpeg8
-libpng12-0
+libpng16-16
libmng1
libexpat1
oslib
-buildsystem
libnsbmp
libnsgif
libwapcaplet
Index: libraries/sdl/libsdl-image1.2/setvars
===================================================================
--- libraries/sdl/libsdl-image1.2/setvars (revision 7206)
+++ libraries/sdl/libsdl-image1.2/setvars (working copy)
@@ -30,6 +30,6 @@
cp $S/showimage$AB_EXEEXT $A
$AB_HOME/add-riscpkg -unixlib -name LibSDLImage1.2-Dev \
- -depends "LibJPEG8-Dev" -depends "LibPNG12-Dev" \
+ -depends "LibJPEG8-Dev" -depends "LibPNG16-Dev" \
-depends "LibTIFF5-Dev" -depends "LibSDL1.2-Dev"
}
Index: libraries/sdl/libsdl-ttf2.0-0/depends
===================================================================
--- libraries/sdl/libsdl-ttf2.0-0/depends (revision 7206)
+++ libraries/sdl/libsdl-ttf2.0-0/depends (working copy)
@@ -1,5 +1,5 @@
libfreetype6
libsdl1.2debian
-libpng12-0
+libpng16-16
libjpeg8
libtiff5
Index: libraries/sdl/libsdl1.2debian/depends
===================================================================
--- libraries/sdl/libsdl1.2debian/depends (revision 7206)
+++ libraries/sdl/libsdl1.2debian/depends (working copy)
@@ -1,4 +1,4 @@
libjpeg8
libtiff5
-libpng12-0
+libpng16-16
zlib1g
Index: libraries/sdl/libsdl2-ttf/depends
===================================================================
--- libraries/sdl/libsdl2-ttf/depends (revision 7206)
+++ libraries/sdl/libsdl2-ttf/depends (working copy)
@@ -1,4 +1,4 @@
libsdl2
-libpng12-0
+libpng16-16
libfreetype6
zlib1g
Index: libraries/sdl/libsdl2-ttf/setvars
===================================================================
--- libraries/sdl/libsdl2-ttf/setvars (revision 7206)
+++ libraries/sdl/libsdl2-ttf/setvars (working copy)
@@ -20,7 +20,7 @@
AB_COMPONENTS=""
$AB_HOME/add-riscpkg -name LibSDL2-ttf -section Library -package libsdl2-ttf \
-depends LibSDL2 -depends SharedLibs-C2 -depends LibFreeType6 \
- -depends LibPNG12-0 -depends ZLib1g
+ -depends LibPNG16-16 -depends ZLib1g
fi
ab_create_app LibSDL2-ttf-Dev Apps/Library libsdl2-ttf-dev
Index: network/thunderbird2/depends
===================================================================
--- network/thunderbird2/depends (revision 7206)
+++ network/thunderbird2/depends (working copy)
@@ -6,5 +6,5 @@
libexpat1
libidl
libjpeg8
-libpng12-0
+libpng16-16
zlib1g
Hi
Attached is a patch to update libpng to the latest version. To simplify the patch, this adds a separate recipe for the new version, rather than attempting to rename the old recipe. I haven't tested every program that requires libpng, however, I've been using this patch for several months now and haven't encountered any problems, so this should hopefully be fine.
Best regards
Cameron
Subscribe to:
Posts (Atom)