BTW I've been working on a ruby script for generating descriptor files for use on cross-compiler setups (cygwin/linux) to go with my other ruby development tools that can be found here: http://www.a500.org/downloads/development/index.xhtml
Chris wrote: You'll need to copy the two .datatype files to SYS:Classes/DataTypes, and the contents of SObjs to SObjs:. Double-click on SVG and then double-click (or open into MultiView) rect1.svg. This should crash it.
Great, thanks!
Whenever there is an issue with threading I consider it a high priority.
Chris wrote: Are you aware of the long-standing libcurl threaded resolver issue?
Not a clue. I just happened to stumble upon this thread because AmiWest just ended and I was scanning forums for questions.
If by "long-standing" you mean it was discussed in a web forum then don't expect anything to happen. Problems must at a minimum be mentioned on the support.amigos.net forum to be noticed.
Beta testers are obligated to scan the support forum for issues to report. They are not obligated to scan anywhere else.
OK, done. Olaf is already aware so I don't expect this to change anything, but it gives some visibility of the issue.
Just because Olaf knows about the problem doesn't mean anybody else does. If it is not recorded in our internal bugzilla then I know nothing about it. And since I'm the guy pushing for fixes... well, you figure it out.
I do the resource planning and push to get bugs fixed. I work from our internal bugzilla. Beta testers are supposed to confirm bugs and file them into bugzilla and let customers know they submitted them. This system has been working pretty good so far but issues still can fall through the cracks and are thus invisible to me.
Hmmmm... This is probably something I should blog about so customers know what to do to get their most annoying bugs fixed. I just realized our development team knows the rules but nobody bothered to tell our customers.
I just cloned the libsvgtiny git repository using hggit but when I try to build it it seems to require some files from netsurf (?): Quote:
26.Development:Projects/Libraries/libsvgtiny> gmake Makefile:10: /opt/netsurf/share/netsurf-buildsystem/makefiles/Makefile.tools: Device not configured Makefile:45: /Makefile.top: Device not configured gmake: stat: /Makefile.top: Device not configured gmake: stat: /opt/netsurf/share/netsurf-buildsystem/makefiles/Makefile.tools: Device not configured gmake: *** No rule to make target `/Makefile.top'. Stop. 26.Development:Projects/Libraries/libsvgtiny> make Makefile:10: /opt/netsurf/share/netsurf-buildsystem/makefiles/Makefile.tools: Device not configured Makefile:45: /Makefile.top: Device not configured make: stat: /Makefile.top: Device not configured make: stat: /opt/netsurf/share/netsurf-buildsystem/makefiles/Makefile.tools: Device not configured make: *** No rule to make target `/Makefile.top'. Stop. 26.Development:Projects/Libraries/libsvgtiny>
Probably doesn't help much actually. But basically you need to also clone buildsystem.git, copy it into a directory called "share", and then when you make libsvgtiny you need to add PREFIX=/path/to/the/share/directory
The latest libsvgtiny also needs libdom, which needs libwapcaplet, and you can build it with the expat binding only.
Today I wasted a lot of time cloning the netsurf.git repository (it took several hours) since I thought it needed files from that. If I knew it would take so long I would have made sure to do only a shallow copy (cloning libsvgtiny.git didn't take very long at all).
Yes, netsurf.git takes forever with hg-git, it's the reason I don't use hg-git with it and want a proper git client. Doing a hg-git pull takes ages too even if nothing has changed.
But the libraries are quick with it, as they have much less history and are smaller overall.
I haven't risked trying to push to git with hg-git yet, and don't intend to.
Cloning buildsystem.git and using PREFIX solved the "Device not configured" errors. I also had to set CC=gcc so that it wouldn't say "Unable to detect toolchain".
After all that and installing gperf it now complains about: Quote:
No closing quote means that pkg-config can't find a particular library. Make sure you have the .pc files for libdom, libwapcaplet and libexpat installed.
The only way to find out the actual error is to find out what command make is trying to run, as it'll be embedded in it. "make -n" might help.
I have libexpat installed from the SDK but it doesn't include the .pc file. Neither does the older version on OS4Depot.
Edit: I downloaded the expat source archive from sourceforge and modified the .pc.in file contained therein and I've now successfully compiled libwapcaplet.
Edit: The .pc file that gmake install generates is empty for some reason but apart from that the install seems to work. Quote:
8.Development:Projects/Libraries/netsurf/libwapcaplet> gmake PREFIX=/SDK/local/newlib CC=gcc install T:gmake.sh.108.HOMQMV[6]: @mkdir: not found T:gmake.sh.108.HOMQMV[7]: @echo: not found T:gmake.sh.108.HOMQMV[8]: @sed: not found T:gmake.sh.108.HOMQMV[12]: @mkdir: not found 8.Development:Projects/Libraries/netsurf/libwapcaplet>
I'm prettty sure I have mkdir, echo and sed in the SDK...
Edited by salass00 on 2012/11/26 8:42:59 Edited by salass00 on 2012/11/26 8:51:30
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
