2:21 a.m.
On Wed, 23 Jul 2008, Chris Young wrote:
On Tue, 22 Jul 2008 19:37:52 +0100 (BST), John-Mark Bell wrote:
> I'm not sure I have any recollection of it being solved, tbh. None of us
> have been able to reproduce it, so it's somewhat difficult to work out
> what's happening.
Well, I fixed it, but I'm not entirely sure how. I deleted a load of
defines from the makefile (ones I had initially copied from the debug
target and then forgotten about) and just recompiled it again from
scratch.
It'd be really useful if we could work out what's causing this, so we know
for the future. Do you know which defines you removed?
J.
1:22 p.m.
New subject: regexec
On Thu, 24 Jul 2008 08:21:47 +0100 (BST), John-Mark Bell wrote:
On Wed, 23 Jul 2008, Chris Young wrote:
> On Tue, 22 Jul 2008 19:37:52 +0100 (BST), John-Mark Bell wrote:
>
>> I'm not sure I have any recollection of it being solved, tbh. None of us
>> have been able to reproduce it, so it's somewhat difficult to work out
>> what's happening.
>
> Well, I fixed it, but I'm not entirely sure how. I deleted a load of
> defines from the makefile (ones I had initially copied from the debug
> target and then forgotten about) and just recompiled it again from
> scratch.
It'd be really useful if we could work out what's causing this, so we know
for the future. Do you know which defines you removed?
I removed the following:
-D_BSD_SOURCE \
-D_XOPEN_SOURCE=600 \
-D_POSIX_C_SOURCE=200112L \
-D_NETBSD_SOURCE \
$(shell xml2-config --cflags)
I had xml2 simply as -lxml2 in ldflags already, I'm not sure what the
defines do.
Chris
5:05 p.m.
New subject: regexec
On 24 Jul 2008 19:22:05 +0100
"Chris Young" <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
> It'd be really useful if we could work out what's
causing this, so
> we know for the future. Do you know which defines you removed?
I removed the following:
-D_BSD_SOURCE \
-D_XOPEN_SOURCE=600 \
-D_POSIX_C_SOURCE=200112L \
-D_NETBSD_SOURCE \
$(shell xml2-config --cflags)
I had xml2 simply as -lxml2 in ldflags already, I'm not sure what the
defines do.
The defines enable the features of the C library that we require on
various operating systems. On *BSD libc, glibc and Solaris, you need
this collection of #defines to enable modern library functionality.
It surprises me that these matter, as if your C library triggers on
them, the only sensible thing it could do is enable more
functionality. This may point to an issue in the C library on your
host system. Try removing one at a time to see if it's just a specific
one that causes the issue, and then grep your standard headers to see
what triggers on it.
B.
5:44 p.m.
New subject: regexec
On Thu, 24 Jul 2008 23:05:01 +0100, Rob Kendrick wrote:
The defines enable the features of the C library that we require on
various operating systems. On *BSD libc, glibc and Solaris, you need
this collection of #defines to enable modern library functionality.
It surprises me that these matter, as if your C library triggers on
them, the only sensible thing it could do is enable more
functionality. This may point to an issue in the C library on your
host system. Try removing one at a time to see if it's just a specific
one that causes the issue, and then grep your standard headers to see
what triggers on it.
I put them all back and can't reproduce the problem again, although
strncasecmp is still crashing.
I've recompiled the whole caboodle with a different clib now and not a
single crash, so I think blaming the C library is the correct thing to
do.
I now have lots of work to do writing native code, currently it opens
a window, fetches a page and sets the window's title - and then sits
in an endless loop doing nothing, as that's as far as I got.
btw, file: URLs seem to be adding a slash to the beginning of the
path, no matter how I specify them. This is very annoying, as a slash
at the start of a path indicates the parent of the current directory.
file://default.css will translate to /default.css which looks in the
parent directory for the file default.css. To get default.css in the
current directory I have to ask for file://netsurf/default.css (which
only works if the current directory is called "netsurf"). Absolute
paths are impossible as file://ram:default.css translates to
/ram:default.css which asks me to insert disk "/ram", which will never
exist.
How do I stop this?
Thanks
Chris
6:01 p.m.
New subject: regexec
On 30 Jul 2008 23:44:20 +0100
"Chris Young" <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
I now have lots of work to do writing native code, currently it
opens
a window, fetches a page and sets the window's title - and then sits
in an endless loop doing nothing, as that's as far as I got.
If you want a Subversion account to check your current work in, please
ask. Checking in often and early is worthwhile; especially given we've
made quite large changes to the Make system recently.
btw, file: URLs seem to be adding a slash to the beginning of the
path, no matter how I specify them. This is very annoying, as a slash
at the start of a path indicates the parent of the current directory.
Ah, that may be a bad assumption on my part. All the /sensible/ OSes
treat multiple contiguous slashes as a single one. :) You'll want to
examine the content of content/fetchers/fetch_data.c
B.
5294
days inactive
5300
days old
netsurf-dev@netsurf-browser.org
4 comments
3 participants
participants (3)
-
Chris Young -
John-Mark Bell -
Rob Kendrick