Hello
Thx for the fastest almost-full-featured web-browser in existence!
Just wondering if there's any development happening, particularly wrt
javascript.
thx!
Monday, 29 June 2015
Re: [gccsdk] Unable to load Shared library with GCC 4.7.4.1
Oops!, I forgot to change the subject heading to something meaningful.
On Mon, June 29, 2015 8:00 pm, Lee Noar <leenoar@sky.com> wrote:
>> I set an <appname>$LD$ENV variable for each application that uses the
>> library. It is usually just set to "LD_LIBRARY_PATH=DRW:" but can also
>> include path variables to any application specific shared libraries.
>
> It looks like I may have made a mistake in r6733 from about a year ago
> when dealing with LD_LIBRARY_PATH.
> If I email you a new dynamic linker, can you try it and see if it fixes
> your problem?
>
Yes that is a good idea.
Regards,
Pete Miller.
_______________________________________________
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 Mon, June 29, 2015 8:00 pm, Lee Noar <leenoar@sky.com> wrote:
>> I set an <appname>$LD$ENV variable for each application that uses the
>> library. It is usually just set to "LD_LIBRARY_PATH=DRW:" but can also
>> include path variables to any application specific shared libraries.
>
> It looks like I may have made a mistake in r6733 from about a year ago
> when dealing with LD_LIBRARY_PATH.
> If I email you a new dynamic linker, can you try it and see if it fixes
> your problem?
>
Yes that is a good idea.
Regards,
Pete Miller.
_______________________________________________
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] gcc Digest, Vol 103, Issue 5
On Mon, June 29, 2015 8:00 pm, Lee Noar <leenoar@sky.com> wrote:
>> I set an <appname>$LD$ENV variable for each application that uses the
>> library. It is usually just set to "LD_LIBRARY_PATH=DRW:" but can also
>> include path variables to any application specific shared libraries.
>
> It looks like I may have made a mistake in r6733 from about a year ago
> when dealing with LD_LIBRARY_PATH.
> If I email you a new dynamic linker, can you try it and see if it fixes
> your problem?
>
Yes that is a good idea.
Regards,
Pete Miller.
_______________________________________________
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 set an <appname>$LD$ENV variable for each application that uses the
>> library. It is usually just set to "LD_LIBRARY_PATH=DRW:" but can also
>> include path variables to any application specific shared libraries.
>
> It looks like I may have made a mistake in r6733 from about a year ago
> when dealing with LD_LIBRARY_PATH.
> If I email you a new dynamic linker, can you try it and see if it fixes
> your problem?
>
Yes that is a good idea.
Regards,
Pete Miller.
_______________________________________________
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] fontconfig build issue
On Mon, Jun 29, 2015 at 09:15:10PM +0100, Lee Noar wrote:
> John Ballance wrote:
> >p.s. I'm building quite a list of things where I have local patches to
> >the autobuilder scripts. Should theyy all come through you, or might it
> >be simpler if I put them in directly? (I guess I'm also asking whether
> >that could be arranged..)
>
> I think it's John Tytgat and Theo who have the power to give svn
> write access.
It's possible to allow write access, but it might be good if you posted
the patches here to begin with, just to make sure we're on the same page.
There are lots of moving parts to the autobuilder and (currently) we aren't
testing them all very regularly, so a little care is required in that
changing one thing to fix a problem here may cause issues for another
package over there. We can usually spot that by glancing over the code but
it might be something that might not be obvious if you aren't familiar with
some of the other packages.
As previously mentioned, just posting them to the list as attachments is
sufficient. If you want to get high tech (and don't mind dealing with
another version control system), git interfaces nicely with svn, handles
commits locally and will generate patch emails automatically.
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
> John Ballance wrote:
> >p.s. I'm building quite a list of things where I have local patches to
> >the autobuilder scripts. Should theyy all come through you, or might it
> >be simpler if I put them in directly? (I guess I'm also asking whether
> >that could be arranged..)
>
> I think it's John Tytgat and Theo who have the power to give svn
> write access.
It's possible to allow write access, but it might be good if you posted
the patches here to begin with, just to make sure we're on the same page.
There are lots of moving parts to the autobuilder and (currently) we aren't
testing them all very regularly, so a little care is required in that
changing one thing to fix a problem here may cause issues for another
package over there. We can usually spot that by glancing over the code but
it might be something that might not be obvious if you aren't familiar with
some of the other packages.
As previously mentioned, just posting them to the list as attachments is
sufficient. If you want to get high tech (and don't mind dealing with
another version control system), git interfaces nicely with svn, handles
commits locally and will generate patch emails automatically.
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] fontconfig build issue
On 29/06/15 20:26, John Ballance wrote:
> Hi
>
> On 29/06/2015 20:11, Lee Noar wrote:
>> On 29/06/15 19:05, John Ballance wrote:
>>> Hi Lee
[snip]
>>> Probably something simple that I'm missing, but the libfontconfig1
>>> directory
>>> doesn't exist in the package directory at this point.
>>
>> Are you building shared libraries? libfontconfig1 is the shared library
> I will need to build shared libraries, but at this stage not sure. I'll
> try again with the libfontconfig1 removed from the AB line
>
> .. build does complete, thanks
>
> shared libraries. ... I've missed this.. how do I globally turn on the
> build of shared libraries please?
In the directory where you build the packages, create a text file called:
build-setvars
containing the line:
RO_SHAREDLIBS=yes
So, for example, I have this:
autobuilder
|
autobuilt
| |
| build-setvars
|
cross
|
env
|
gcc4
where autobuilt is a directory I created myself to build the packages
in. I then do:
cd autobuilt
../autobuilder/build -d fontconfig
The autobuilder automatically reads the build-setvars file each time
it's invoked so shared libraries are always enabled.
> Thanks
> John
>
> p.s. I'm building quite a list of things where I have local patches to
> the autobuilder scripts. Should theyy all come through you, or might it
> be simpler if I put them in directly? (I guess I'm also asking whether
> that could be arranged..)
I think it's John Tytgat and Theo who have the power to give svn write
access.
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
>
> On 29/06/2015 20:11, Lee Noar wrote:
>> On 29/06/15 19:05, John Ballance wrote:
>>> Hi Lee
[snip]
>>> Probably something simple that I'm missing, but the libfontconfig1
>>> directory
>>> doesn't exist in the package directory at this point.
>>
>> Are you building shared libraries? libfontconfig1 is the shared library
> I will need to build shared libraries, but at this stage not sure. I'll
> try again with the libfontconfig1 removed from the AB line
>
> .. build does complete, thanks
>
> shared libraries. ... I've missed this.. how do I globally turn on the
> build of shared libraries please?
In the directory where you build the packages, create a text file called:
build-setvars
containing the line:
RO_SHAREDLIBS=yes
So, for example, I have this:
autobuilder
|
autobuilt
| |
| build-setvars
|
cross
|
env
|
gcc4
where autobuilt is a directory I created myself to build the packages
in. I then do:
cd autobuilt
../autobuilder/build -d fontconfig
The autobuilder automatically reads the build-setvars file each time
it's invoked so shared libraries are always enabled.
> Thanks
> John
>
> p.s. I'm building quite a list of things where I have local patches to
> the autobuilder scripts. Should theyy all come through you, or might it
> be simpler if I put them in directly? (I guess I'm also asking whether
> that could be arranged..)
I think it's John Tytgat and Theo who have the power to give svn write
access.
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] fontconfig build issue
Hi
.. build does complete, thanks
shared libraries. ... I've missed this.. how do I globally turn on the build of shared libraries please?
Thanks
John
p.s. I'm building quite a list of things where I have local patches to the autobuilder scripts. Should theyy all come through you, or might it be simpler if I put them in directly? (I guess I'm also asking whether that could be arranged..)
On 29/06/2015 20:11, Lee Noar wrote:
On 29/06/15 19:05, John Ballance wrote:I will need to build shared libraries, but at this stage not sure. I'll try again with the libfontconfig1 removed from the AB line
Hi Lee
Thanks for the check. begs the Q of what it may be...
I did then try the --disable-docs which did bypass that issue, then
grumble in the riscpkg stage:
add-riscpkg: Adding files for the RISC OS Packaging Project
add-riskpkg: Using Debian description
add-riscpkg: Setting filetypes...
add-riskpkg: Finished
Autobuilder: Packaging files
Autobuilder: Packaging as fontconfig-config
-rw-rw-rw- 1 jb jb 88085 Jun 29 19:00
/home/jb/GCCSDK471/autobuilder/autobuilder_packages/Fonts/fontconfig-config_2.11.0-1.zip
Autobuilder: Packaging as fontconfig
-rw-rw-rw- 1 jb jb 5704386 Jun 29 19:00
/home/jb/GCCSDK471/autobuilder/autobuilder_packages/Fonts/fontconfig_2.11.0-1.zip
Autobuilder: Packaging as libfontconfig1-dev
-rw-rw-rw- 1 jb jb 860002 Jun 29 19:00
/home/jb/GCCSDK471/autobuilder/autobuilder_packages/Library/libfontconfig1-dev_2.11.0-1.zip
Autobuilder: Packaging as libfontconfig1
Autobuilder: package directory missing libfontconfig1
Package fontconfig: ***Failure***
Build for package "fontconfig" failed
Probably something simple that I'm missing, but the libfontconfig1 directory
doesn't exist in the package directory at this point.
Are you building shared libraries? libfontconfig1 is the shared library
.. build does complete, thanks
shared libraries. ... I've missed this.. how do I globally turn on the build of shared libraries please?
Thanks
John
p.s. I'm building quite a list of things where I have local patches to the autobuilder scripts. Should theyy all come through you, or might it be simpler if I put them in directly? (I guess I'm also asking whether that could be arranged..)
package and is only created if shared libraries are enabled. The
autobuilder expects to always find it though because it's mentioned at
the top of setvars in AB_PACKAGES. I guess I need to set AB_PACKAGES
here according to whether shared libraries are enabled or not.
IS there any AB type definition that brings in the native cc compiler,
not the arm one?
No I don't think so, because the autobuilder doesn't know which compiler
to use when. Sometimes the package authors will specifically support
cross compiling and allow you to set HOST_CC. Sometimes you have to
configure and build the package twice (in setvars) for native and
RISC OS to get native compiled tools.
In this case though all the html documentation files seem to be
present in doc/fontconfig-devel even with --disable-doc (in fact
the debian patch adds them), so I'll alter setvars to add this
option and fix AB_PACKAGES as above.
Lee.
--
Stop press! Just announced -
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Re: [gccsdk] fontconfig build issue
On 29/06/15 19:05, John Ballance wrote:
> Hi Lee
>
> Thanks for the check. begs the Q of what it may be...
>
> I did then try the --disable-docs which did bypass that issue, then
> grumble in the riscpkg stage:
>
> add-riscpkg: Adding files for the RISC OS Packaging Project
> add-riskpkg: Using Debian description
> add-riscpkg: Setting filetypes...
> add-riskpkg: Finished
> Autobuilder: Packaging files
> Autobuilder: Packaging as fontconfig-config
> -rw-rw-rw- 1 jb jb 88085 Jun 29 19:00
> /home/jb/GCCSDK471/autobuilder/autobuilder_packages/Fonts/fontconfig-config_2.11.0-1.zip
> Autobuilder: Packaging as fontconfig
> -rw-rw-rw- 1 jb jb 5704386 Jun 29 19:00
> /home/jb/GCCSDK471/autobuilder/autobuilder_packages/Fonts/fontconfig_2.11.0-1.zip
> Autobuilder: Packaging as libfontconfig1-dev
> -rw-rw-rw- 1 jb jb 860002 Jun 29 19:00
> /home/jb/GCCSDK471/autobuilder/autobuilder_packages/Library/libfontconfig1-dev_2.11.0-1.zip
> Autobuilder: Packaging as libfontconfig1
> Autobuilder: package directory missing libfontconfig1
> Package fontconfig: ***Failure***
> Build for package "fontconfig" failed
>
>
> Probably something simple that I'm missing, but the libfontconfig1 directory
> doesn't exist in the package directory at this point.
Are you building shared libraries? libfontconfig1 is the shared library
package and is only created if shared libraries are enabled. The
autobuilder expects to always find it though because it's mentioned at
the top of setvars in AB_PACKAGES. I guess I need to set AB_PACKAGES
here according to whether shared libraries are enabled or not.
> IS there any AB type definition that brings in the native cc compiler,
> not the arm one?
No I don't think so, because the autobuilder doesn't know which compiler
to use when. Sometimes the package authors will specifically support
cross compiling and allow you to set HOST_CC. Sometimes you have to
configure and build the package twice (in setvars) for native and
RISC OS to get native compiled tools.
In this case though all the html documentation files seem to be
present in doc/fontconfig-devel even with --disable-doc (in fact
the debian patch adds them), so I'll alter setvars to add this
option and fix AB_PACKAGES as above.
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 Lee
>
> Thanks for the check. begs the Q of what it may be...
>
> I did then try the --disable-docs which did bypass that issue, then
> grumble in the riscpkg stage:
>
> add-riscpkg: Adding files for the RISC OS Packaging Project
> add-riskpkg: Using Debian description
> add-riscpkg: Setting filetypes...
> add-riskpkg: Finished
> Autobuilder: Packaging files
> Autobuilder: Packaging as fontconfig-config
> -rw-rw-rw- 1 jb jb 88085 Jun 29 19:00
> /home/jb/GCCSDK471/autobuilder/autobuilder_packages/Fonts/fontconfig-config_2.11.0-1.zip
> Autobuilder: Packaging as fontconfig
> -rw-rw-rw- 1 jb jb 5704386 Jun 29 19:00
> /home/jb/GCCSDK471/autobuilder/autobuilder_packages/Fonts/fontconfig_2.11.0-1.zip
> Autobuilder: Packaging as libfontconfig1-dev
> -rw-rw-rw- 1 jb jb 860002 Jun 29 19:00
> /home/jb/GCCSDK471/autobuilder/autobuilder_packages/Library/libfontconfig1-dev_2.11.0-1.zip
> Autobuilder: Packaging as libfontconfig1
> Autobuilder: package directory missing libfontconfig1
> Package fontconfig: ***Failure***
> Build for package "fontconfig" failed
>
>
> Probably something simple that I'm missing, but the libfontconfig1 directory
> doesn't exist in the package directory at this point.
Are you building shared libraries? libfontconfig1 is the shared library
package and is only created if shared libraries are enabled. The
autobuilder expects to always find it though because it's mentioned at
the top of setvars in AB_PACKAGES. I guess I need to set AB_PACKAGES
here according to whether shared libraries are enabled or not.
> IS there any AB type definition that brings in the native cc compiler,
> not the arm one?
No I don't think so, because the autobuilder doesn't know which compiler
to use when. Sometimes the package authors will specifically support
cross compiling and allow you to set HOST_CC. Sometimes you have to
configure and build the package twice (in setvars) for native and
RISC OS to get native compiled tools.
In this case though all the html documentation files seem to be
present in doc/fontconfig-devel even with --disable-doc (in fact
the debian patch adds them), so I'll alter setvars to add this
option and fix AB_PACKAGES as above.
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] fontconfig build issue
Hi Lee
Thanks for the check. begs the Q of what it may be...
I did then try the --disable-docs which did bypass that issue, then grumble in the riscpkg stage:
add-riscpkg: Adding files for the RISC OS Packaging Project
add-riskpkg: Using Debian description
add-riscpkg: Setting filetypes...
add-riskpkg: Finished
Autobuilder: Packaging files
Autobuilder: Packaging as fontconfig-config
-rw-rw-rw- 1 jb jb 88085 Jun 29 19:00 /home/jb/GCCSDK471/autobuilder/autobuilder_packages/Fonts/fontconfig-config_2.11.0-1.zip
Autobuilder: Packaging as fontconfig
-rw-rw-rw- 1 jb jb 5704386 Jun 29 19:00 /home/jb/GCCSDK471/autobuilder/autobuilder_packages/Fonts/fontconfig_2.11.0-1.zip
Autobuilder: Packaging as libfontconfig1-dev
-rw-rw-rw- 1 jb jb 860002 Jun 29 19:00 /home/jb/GCCSDK471/autobuilder/autobuilder_packages/Library/libfontconfig1-dev_2.11.0-1.zip
Autobuilder: Packaging as libfontconfig1
Autobuilder: package directory missing libfontconfig1
Package fontconfig: ***Failure***
Build for package "fontconfig" failed
Probably something simple that I'm missing, but the libfontconfig1 directory
doesn't exist in the package directory at this point.
IS there any AB type definition that brings in the native cc compiler, not the arm one?
Tanks
John
Thanks for the check. begs the Q of what it may be...
I did then try the --disable-docs which did bypass that issue, then grumble in the riscpkg stage:
add-riscpkg: Adding files for the RISC OS Packaging Project
add-riskpkg: Using Debian description
add-riscpkg: Setting filetypes...
add-riskpkg: Finished
Autobuilder: Packaging files
Autobuilder: Packaging as fontconfig-config
-rw-rw-rw- 1 jb jb 88085 Jun 29 19:00 /home/jb/GCCSDK471/autobuilder/autobuilder_packages/Fonts/fontconfig-config_2.11.0-1.zip
Autobuilder: Packaging as fontconfig
-rw-rw-rw- 1 jb jb 5704386 Jun 29 19:00 /home/jb/GCCSDK471/autobuilder/autobuilder_packages/Fonts/fontconfig_2.11.0-1.zip
Autobuilder: Packaging as libfontconfig1-dev
-rw-rw-rw- 1 jb jb 860002 Jun 29 19:00 /home/jb/GCCSDK471/autobuilder/autobuilder_packages/Library/libfontconfig1-dev_2.11.0-1.zip
Autobuilder: Packaging as libfontconfig1
Autobuilder: package directory missing libfontconfig1
Package fontconfig: ***Failure***
Build for package "fontconfig" failed
Probably something simple that I'm missing, but the libfontconfig1 directory
doesn't exist in the package directory at this point.
IS there any AB type definition that brings in the native cc compiler, not the arm one?
Tanks
John
On 29/06/2015 16:50, Lee Noar wrote:
On 29/06/15 00:49, John Ballance wrote:
Hi
I'm trying to build fontconfig with the current cross compile toolset
(4.7.1) and the autobuilder
In the doc folder there is a thing called edit-sgml.c which should be
compiled for use on the host (compiling x86) machine, but is being
compiled into arm code.
Has anyone else met this, and more to the point, how in makefile or
makefile.am syntax do I oblige it to compile for local x86 rather than
crosscompile arm please
I've just tried a new build of fontconfig and it finished without error.
I suspect that you have a native package installed that I don't which
alters the behaviour of configure (ie, its absence on my machine makes
it skip the area you're having problems with).
Your best bet might be to configure with --disable-docs if you don't
mind not having the documentation. You would add this to AB_CONFLAGS
in setvars.
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
--
Stop press! Just announced -
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Re: [gccsdk] Unable to load Shared library with GCC 4.7.4.1
On 28/06/15 20:34, pdmiller@pdmiller1.plus.com wrote:
> On Sun, June 28, 2015 8:00 pm, Lee Noar <leenoar@sky.com> wrote:
>
>>> The path variable DRW: is set to
>>>
>>> RAM::RamDisc0.$.Resources.!DRWDEF.DRW.
>>>
>>> This setup works when compiling, linking and loading using GCC 4.1.2.
>>>
>>> Has anything changed in GCC 4.7.4.1 that means I need to change my
>>> shared
>>> library scheme to work with GCC 4.7.4.1?
>>
>> I can't see anything that would prevent a library name prefixed with
>> a path variable from working in a symlink. I did make some changes to
>> where the dynamic linker searches for libraries to support VFP, but
>> that's before symlink processing.
>>
>> Where are the symlink files stored?
>>
> They are copied to RAM::RamDisc0.$.Resources.!DRWDEF.DRW. during system
> startup.
>
> The shared library itself happens to be in the same library.
>
> I set an <appname>$LD$ENV variable for each application that uses the
> library. It is usually just set to "LD_LIBRARY_PATH=DRW:" but can also
> include path variables to any application specific shared libraries.
It looks like I may have made a mistake in r6733 from about a year ago
when dealing with LD_LIBRARY_PATH.
If I email you a new dynamic linker, can you try it and see if it fixes
your problem?
Thanks,
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 Sun, June 28, 2015 8:00 pm, Lee Noar <leenoar@sky.com> wrote:
>
>>> The path variable DRW: is set to
>>>
>>> RAM::RamDisc0.$.Resources.!DRWDEF.DRW.
>>>
>>> This setup works when compiling, linking and loading using GCC 4.1.2.
>>>
>>> Has anything changed in GCC 4.7.4.1 that means I need to change my
>>> shared
>>> library scheme to work with GCC 4.7.4.1?
>>
>> I can't see anything that would prevent a library name prefixed with
>> a path variable from working in a symlink. I did make some changes to
>> where the dynamic linker searches for libraries to support VFP, but
>> that's before symlink processing.
>>
>> Where are the symlink files stored?
>>
> They are copied to RAM::RamDisc0.$.Resources.!DRWDEF.DRW. during system
> startup.
>
> The shared library itself happens to be in the same library.
>
> I set an <appname>$LD$ENV variable for each application that uses the
> library. It is usually just set to "LD_LIBRARY_PATH=DRW:" but can also
> include path variables to any application specific shared libraries.
It looks like I may have made a mistake in r6733 from about a year ago
when dealing with LD_LIBRARY_PATH.
If I email you a new dynamic linker, can you try it and see if it fixes
your problem?
Thanks,
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] fontconfig build issue
On 29/06/15 00:49, John Ballance wrote:
> Hi
>
> I'm trying to build fontconfig with the current cross compile toolset
> (4.7.1) and the autobuilder
>
> In the doc folder there is a thing called edit-sgml.c which should be
> compiled for use on the host (compiling x86) machine, but is being
> compiled into arm code.
>
> Has anyone else met this, and more to the point, how in makefile or
> makefile.am syntax do I oblige it to compile for local x86 rather than
> crosscompile arm please
I've just tried a new build of fontconfig and it finished without error.
I suspect that you have a native package installed that I don't which
alters the behaviour of configure (ie, its absence on my machine makes
it skip the area you're having problems with).
Your best bet might be to configure with --disable-docs if you don't
mind not having the documentation. You would add this to AB_CONFLAGS
in setvars.
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'm trying to build fontconfig with the current cross compile toolset
> (4.7.1) and the autobuilder
>
> In the doc folder there is a thing called edit-sgml.c which should be
> compiled for use on the host (compiling x86) machine, but is being
> compiled into arm code.
>
> Has anyone else met this, and more to the point, how in makefile or
> makefile.am syntax do I oblige it to compile for local x86 rather than
> crosscompile arm please
I've just tried a new build of fontconfig and it finished without error.
I suspect that you have a native package installed that I don't which
alters the behaviour of configure (ie, its absence on my machine makes
it skip the area you're having problems with).
Your best bet might be to configure with --disable-docs if you don't
mind not having the documentation. You would add this to AB_CONFLAGS
in setvars.
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
Sunday, 28 June 2015
[gccsdk] fontconfig build issue
Hi
I'm trying to build fontconfig with the current cross compile toolset (4.7.1) and the autobuilder
In the doc folder there is a thing called edit-sgml.c which should be compiled for use on the host (compiling x86) machine, but is being compiled into arm code.
Has anyone else met this, and more to the point, how in makefile or makefile.am syntax do I oblige it to compile for local x86 rather than crosscompile arm please
Many thanks
John
I'm trying to build fontconfig with the current cross compile toolset (4.7.1) and the autobuilder
In the doc folder there is a thing called edit-sgml.c which should be compiled for use on the host (compiling x86) machine, but is being compiled into arm code.
Has anyone else met this, and more to the point, how in makefile or makefile.am syntax do I oblige it to compile for local x86 rather than crosscompile arm please
Many thanks
John
--
Stop press! Just announced -
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Re: [gccsdk] Unable to load Shared library with GCC 4.7.4.1
On Sun, June 28, 2015 8:00 pm, Lee Noar <leenoar@sky.com> wrote:
>> The path variable DRW: is set to
>>
>> RAM::RamDisc0.$.Resources.!DRWDEF.DRW.
>>
>> This setup works when compiling, linking and loading using GCC 4.1.2.
>>
>> Has anything changed in GCC 4.7.4.1 that means I need to change my
>> shared
>> library scheme to work with GCC 4.7.4.1?
>
> I can't see anything that would prevent a library name prefixed with
> a path variable from working in a symlink. I did make some changes to
> where the dynamic linker searches for libraries to support VFP, but
> that's before symlink processing.
>
> Where are the symlink files stored?
>
They are copied to RAM::RamDisc0.$.Resources.!DRWDEF.DRW. during system
startup.
The shared library itself happens to be in the same library.
I set an <appname>$LD$ENV variable for each application that uses the
library. It is usually just set to "LD_LIBRARY_PATH=DRW:" but can also
include path variables to any application specific shared libraries.
Regards,
Pete Miller.
_______________________________________________
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 path variable DRW: is set to
>>
>> RAM::RamDisc0.$.Resources.!DRWDEF.DRW.
>>
>> This setup works when compiling, linking and loading using GCC 4.1.2.
>>
>> Has anything changed in GCC 4.7.4.1 that means I need to change my
>> shared
>> library scheme to work with GCC 4.7.4.1?
>
> I can't see anything that would prevent a library name prefixed with
> a path variable from working in a symlink. I did make some changes to
> where the dynamic linker searches for libraries to support VFP, but
> that's before symlink processing.
>
> Where are the symlink files stored?
>
They are copied to RAM::RamDisc0.$.Resources.!DRWDEF.DRW. during system
startup.
The shared library itself happens to be in the same library.
I set an <appname>$LD$ENV variable for each application that uses the
library. It is usually just set to "LD_LIBRARY_PATH=DRW:" but can also
include path variables to any application specific shared libraries.
Regards,
Pete Miller.
_______________________________________________
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] Unable to load Shared library with GCC 4.7.4.1
On 28/06/15 13:01, pdmiller@pdmiller1.plus.com wrote:
> I am in the process of updating DrWimpC to use GCC 4.7.4.1 however,
> afterrebuilfing the shared DrWimpC library and applications that use it I
> get a message like HostFS::HardDisc4.$.Apps.!drwopen.!RunImage: can't load
> library 'libdrwlib32Gs/so/1'.
>
> The symlink files (libdrwlib32Gs/so and libdrwlib32Gs/so/1) for
> libdrwlib32Gs contain:
>
> LINK[1A][0][0][0]DRW:libdrwlib32Gs/so/1/5/0
>
> The path variable DRW: is set to
>
> RAM::RamDisc0.$.Resources.!DRWDEF.DRW.
>
> This setup works when compiling, linking and loading using GCC 4.1.2.
>
> Has anything changed in GCC 4.7.4.1 that means I need to change my shared
> library scheme to work with GCC 4.7.4.1?
I can't see anything that would prevent a library name prefixed with
a path variable from working in a symlink. I did make some changes to
where the dynamic linker searches for libraries to support VFP, but
that's before symlink processing.
Where are the symlink files stored?
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
> I am in the process of updating DrWimpC to use GCC 4.7.4.1 however,
> afterrebuilfing the shared DrWimpC library and applications that use it I
> get a message like HostFS::HardDisc4.$.Apps.!drwopen.!RunImage: can't load
> library 'libdrwlib32Gs/so/1'.
>
> The symlink files (libdrwlib32Gs/so and libdrwlib32Gs/so/1) for
> libdrwlib32Gs contain:
>
> LINK[1A][0][0][0]DRW:libdrwlib32Gs/so/1/5/0
>
> The path variable DRW: is set to
>
> RAM::RamDisc0.$.Resources.!DRWDEF.DRW.
>
> This setup works when compiling, linking and loading using GCC 4.1.2.
>
> Has anything changed in GCC 4.7.4.1 that means I need to change my shared
> library scheme to work with GCC 4.7.4.1?
I can't see anything that would prevent a library name prefixed with
a path variable from working in a symlink. I did make some changes to
where the dynamic linker searches for libraries to support VFP, but
that's before symlink processing.
Where are the symlink files stored?
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
[gccsdk] Unable to load Shared library with GCC 4.7.4.1
I am in the process of updating DrWimpC to use GCC 4.7.4.1 however,
afterrebuilfing the shared DrWimpC library and applications that use it I
get a message like HostFS::HardDisc4.$.Apps.!drwopen.!RunImage: can't load
library 'libdrwlib32Gs/so/1'.
The symlink files (libdrwlib32Gs/so and libdrwlib32Gs/so/1) for
libdrwlib32Gs contain:
LINK[1A][0][0][0]DRW:libdrwlib32Gs/so/1/5/0
The path variable DRW: is set to
RAM::RamDisc0.$.Resources.!DRWDEF.DRW.
This setup works when compiling, linking and loading using GCC 4.1.2.
Has anything changed in GCC 4.7.4.1 that means I need to change my shared
library scheme to work with GCC 4.7.4.1?
Regards,
Pete Miller.
_______________________________________________
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
afterrebuilfing the shared DrWimpC library and applications that use it I
get a message like HostFS::HardDisc4.$.Apps.!drwopen.!RunImage: can't load
library 'libdrwlib32Gs/so/1'.
The symlink files (libdrwlib32Gs/so and libdrwlib32Gs/so/1) for
libdrwlib32Gs contain:
LINK[1A][0][0][0]DRW:libdrwlib32Gs/so/1/5/0
The path variable DRW: is set to
RAM::RamDisc0.$.Resources.!DRWDEF.DRW.
This setup works when compiling, linking and loading using GCC 4.1.2.
Has anything changed in GCC 4.7.4.1 that means I need to change my shared
library scheme to work with GCC 4.7.4.1?
Regards,
Pete Miller.
_______________________________________________
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, 25 June 2015
Re: Unable to locate logical address space.
On 25 Jun 2015 Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Thu, Jun 25, 2015 at 03:02:41PM +0100, Peter Young wrote:
>> NetSurf development #2811.
>>
>> Since I got the ARMX6 I occasionally and unpredictably get the message
>> "Unable to locate logical address space" when I try to run NetSurf.
>> Today this happened shortly after a restart, and up till now I have
>> only used NetFetch and Messenger Pro. FWIW the Next slot is 1024K.
>> According to Organizer's icon bar organ I have 1.825M free memory, so
>> it can't be that NetSurf is running out of memory. Can anyone comment
>> on this, please, and should I submit a bug report?
> I do not believe this error is from NetSurf, or UnixLib, or the GCC
> stubs. At least, a grep in the source code suggests not.
> I would suggest following up with ARMX6's technical support.
Thanks, and will do.
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> On Thu, Jun 25, 2015 at 03:02:41PM +0100, Peter Young wrote:
>> NetSurf development #2811.
>>
>> Since I got the ARMX6 I occasionally and unpredictably get the message
>> "Unable to locate logical address space" when I try to run NetSurf.
>> Today this happened shortly after a restart, and up till now I have
>> only used NetFetch and Messenger Pro. FWIW the Next slot is 1024K.
>> According to Organizer's icon bar organ I have 1.825M free memory, so
>> it can't be that NetSurf is running out of memory. Can anyone comment
>> on this, please, and should I submit a bug report?
> I do not believe this error is from NetSurf, or UnixLib, or the GCC
> stubs. At least, a grep in the source code suggests not.
> I would suggest following up with ARMX6's technical support.
Thanks, and will do.
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: Unable to locate logical address space.
On Thu, Jun 25, 2015 at 03:02:41PM +0100, Peter Young wrote:
> NetSurf development #2811.
>
> Since I got the ARMX6 I occasionally and unpredictably get the message
> "Unable to locate logical address space" when I try to run NetSurf.
> Today this happened shortly after a restart, and up till now I have
> only used NetFetch and Messenger Pro. FWIW the Next slot is 1024K.
> According to Organizer's icon bar organ I have 1.825M free memory, so
> it can't be that NetSurf is running out of memory. Can anyone comment
> on this, please, and should I submit a bug report?
I do not believe this error is from NetSurf, or UnixLib, or the GCC
stubs. At least, a grep in the source code suggests not.
I would suggest following up with ARMX6's technical support.
B.
> NetSurf development #2811.
>
> Since I got the ARMX6 I occasionally and unpredictably get the message
> "Unable to locate logical address space" when I try to run NetSurf.
> Today this happened shortly after a restart, and up till now I have
> only used NetFetch and Messenger Pro. FWIW the Next slot is 1024K.
> According to Organizer's icon bar organ I have 1.825M free memory, so
> it can't be that NetSurf is running out of memory. Can anyone comment
> on this, please, and should I submit a bug report?
I do not believe this error is from NetSurf, or UnixLib, or the GCC
stubs. At least, a grep in the source code suggests not.
I would suggest following up with ARMX6's technical support.
B.
Unable to locate logical address space.
NetSurf development #2811.
Since I got the ARMX6 I occasionally and unpredictably get the message
"Unable to locate logical address space" when I try to run NetSurf.
Today this happened shortly after a restart, and up till now I have
only used NetFetch and Messenger Pro. FWIW the Next slot is 1024K.
According to Organizer's icon bar organ I have 1.825M free memory, so
it can't be that NetSurf is running out of memory. Can anyone comment
on this, please, and should I submit a bug report?
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Since I got the ARMX6 I occasionally and unpredictably get the message
"Unable to locate logical address space" when I try to run NetSurf.
Today this happened shortly after a restart, and up till now I have
only used NetFetch and Messenger Pro. FWIW the Next slot is 1024K.
According to Organizer's icon bar organ I have 1.825M free memory, so
it can't be that NetSurf is running out of memory. Can anyone comment
on this, please, and should I submit a bug report?
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Tuesday, 23 June 2015
Re: Font scanning issue
On 22 Jun 2015 Bernard Boase [mailto: b.boase@bcs.org] wrote:
[snip]
> Has anyone else had this experience? And could it be considered a bug
> that Netsurf can stall so unhelpfully during font re-initialisation?
This happened to me a while back with a rogue font, though I haven't
used the font since. Or maybe if I know I am using that font I
subconsciously start up Netsurf before double clicking the !Fonts
folder which contains that font.
It would be helpful if Netsurf had some sort of report / option to
skip installation etc.
Chris.
--
Chris
[snip]
> Has anyone else had this experience? And could it be considered a bug
> that Netsurf can stall so unhelpfully during font re-initialisation?
This happened to me a while back with a rogue font, though I haven't
used the font since. Or maybe if I know I am using that font I
subconsciously start up Netsurf before double clicking the !Fonts
folder which contains that font.
It would be helpful if Netsurf had some sort of report / option to
skip installation etc.
Chris.
--
Chris
Re: [gccsdk] VFP revisited
On 19/06/15 01:05, Jeffrey Lee wrote:
> Hi,
>
> Attached is a new patch with a couple of VFP related changes:
Ok, thanks, I'll merge them in soon.
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,
>
> Attached is a new patch with a couple of VFP related changes:
Ok, thanks, I'll merge them in soon.
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, 22 June 2015
Font scanning issue
If a problem font is added to one's RISC OS system after Netsurf has
established its RUfl_cache file, it seems that on next start-up
Netsurf can hang the machine without having given any error
information to help diagnose the problem.
When this happened to me, I'd forgotten that I'd added a font (but in
any case had not suspected it to be faulty), and it wasn't until I
deleted RUfl_cache that the font scanning progress bar could be seen
again and therefore where it stopped immediately before the hang. This
helped identify the suspect font.
Has anyone else had this experience? And could it be considered a bug
that Netsurf can stall so unhelpfully during font re-initialisation?
--
Bernard
established its RUfl_cache file, it seems that on next start-up
Netsurf can hang the machine without having given any error
information to help diagnose the problem.
When this happened to me, I'd forgotten that I'd added a font (but in
any case had not suspected it to be faulty), and it wasn't until I
deleted RUfl_cache that the font scanning progress bar could be seen
again and therefore where it stopped immediately before the hang. This
helped identify the suspect font.
Has anyone else had this experience? And could it be considered a bug
that Netsurf can stall so unhelpfully during font re-initialisation?
--
Bernard
Friday, 19 June 2015
Re: [Rpcemu] Problem with source tarball
> Relatedly, Chrome 43 stops trying to cope with this kind of thing.
Forgot the link.
http://code.google.com/p/chromium/issues/detail?id=268085
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Forgot the link.
http://code.google.com/p/chromium/issues/detail?id=268085
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Problem with source tarball
Hi Sprow,
> > < HTTP/1.1 200 OK
> > < Date: Thu, 18 Jun 2015 10:37:44 GMT
> > < Server: Apache
> > < Last-Modified: Wed, 22 Oct 2014 18:23:45 GMT
> > < ETag: "69c012-5cb89-506070c552e40"
> > < Accept-Ranges: bytes
> > < Content-Length: 379785
> > == < Content-Type: application/x-gzip
> > == < Content-Encoding: x-gzip
> >
> > Perhaps they've fixed it, but it's compressed here.
> >
> > 379,785 bytes arrive, decompressing into 1,699,840. Could your HTTP
> > client be decompressing it without you asking?
>
> Curious!
>
> Chrome delivers 1.6MB and what is plainly a tar file. Internet
> Explorer delivers 370KB as you describe.
>
> So it is indeed a browser/webserver setup funny by the looks of it,
I thought this sounded familiar, and it is a long-standing marutan.net
bug. http://www.riscos.info/pipermail/rpcemu/2010-May/000986.html The
.tar.gz is being served as application/x-gzip above. To then say its
Content-Encoding is x-gzip states it has been compressed again.
Relatedly, Chrome 43 stops trying to cope with this kind of thing.
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> > < HTTP/1.1 200 OK
> > < Date: Thu, 18 Jun 2015 10:37:44 GMT
> > < Server: Apache
> > < Last-Modified: Wed, 22 Oct 2014 18:23:45 GMT
> > < ETag: "69c012-5cb89-506070c552e40"
> > < Accept-Ranges: bytes
> > < Content-Length: 379785
> > == < Content-Type: application/x-gzip
> > == < Content-Encoding: x-gzip
> >
> > Perhaps they've fixed it, but it's compressed here.
> >
> > 379,785 bytes arrive, decompressing into 1,699,840. Could your HTTP
> > client be decompressing it without you asking?
>
> Curious!
>
> Chrome delivers 1.6MB and what is plainly a tar file. Internet
> Explorer delivers 370KB as you describe.
>
> So it is indeed a browser/webserver setup funny by the looks of it,
I thought this sounded familiar, and it is a long-standing marutan.net
bug. http://www.riscos.info/pipermail/rpcemu/2010-May/000986.html The
.tar.gz is being served as application/x-gzip above. To then say its
Content-Encoding is x-gzip states it has been compressed again.
Relatedly, Chrome 43 stops trying to cope with this kind of thing.
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Thursday, 18 June 2015
Re: [gccsdk] VFP revisited
Index: gcc4/recipe/files/gcc/libunixlib/signal/_signal.s
===================================================================
--- gcc4/recipe/files/gcc/libunixlib/signal/_signal.s (revision 6866)
+++ gcc4/recipe/files/gcc/libunixlib/signal/_signal.s (working copy)
@@ -350,7 +350,7 @@
@ 0x80000100 - &800001FF CoProcessor exceptions
@ 0x80000200 - &800002FF Floating Point exceptions
@ 0x80000300 - &800003FF Econet exceptions
-@ 0x80000500 - &800005FF VFP exceptions
+@ 0x80000600 - &800006FF VFP exceptions
@
@ For these classes of exceptions, we map Floating Point & VFP exceptions
@ to SIGFPE and all others to SIGEMT.
@@ -444,7 +444,7 @@
MOV a3, a3, LSR #8
AND a3, a3, #0xFF
# if defined(__VFP_FP__)
- CMP a3, #0x05
+ CMP a3, #0x06
# else
CMP a3, #0x02
# endif
Index: gcc4/recipe/patches/gcc/libcpp.configure.ac.p
===================================================================
--- gcc4/recipe/patches/gcc/libcpp.configure.ac.p (revision 0)
+++ gcc4/recipe/patches/gcc/libcpp.configure.ac.p (revision 0)
@@ -0,0 +1,12 @@
+Index: libcpp/configure.ac
+===================================================================
+--- libcpp/configure.ac (revision 221801)
++++ libcpp/configure.ac (working copy)
+@@ -150,6 +150,7 @@
+ case $target in
+ alpha*-*-* | \
+ arm*-*-*eabi* | \
++ arm*-*-riscos | \
+ arm*-*-rtems[.0-9]* | \
+ arm*-*-symbianelf* | \
+ x86_64-*-* | \
Index: gcc4/recipe/patches/gcc/gcc.config.arm.arm.c.p
===================================================================
--- gcc4/recipe/patches/gcc/gcc.config.arm.arm.c.p (revision 6866)
+++ gcc4/recipe/patches/gcc/gcc.config.arm.arm.c.p (working copy)
@@ -381,22 +381,6 @@
if (TARGET_VXWORKS_RTP)
{
pic_rtx = gen_rtx_SYMBOL_REF (Pmode, VXWORKS_GOTT_BASE);
-@@ -9024,6 +9239,15 @@
- if (immtype == -1)
- return -1;
-
-+#ifdef TARGET_RISCOSELF
-+ /* FIXME: GCCSDK: Find a better fix for this if possible
-+ (see "Broken on 32-bit H_W_I hosts" FIXME below)
-+ GCC team have no plans to fix the issue:
-+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511 */
-+ if ((sizeof (HOST_WIDE_INT) != 8) && (immtype == 17))
-+ return -1;
-+#endif
-+
- if (elementwidth)
- *elementwidth = elsize;
-
@@ -15072,7 +15296,7 @@
compromise save just the frame pointers. Combined with the link
register saved elsewhere this should be sufficient to get
Index: gcc4/recipe/patches/gcc/gcc.config.gcc.p
===================================================================
--- gcc4/recipe/patches/gcc/gcc.config.gcc.p (revision 6866)
+++ gcc4/recipe/patches/gcc/gcc.config.gcc.p (working copy)
@@ -1,8 +1,8 @@
Index: gcc/config.gcc
===================================================================
---- gcc/config.gcc (revision 196619)
+--- gcc/config.gcc (revision 221801)
+++ gcc/config.gcc (working copy)
-@@ -930,6 +930,18 @@
+@@ -930,6 +930,19 @@
esac
tm_file="${tm_file} arm/aout.h arm/arm.h"
;;
@@ -17,6 +17,7 @@
+ extra_options="${extra_options} arm/riscos.opt"
+ extra_objs="riscos.o"
+ extra_gcc_objs="riscos-gcc.o"
++ need_64bit_hwint=yes
+ ;;
arm*-*-elf)
tm_file="dbxelf.h elfos.h newlib-stdint.h arm/unknown-elf.h arm/elf.h arm/aout.h arm/arm.h"
Index: gcc4/recipe/scripts/gcc/reconf-libcpp
===================================================================
--- gcc4/recipe/scripts/gcc/reconf-libcpp (revision 0)
+++ gcc4/recipe/scripts/gcc/reconf-libcpp (revision 0)
@@ -0,0 +1,5 @@
+#!/bin/bash -e
+# Auto-generate 'libcpp' as we've patched it.
+# Copyright (c) 2010-2015 GCCSDK Developers
+
+( cd libcpp && ACLOCAL='aclocal -I .. -I ../config' autoreconf -v )
===================================================================
--- gcc4/recipe/files/gcc/libunixlib/signal/_signal.s (revision 6866)
+++ gcc4/recipe/files/gcc/libunixlib/signal/_signal.s (working copy)
@@ -350,7 +350,7 @@
@ 0x80000100 - &800001FF CoProcessor exceptions
@ 0x80000200 - &800002FF Floating Point exceptions
@ 0x80000300 - &800003FF Econet exceptions
-@ 0x80000500 - &800005FF VFP exceptions
+@ 0x80000600 - &800006FF VFP exceptions
@
@ For these classes of exceptions, we map Floating Point & VFP exceptions
@ to SIGFPE and all others to SIGEMT.
@@ -444,7 +444,7 @@
MOV a3, a3, LSR #8
AND a3, a3, #0xFF
# if defined(__VFP_FP__)
- CMP a3, #0x05
+ CMP a3, #0x06
# else
CMP a3, #0x02
# endif
Index: gcc4/recipe/patches/gcc/libcpp.configure.ac.p
===================================================================
--- gcc4/recipe/patches/gcc/libcpp.configure.ac.p (revision 0)
+++ gcc4/recipe/patches/gcc/libcpp.configure.ac.p (revision 0)
@@ -0,0 +1,12 @@
+Index: libcpp/configure.ac
+===================================================================
+--- libcpp/configure.ac (revision 221801)
++++ libcpp/configure.ac (working copy)
+@@ -150,6 +150,7 @@
+ case $target in
+ alpha*-*-* | \
+ arm*-*-*eabi* | \
++ arm*-*-riscos | \
+ arm*-*-rtems[.0-9]* | \
+ arm*-*-symbianelf* | \
+ x86_64-*-* | \
Index: gcc4/recipe/patches/gcc/gcc.config.arm.arm.c.p
===================================================================
--- gcc4/recipe/patches/gcc/gcc.config.arm.arm.c.p (revision 6866)
+++ gcc4/recipe/patches/gcc/gcc.config.arm.arm.c.p (working copy)
@@ -381,22 +381,6 @@
if (TARGET_VXWORKS_RTP)
{
pic_rtx = gen_rtx_SYMBOL_REF (Pmode, VXWORKS_GOTT_BASE);
-@@ -9024,6 +9239,15 @@
- if (immtype == -1)
- return -1;
-
-+#ifdef TARGET_RISCOSELF
-+ /* FIXME: GCCSDK: Find a better fix for this if possible
-+ (see "Broken on 32-bit H_W_I hosts" FIXME below)
-+ GCC team have no plans to fix the issue:
-+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511 */
-+ if ((sizeof (HOST_WIDE_INT) != 8) && (immtype == 17))
-+ return -1;
-+#endif
-+
- if (elementwidth)
- *elementwidth = elsize;
-
@@ -15072,7 +15296,7 @@
compromise save just the frame pointers. Combined with the link
register saved elsewhere this should be sufficient to get
Index: gcc4/recipe/patches/gcc/gcc.config.gcc.p
===================================================================
--- gcc4/recipe/patches/gcc/gcc.config.gcc.p (revision 6866)
+++ gcc4/recipe/patches/gcc/gcc.config.gcc.p (working copy)
@@ -1,8 +1,8 @@
Index: gcc/config.gcc
===================================================================
---- gcc/config.gcc (revision 196619)
+--- gcc/config.gcc (revision 221801)
+++ gcc/config.gcc (working copy)
-@@ -930,6 +930,18 @@
+@@ -930,6 +930,19 @@
esac
tm_file="${tm_file} arm/aout.h arm/arm.h"
;;
@@ -17,6 +17,7 @@
+ extra_options="${extra_options} arm/riscos.opt"
+ extra_objs="riscos.o"
+ extra_gcc_objs="riscos-gcc.o"
++ need_64bit_hwint=yes
+ ;;
arm*-*-elf)
tm_file="dbxelf.h elfos.h newlib-stdint.h arm/unknown-elf.h arm/elf.h arm/aout.h arm/arm.h"
Index: gcc4/recipe/scripts/gcc/reconf-libcpp
===================================================================
--- gcc4/recipe/scripts/gcc/reconf-libcpp (revision 0)
+++ gcc4/recipe/scripts/gcc/reconf-libcpp (revision 0)
@@ -0,0 +1,5 @@
+#!/bin/bash -e
+# Auto-generate 'libcpp' as we've patched it.
+# Copyright (c) 2010-2015 GCCSDK Developers
+
+( cd libcpp && ACLOCAL='aclocal -I .. -I ../config' autoreconf -v )
Property changes on: gcc4/recipe/scripts/gcc/reconf-libcpp
___________________________________________________________________
Added: svn:executable
+ *
Hi,
Attached is a new patch with a couple of VFP related changes:
* Corrected the VFP exception error base to match the value that's now
being used by RISC OS (it was recently modified in the OS to avoid a
potential clash with one of ROL's allocations, as I'd mentioned might
happen in my original mail)
* Removed the hacky fix for the internal compiler error in
gcc/config/arm.c and instead make GCC use a 64bit HOST_WIDE_INT when
targetting RISC OS. Forcing 64bit HOST_wIDE_INT, even on 32bit hosts, is
the behaviour that the major ARM targets seem to take. The GCC binaries
will be bigger, and compiler memory usage will presumably increase too,
but the change doesn't seem to have had any measurable impact on compile
times (compiling some non-trivial C code on an Iyonix with -O3 took almost
exactly 10 minutes for both 32bit and 64bit HOST_WIDE_INT versions)
Cheers,
- Jeffrey
(Fwd) toolchain for m68k-amigaos
Forwarded to netsurf-dev list.
=== BEGIN FORWARDED MESSAGE ===
Hello,
While browsing the www I stumbled upon the netsurf toolchains.
Especially the m68k-amigaos toolchain was unexpected.
I have a remark about the binutils comment in the m68k-amigaos
Makefile. The Makefile complains that the binutils are not 64-bit
safe. This restriction is no longer present.
Regards,
Gunther Nikl
=== BEGIN FORWARDED MESSAGE ===
Hello,
While browsing the www I stumbled upon the netsurf toolchains.
Especially the m68k-amigaos toolchain was unexpected.
I have a remark about the binutils comment in the m68k-amigaos
Makefile. The Makefile complains that the binutils are not 64-bit
safe. This restriction is no longer present.
Regards,
Gunther Nikl
Re: [Rpcemu] Problem with source tarball
Hi Ralph,
In article <20150618104327.71E67213AA@orac.inputplus.co.uk>, Ralph Corderoy
<ralph@inputplus.co.uk> wrote:
> > /rpcemu/cgi/download.php?sFName=0.8.12/rpcemu-0.8.12.tar.gz
> >
> > isn't actually a tar gz file, it's just a tar file.
>
> Perhaps they've fixed it, but it's compressed here.
>
> 379,785 bytes arrive, decompressing into 1,699,840. Could your HTTP
> client be decompressing it without you asking?
Curious!
Chrome delivers 1.6MB and what is plainly a tar file.
Internet Explorer delivers 370KB as you describe.
So it is indeed a browser/webserver setup funny by the looks of it,
Sprow.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
In article <20150618104327.71E67213AA@orac.inputplus.co.uk>, Ralph Corderoy
<ralph@inputplus.co.uk> wrote:
> > /rpcemu/cgi/download.php?sFName=0.8.12/rpcemu-0.8.12.tar.gz
> >
> > isn't actually a tar gz file, it's just a tar file.
>
> Perhaps they've fixed it, but it's compressed here.
>
> 379,785 bytes arrive, decompressing into 1,699,840. Could your HTTP
> client be decompressing it without you asking?
Curious!
Chrome delivers 1.6MB and what is plainly a tar file.
Internet Explorer delivers 370KB as you describe.
So it is indeed a browser/webserver setup funny by the looks of it,
Sprow.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Problem with source tarball
Hi Sprow,
> /rpcemu/cgi/download.php?sFName=0.8.12/rpcemu-0.8.12.tar.gz
>
> isn't actually a tar gz file, it's just a tar file.
Perhaps they've fixed it, but it's compressed here. See `=='.
$ curl -sSLv 'http://marutan.net/rpcemu/cgi/download.php?sFName=0.8.12/rpcemu-0.8.12.tar.gz' |
> file -
* About to connect() to marutan.net port 80 (#0)
* Trying 217.135.32.99... connected
* Connected to marutan.net (217.135.32.99) port 80 (#0)
> GET /rpcemu/cgi/download.php?sFName=0.8.12/rpcemu-0.8.12.tar.gz HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
> Host: marutan.net
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Thu, 18 Jun 2015 10:37:44 GMT
< Server: Apache
< Location: http://www.marutan.net/rpcemu/0.8.12/rpcemu-0.8.12.tar.gz
< Content-Length: 0
< Content-Type: text/html; charset=utf-8
<
* Connection #0 to host marutan.net left intact
* Issue another request to this URL: 'http://www.marutan.net/rpcemu/0.8.12/rpcemu-0.8.12.tar.gz'
* About to connect() to www.marutan.net port 80 (#1)
* Trying 217.135.32.99... connected
* Connected to www.marutan.net (217.135.32.99) port 80 (#1)
> GET /rpcemu/0.8.12/rpcemu-0.8.12.tar.gz HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
> Host: www.marutan.net
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 18 Jun 2015 10:37:44 GMT
< Server: Apache
< Last-Modified: Wed, 22 Oct 2014 18:23:45 GMT
< ETag: "69c012-5cb89-506070c552e40"
< Accept-Ranges: bytes
< Content-Length: 379785
== < Content-Type: application/x-gzip
== < Content-Encoding: x-gzip
<
{ [data not shown]
== /dev/stdin: gzip compressed data, from Unix, last modified: Wed Oct 22 19:23:44 2014, max compression
$
379,785 bytes arrive, decompressing into 1,699,840. Could your HTTP
client be decompressing it without you asking? It shouldn't be AIUI, as
it isn't `Transfer-Encoding: gzip', but Content-Encoding.
> Was the crucial 'c' switch missing from the command that created it,
> meaning it's uncompressed?
`c' is tar(1)'s option to create the tar file.
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> /rpcemu/cgi/download.php?sFName=0.8.12/rpcemu-0.8.12.tar.gz
>
> isn't actually a tar gz file, it's just a tar file.
Perhaps they've fixed it, but it's compressed here. See `=='.
$ curl -sSLv 'http://marutan.net/rpcemu/cgi/download.php?sFName=0.8.12/rpcemu-0.8.12.tar.gz' |
> file -
* About to connect() to marutan.net port 80 (#0)
* Trying 217.135.32.99... connected
* Connected to marutan.net (217.135.32.99) port 80 (#0)
> GET /rpcemu/cgi/download.php?sFName=0.8.12/rpcemu-0.8.12.tar.gz HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
> Host: marutan.net
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Thu, 18 Jun 2015 10:37:44 GMT
< Server: Apache
< Location: http://www.marutan.net/rpcemu/0.8.12/rpcemu-0.8.12.tar.gz
< Content-Length: 0
< Content-Type: text/html; charset=utf-8
<
* Connection #0 to host marutan.net left intact
* Issue another request to this URL: 'http://www.marutan.net/rpcemu/0.8.12/rpcemu-0.8.12.tar.gz'
* About to connect() to www.marutan.net port 80 (#1)
* Trying 217.135.32.99... connected
* Connected to www.marutan.net (217.135.32.99) port 80 (#1)
> GET /rpcemu/0.8.12/rpcemu-0.8.12.tar.gz HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
> Host: www.marutan.net
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 18 Jun 2015 10:37:44 GMT
< Server: Apache
< Last-Modified: Wed, 22 Oct 2014 18:23:45 GMT
< ETag: "69c012-5cb89-506070c552e40"
< Accept-Ranges: bytes
< Content-Length: 379785
== < Content-Type: application/x-gzip
== < Content-Encoding: x-gzip
<
{ [data not shown]
== /dev/stdin: gzip compressed data, from Unix, last modified: Wed Oct 22 19:23:44 2014, max compression
$
379,785 bytes arrive, decompressing into 1,699,840. Could your HTTP
client be decompressing it without you asking? It shouldn't be AIUI, as
it isn't `Transfer-Encoding: gzip', but Content-Encoding.
> Was the crucial 'c' switch missing from the command that created it,
> meaning it's uncompressed?
`c' is tar(1)'s option to create the tar file.
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Problem with source tarball
Hi,
After a bit of headscratching I ought to point out that the source download
on the RPCEmu website at
/rpcemu/cgi/download.php?sFName=0.8.12/rpcemu-0.8.12.tar.gz
isn't actually a tar gz file, it's just a tar file. Was the crucial 'c'
switch missing from the command that created it, meaning it's uncompressed?
SparkFS is man enough to figure it out (changing it's filetype back to &C46)
but extracting it at the Linux bash prompt isn't as forgiving.
Regards,
Sprow.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
After a bit of headscratching I ought to point out that the source download
on the RPCEmu website at
/rpcemu/cgi/download.php?sFName=0.8.12/rpcemu-0.8.12.tar.gz
isn't actually a tar gz file, it's just a tar file. Was the crucial 'c'
switch missing from the command that created it, meaning it's uncompressed?
SparkFS is man enough to figure it out (changing it's filetype back to &C46)
but extracting it at the Linux bash prompt isn't as forgiving.
Regards,
Sprow.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Wednesday, 17 June 2015
[gccsdk] Has any one got GDBServer and GDB working
I've been trying to see if I could get GCC debugging going.
I've got as far as starting the program and connecting with GDB
on my Linux machine. But I don't seem to be getting any source
code to examine and can't seem to step.
I get the message "cannot find bounds of current function" from
the "s" command.
I'm unfamiliar with GDB so may of course be doing something
completely incorrect.
I've got RPCEmu on Windows running the code using GDB
(after loading the module) and a virtual Ubuntu machine
on the same windows box where I have built version 7.4
of GDB with --target=arm-elf.
gdb is running on RISC OS after pressing F12 as it doesn't get
anywhere when run in a taskwindow.
I seem to get a lot of strange characters on the RPCEmu
screen and various Unsupported packet messages.
Is there a specific version of gdb I should be building on
Ubuntu?
Is there anything else I should be doing?
Regards,
Alan
Thursday, 11 June 2015
Aw: Re: Running netsurf 3.3 on Raspberry Pi in framebuffer
Hello Ole,
thank you for trying to help me. To be honest I do not have a clue hot to check, if that libnsfb is compiled with SDL backend. I just followed the "Quick Build Steps for NetSurf" instructions from the Netsurf Hompeage.
Now I tried to install a fresh latest raspbian image, and followed the steps once more. At this time, step " make TARGET=framebuffer" stops with:
COMPRESS: !NetSurf/Resources/nl/Messages
LINK: nsfb
/usr/bin/ld: /home/pi/dev-netsurf/workspace/inst-arm-linux-gnueabihf/lib/libnsutils.a(src_time.o): undefined reference to symbol 'clock_gettime@@GLIBC_2.4'
//lib/arm-linux-gnueabihf/librt.so.1: error adding symbols: DSO missing from command line
collect2: ld returned 1 exit status
Makefile:632: recipe for target 'nsfb' failed
make: *** [nsfb] Error 1
rm !NetSurf/Resources/fr/Messages.tmp !NetSurf/Resources/en/Messages.tmp !NetSurf/Resources/nl/Messages.tmp !NetSurf/Resources/de/Messages.tmp !NetSurf/Resources/it/Messages.tmp
I would prefer to compile the 3.3 and not the 3.4 dev version, but the instructions bundled with the 3.3 sources are little bit confusing for me, thus I am not familiar with C/C++ development.
Could you give me some hints ?
Greets,
Karel
+ --------------------------
+ Karel Mácha
+ www.karlitos.net
+ --------------------------
---- Ein Mo, 08 Jun 2015 16:42:27 +0200 Ole<ole@monochrom.net> hat geschrieben ----
> Hello Karel,
>
> > (0.164048) framebuffer/gui.c:455 process_cmdline: argc 1, argv 0xbea79804
> > (0.166074) framebuffer/framebuffer.c:400 framebuffer_initialise: The sdl
> > surface is not available from libnsfb
> >
> > Am I missing something or do I get the error because of the 3.4 (Dev)
> > version ? Can someone please give me a hint how to fix this ?
>
> Did you already to try to run the framebuffer version under X11? the
> libnsfb can be compiled with several backends... SDL is one of them. When
> the build system does not detect SDL correctly (and you do not configure
> it manually somehow...), it probably just skips the build of the SDL
> backend.
>
> Maybe you have luck and the X11 backend was put into your build of libnsfb.
>
> Otherwise, make sure that libnsfb is compiled with SDL backend.
>
> I once had an problem with that...:
>
> libnsfb make use of some gcc feature (a ctor function for libraries...,
> something like that) which was unsupported by the GCC cross compiler that
> I used: SDL was never registered as valid backend when libnsfb was loaded
> and always reported that the SDL backend is not available... I had to
> manually call the registration of the backend at application startup time.
> But I think this was a very rare problem, I guess the buildsystem did not
> find your installation of SDL development files.
>
> Greets,
> Ole
>
>
>
thank you for trying to help me. To be honest I do not have a clue hot to check, if that libnsfb is compiled with SDL backend. I just followed the "Quick Build Steps for NetSurf" instructions from the Netsurf Hompeage.
Now I tried to install a fresh latest raspbian image, and followed the steps once more. At this time, step " make TARGET=framebuffer" stops with:
COMPRESS: !NetSurf/Resources/nl/Messages
LINK: nsfb
/usr/bin/ld: /home/pi/dev-netsurf/workspace/inst-arm-linux-gnueabihf/lib/libnsutils.a(src_time.o): undefined reference to symbol 'clock_gettime@@GLIBC_2.4'
//lib/arm-linux-gnueabihf/librt.so.1: error adding symbols: DSO missing from command line
collect2: ld returned 1 exit status
Makefile:632: recipe for target 'nsfb' failed
make: *** [nsfb] Error 1
rm !NetSurf/Resources/fr/Messages.tmp !NetSurf/Resources/en/Messages.tmp !NetSurf/Resources/nl/Messages.tmp !NetSurf/Resources/de/Messages.tmp !NetSurf/Resources/it/Messages.tmp
I would prefer to compile the 3.3 and not the 3.4 dev version, but the instructions bundled with the 3.3 sources are little bit confusing for me, thus I am not familiar with C/C++ development.
Could you give me some hints ?
Greets,
Karel
+ --------------------------
+ Karel Mácha
+ www.karlitos.net
+ --------------------------
---- Ein Mo, 08 Jun 2015 16:42:27 +0200 Ole<ole@monochrom.net> hat geschrieben ----
> Hello Karel,
>
> > (0.164048) framebuffer/gui.c:455 process_cmdline: argc 1, argv 0xbea79804
> > (0.166074) framebuffer/framebuffer.c:400 framebuffer_initialise: The sdl
> > surface is not available from libnsfb
> >
> > Am I missing something or do I get the error because of the 3.4 (Dev)
> > version ? Can someone please give me a hint how to fix this ?
>
> Did you already to try to run the framebuffer version under X11? the
> libnsfb can be compiled with several backends... SDL is one of them. When
> the build system does not detect SDL correctly (and you do not configure
> it manually somehow...), it probably just skips the build of the SDL
> backend.
>
> Maybe you have luck and the X11 backend was put into your build of libnsfb.
>
> Otherwise, make sure that libnsfb is compiled with SDL backend.
>
> I once had an problem with that...:
>
> libnsfb make use of some gcc feature (a ctor function for libraries...,
> something like that) which was unsupported by the GCC cross compiler that
> I used: SDL was never registered as valid backend when libnsfb was loaded
> and always reported that the SDL backend is not available... I had to
> manually call the registration of the backend at application startup time.
> But I think this was a very rare problem, I guess the buildsystem did not
> find your installation of SDL development files.
>
> Greets,
> Ole
>
>
>
Monday, 8 June 2015
NetSurf in the Press
I'm happy to report that NetSurf is in the news.
It is featured, with a fairly accurate write-up, in the
'Hot Picks' section of the current issue of the magazine
'Linux Format'.
--
Regards,
Dave Lawton
HTML emails are just a security risk, and nobody needs that.
It is featured, with a fairly accurate write-up, in the
'Hot Picks' section of the current issue of the magazine
'Linux Format'.
--
Regards,
Dave Lawton
HTML emails are just a security risk, and nobody needs that.
Re: Running netsurf 3.3 on Raspberry Pi in framebuffer
Hello Karel,
> (0.164048) framebuffer/gui.c:455 process_cmdline: argc 1, argv 0xbea79804
> (0.166074) framebuffer/framebuffer.c:400 framebuffer_initialise: The sdl
> surface is not available from libnsfb
>
> Am I missing something or do I get the error because of the 3.4 (Dev)
> version ? Can someone please give me a hint how to fix this ?
Did you already to try to run the framebuffer version under X11? the
libnsfb can be compiled with several backends... SDL is one of them. When
the build system does not detect SDL correctly (and you do not configure
it manually somehow...), it probably just skips the build of the SDL
backend.
Maybe you have luck and the X11 backend was put into your build of libnsfb.
Otherwise, make sure that libnsfb is compiled with SDL backend.
I once had an problem with that...:
libnsfb make use of some gcc feature (a ctor function for libraries...,
something like that) which was unsupported by the GCC cross compiler that
I used: SDL was never registered as valid backend when libnsfb was loaded
and always reported that the SDL backend is not available... I had to
manually call the registration of the backend at application startup time.
But I think this was a very rare problem, I guess the buildsystem did not
find your installation of SDL development files.
Greets,
Ole
> (0.164048) framebuffer/gui.c:455 process_cmdline: argc 1, argv 0xbea79804
> (0.166074) framebuffer/framebuffer.c:400 framebuffer_initialise: The sdl
> surface is not available from libnsfb
>
> Am I missing something or do I get the error because of the 3.4 (Dev)
> version ? Can someone please give me a hint how to fix this ?
Did you already to try to run the framebuffer version under X11? the
libnsfb can be compiled with several backends... SDL is one of them. When
the build system does not detect SDL correctly (and you do not configure
it manually somehow...), it probably just skips the build of the SDL
backend.
Maybe you have luck and the X11 backend was put into your build of libnsfb.
Otherwise, make sure that libnsfb is compiled with SDL backend.
I once had an problem with that...:
libnsfb make use of some gcc feature (a ctor function for libraries...,
something like that) which was unsupported by the GCC cross compiler that
I used: SDL was never registered as valid backend when libnsfb was loaded
and always reported that the SDL backend is not available... I had to
manually call the registration of the backend at application startup time.
But I think this was a very rare problem, I guess the buildsystem did not
find your installation of SDL development files.
Greets,
Ole
Thursday, 4 June 2015
Running netsurf 3.3 on Raspberry Pi in framebuffer
Hello,
I would like to try the latest netsurf-browser on my Raspberry Pi. I am using the Raspbian (Debian) distro. I followed the steps on http://source.netsurf-browser.org/netsurf.git/plain/Docs/QUICK-START and build the netsurf browser according to this How-To. In the last step I used:
make TARGET=framebuffer
to build the framebuffer front end.
But, if i try to run the netsurf browser with ./nsfb -v I get following errors:
(0.000003) desktop/netsurf.c:157 netsurf_init: NetSurf version '3.4 (Dev)'
(0.002204) desktop/netsurf.c:161 netsurf_init: NetSurf on <Linux>, node <kivypie>, release <3.18.9+>, version <#768 PREEMPT Sun Mar 15 18:59:03 GMT 2015>, machine <armv6l>
(0.004817) utils/messages.c:152 messages_load: Loading Messages from '/home/sysop/dev-netsurf/workspace/netsurf/!NetSurf/Resources/en/Messages'
(0.033929) image/image_cache.c:378 image_cache_init: Image cache initilised with a limit of 3145728 hysteresis of 629145
(0.046726) render/html_css_fetcher.c:64 html_css_fetcher_initialise: html_css_fetcher_initialise called for x-ns-css
(0.051498) content/fetchers/curl.c:1239 fetch_curl_register: curl_version libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3
(0.083398) utils/useragent.c:68 user_agent_build_string: Built user agent "NetSurf/3.4 (Linux)"
(0.085862) content/fetchers/curl.c:1325 fetch_curl_register: cURL linked against openssl
(0.089008) content/fetchers/curl.c:115 fetch_curl_initialise: Initialise cURL fetcher for http
(0.090500) content/fetchers/curl.c:115 fetch_curl_initialise: Initialise cURL fetcher for https
(0.090837) content/fetchers/data.c:65 fetch_data_initialise: fetch_data_initialise called for data
(0.100393) content/llcache.c:3296 llcache_initialise: llcache initialising with a limit of 9437184 bytes
(0.162072) javascript/jsapi.c:46 js_initialise: New runtime handle 0x47c068
(0.164048) framebuffer/gui.c:455 process_cmdline: argc 1, argv 0xbea79804
(0.166074) framebuffer/framebuffer.c:400 framebuffer_initialise: The sdl surface is not available from libnsfb
Am I missing something or do I get the error because of the 3.4 (Dev) version ? Can someone please give me a hint how to fix this ?
+ --------------------------
+ Karel Mácha
+ www.karlitos.net
+ --------------------------
I would like to try the latest netsurf-browser on my Raspberry Pi. I am using the Raspbian (Debian) distro. I followed the steps on http://source.netsurf-browser.org/netsurf.git/plain/Docs/QUICK-START and build the netsurf browser according to this How-To. In the last step I used:
make TARGET=framebuffer
to build the framebuffer front end.
But, if i try to run the netsurf browser with ./nsfb -v I get following errors:
(0.000003) desktop/netsurf.c:157 netsurf_init: NetSurf version '3.4 (Dev)'
(0.002204) desktop/netsurf.c:161 netsurf_init: NetSurf on <Linux>, node <kivypie>, release <3.18.9+>, version <#768 PREEMPT Sun Mar 15 18:59:03 GMT 2015>, machine <armv6l>
(0.004817) utils/messages.c:152 messages_load: Loading Messages from '/home/sysop/dev-netsurf/workspace/netsurf/!NetSurf/Resources/en/Messages'
(0.033929) image/image_cache.c:378 image_cache_init: Image cache initilised with a limit of 3145728 hysteresis of 629145
(0.046726) render/html_css_fetcher.c:64 html_css_fetcher_initialise: html_css_fetcher_initialise called for x-ns-css
(0.051498) content/fetchers/curl.c:1239 fetch_curl_register: curl_version libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3
(0.083398) utils/useragent.c:68 user_agent_build_string: Built user agent "NetSurf/3.4 (Linux)"
(0.085862) content/fetchers/curl.c:1325 fetch_curl_register: cURL linked against openssl
(0.089008) content/fetchers/curl.c:115 fetch_curl_initialise: Initialise cURL fetcher for http
(0.090500) content/fetchers/curl.c:115 fetch_curl_initialise: Initialise cURL fetcher for https
(0.090837) content/fetchers/data.c:65 fetch_data_initialise: fetch_data_initialise called for data
(0.100393) content/llcache.c:3296 llcache_initialise: llcache initialising with a limit of 9437184 bytes
(0.162072) javascript/jsapi.c:46 js_initialise: New runtime handle 0x47c068
(0.164048) framebuffer/gui.c:455 process_cmdline: argc 1, argv 0xbea79804
(0.166074) framebuffer/framebuffer.c:400 framebuffer_initialise: The sdl surface is not available from libnsfb
Am I missing something or do I get the error because of the 3.4 (Dev) version ? Can someone please give me a hint how to fix this ?
+ --------------------------
+ Karel Mácha
+ www.karlitos.net
+ --------------------------
Monday, 1 June 2015
Re: NetSurf Developer Weekend
On Mon, Jun 01, 2015 at 13:09:55 +0100, Daniel Silverstone wrote:
> The weekend of the 4/5 of July, Codethink Ltd (My employer) has graciously
> allowed the use of meeting room, tea/coffee/biscuits etc.
Correction -- 18/19 July -- I was running on old data. My apologies.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> The weekend of the 4/5 of July, Codethink Ltd (My employer) has graciously
> allowed the use of meeting room, tea/coffee/biscuits etc.
Correction -- 18/19 July -- I was running on old data. My apologies.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
NetSurf Developer Weekend
Hi all,
We will be having a NetSurf Developer Weekend in just about 1 month's time.
The weekend of the 4/5 of July, Codethink Ltd (My employer) has graciously
allowed the use of meeting room, tea/coffee/biscuits etc.
This means the meeting will be at Codethink's Office[0] on the Saturday and
Sunday. There is no cost to attend (outside of your travel and accommodation)
but, if you wish to attend, you need to let me know directly (email to me, not
to the list).
Currently the full *core* development team will be attending. If anyone wants
to come along to help with a frontend, or to learn about core development plans
then please do let me know.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
We will be having a NetSurf Developer Weekend in just about 1 month's time.
The weekend of the 4/5 of July, Codethink Ltd (My employer) has graciously
allowed the use of meeting room, tea/coffee/biscuits etc.
This means the meeting will be at Codethink's Office[0] on the Saturday and
Sunday. There is no cost to attend (outside of your travel and accommodation)
but, if you wish to attend, you need to let me know directly (email to me, not
to the list).
Currently the full *core* development team will be attending. If anyone wants
to come along to help with a frontend, or to learn about core development plans
then please do let me know.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Subscribe to:
Posts (Atom)