Default LANG?
by Anthony J. Bentley
Hi,
After upgrading to 3.0 on my system, NetSurf-GTK looks like this:
http://i.imgur.com/BUr5Tj4.png
It turns out this is because LANG is unset in my environment (although
LC_CTYPE=en_US.UTF8). If I run "LANG=en netsurf", everything is peachy.
Would it be possible to default to "en" if LANG is unset and/or LANG=C?
--
Anthony J. Bentley
10 years, 1 month
Auto-builder
by Chris Young
Seems to be in a stuck state due to chimera being off-line.
10 years, 1 month
Tests rely on alloca()
by Anthony J. Bentley
Hi,
Several tests use alloca() to allocate memory. But alloca() is not part of
C99, and on OpenBSD this leads to linking errors since the NetSurf build
system specifies -std=c99:
LINK: build-OpenBSD-OpenBSD-release-lib-shared/test_parser
cc -o build-OpenBSD-OpenBSD-release-lib-shared/test_parser build-OpenBSD-OpenBSD-release-lib-shared/test_parser.o -Lbuild-OpenBSD-OpenBSD-release-lib-shared/ -lhubbub -g -L/usr/local/lib -liconv -L/usr/local/lib -ljson-c
build-OpenBSD-OpenBSD-release-lib-shared/test_parser.o(.text+0x578): In function `run_test':
test/parser.c:28: undefined reference to `alloca'
collect2: ld returned 1 exit status
These are the files that use alloca():
libhubbub:
test/parser.c
test/tokeniser2.c
test/tokeniser3.c
test/tree.c
libcss:
test/css21.c
test/parse-auto.c
libparserutils:
test/cscodec-8859.c
test/cscodec-ext8.c
test/cscodec-utf8.c
test/cscodec-utf16.c
10 years, 1 month
new Dutch translation
by Simon Voortman
Hi list,
Where should I submit new Dutch translations?
TIA,
Simon Voortman.
10 years, 1 month
Clang warning fixes
by Rob Kendrick
I've pushed a handful of branches containing some clang warning fixes.
libnsfb/rjek/clang-warnings
libcss/rjek/clang-warnings
nsjsgenbind/rjek/clang-warnings
netsurf/rjek/clang-warnings
B.
10 years, 1 month
Javascript feature details
by Dave Higton
Would it be possible to list the progress on individual Javascript
features, in the same way as the CSS features? That way, those of
us who are interested can play with features, learn Javascript,
and test the features.
Or will implementation be an all-or-nothing event - suddenly one
day all of Javascript will work?
Dave
____________________________________________________________
GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at http://www.inbox.com/smileys
Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails
10 years, 1 month
Fetch polling change branch
by Chris Young
All
I've just created a branch chris/scheduled-fetches because currently
when downloading, NetSurf runs in a busy loop fetching data. This
really slows down the whole system ounder AmigaOS because NetSurf ends
up hogging most of the processor time.
In the branch I've changed the main loop so it schedules itself
to do an immediate hlcache_poll, rather than directly calling
hlcache_poll itself. This means that operating systems with something
like Wait(), which will wait for an event to come in, eg. for one
of NetSurf's scheduled tasks, will be able to use Wait() rather than
dropping out of gui_poll and letting NetSurf busy-loop, and be a bit
more multi-tasking friendly. It is certainly working well here, with
a minor change to ignore gui_poll's "active" flag.
I'm not sure what implications this has for other platforms we target.
I don't see that it would cause any problems, as the only real change
is that schedule() calls hlcache_poll() rather than the main loop
doing it - unless there are some hidden reasons why that is a bad
idea?
Ideally I'd like to see this in 3.0 if possible, as it has solved
something that has been bugging me for ages!
Thoughts?
Chris
10 years, 1 month
NetSurf Build System / Atari support
by Ole
Hello,
It looks like the current netsurf buildsystem isn't able to compile
correct executables for the atari target, this is especially bad when
running
on coldfire, where the build failure results in illegal instructions
(when m68k CPU emulation is turned off).
(the sdk build maybe suffers the same problem, but that's another
story)
On my local box I use Verbose mode of make, to see the actual compiler
commands.
Let's have a look at the atari support within the netsurf buildsystem:
--- snip ---
# FreeMiNT / atari
ifeq ($(TARGET),atari)
ifeq ($(HOST),atari)
# Building on FreeMiNT
# Nothing to do, as we assume the default tooling works
else
# Cross compiling for FreeMiNT
ATARIARCH ?= 68020-60
GCCSDK_INSTALL_ENV ?= /opt/netsurf/m68k-atari-mint
GCCSDK_INSTALL_CROSSBIN ?= /opt/netsurf/m68k-atari-mint/cross/bin
CC__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-gcc
CXX__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-g++
AR__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-ar
ifeq ($(ATARIARCH),68000)
ARCHFLAGS :=
ARCHDIR :=
endif
ifeq ($(ATARIARCH),68020-60)
ARCHFLAGS := -m$(ATARIARCH)
ARCHDIR := /$(ATARIARCH)
endif
ifeq ($(ATARIARCH),v4e)
ARCHFLAGS := -mcpu=5475
ARCHDIR := /m5475
endif
CFLAGS := $(CFLAGS) -U__STRICT_ANSI__
-I$(GCCSDK_INSTALL_ENV)/include $(ARCHFLAGS)
CXXFLAGS := $(CXXFLAGS) -U__STRICT_ANSI__
-I$(GCCSDK_INSTALL_ENV)/include $(ARCHFLAGS)
LDFLAGS := $(LDFLAGS) -L$(GCCSDK_INSTALL_ENV)/lib$(ARCHDIR)
PREFIX ?= $(GCCSDK_INSTALL_ENV)
endif
endif
--- snip ---
First thing to notice is the fact that it assumes you do pass the
environment variable ATARIARCH
to specify the CPU type. If you do not specify this variable, the cpu
defaults to 68020-60, which
is definitly wrong for coldfire compilation.
I'm assuming that the netsurf build system does not set ATARIARCH.
I'm open for suggestions, how to specify and resolve the CPU type
differently, of course.
Also look at the output of libcss build:
http://ci.netsurf-browser.org/jenkins/job/libcss/TARGET=m5475-atari-mint,...
You can not see which compiler was used. You can not see which
CFLAGS/LDFLAGS where used.
Second thing to notice is the fact that it assumes the m68k-atari-mint
toolchain to be used:
CC__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-gcc
CXX__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-g++
AR__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-ar
When compiling for coldfire (the way it was meant to be: by setting
ATARIARCH) it will fail to find the compiler
because the m68k-atari-mint compiler is not located in the coldfire sdk
dirs.
Of course the script could be adjusted like this:
ifeq ($(ATARIARCH),v4e)
ARCHFLAGS := -mcpu=5475
ARCHDIR := /m5475
CC__ := $(GCCSDK_INSTALL_CROSSBIN)/m5475-atari-mint-gcc
CXX__ := $(GCCSDK_INSTALL_CROSSBIN)/m5475-atari-mint-g++
AR__ := $(GCCSDK_INSTALL_CROSSBIN)/m5475-atari-mint-ar
endif
But that would mean, that the average buildsystem user is not able to
compile netsurf
on his own box, when he doesn't want to use the m5475-atari-mint-xxx
provided by the netsurf sdk build.
As an example, just take this simple make command and see how it fails:
/media/src/netsurf.git/libnsgif$
GCCSDK_INSTALL_CROSSBIN=/opt/netsurf/m5475-atari-mint/cross/bin
GCCSDK_INSTALL_ENV=/opt/netsurf/m5475-atari-mint make TARGET=atari
ATARIARCH=v4e
/bin/sh: /opt/netsurf/m5475-atari-mint/cross/bin/m68k-atari-mint-gcc:
not found
/bin/sh: /opt/netsurf/m5475-atari-mint/cross/bin/m68k-atari-mint-gcc:
not found
/opt/netsurf/m5475-atari-mint/share/netsurf-buildsystem/makefiles/Makefile.tools:466:
*** Unable to detect toolchain. Schluss.
Using m68k-atari-mint-gcc to compile atari coldfire software is de
facto standard and
I don't want to explain people that things are different with netsurf
;)
However, if this is the only way to implement clean coldfire support in
the netsurf
buildsystem, I'm happy to take that pill.
Can we add the ATARIARCH environment variable, like it is done for the
netsurf build?
Valid values:
ATARIARCH=68020-60
ATARIARCH=v4e
The coldfire build will be broken then (look at the example above),
because it won't be able to find the toolchain (except it is explicitly
set), however, when that happens, I probably already fixed the toolchain
names for coldfire within the makefile.
10 years, 1 month
