On Feb 7, 2012, at 8:52 PM, Jeff Sickel wrote:
>
> On Feb 7, 2012, at 8:48 PM, Jeff Sickel wrote:
>
>>
>> On Feb 7, 2012, at 6:21 PM, erik quanstrom wrote:
>>
Now gs builds (untested) on/for arm.
>>>
>>> gs already built/works on arm. did someone break it?
>>> it is too slow to u
On Feb 7, 2012, at 8:48 PM, Jeff Sickel wrote:
>
> On Feb 7, 2012, at 6:21 PM, erik quanstrom wrote:
>
>>>
>>> Now gs builds (untested) on/for arm.
>>
>> gs already built/works on arm. did someone break it?
>> it is too slow to use, though. does anyone know what's
>> wrong with gs on amd64?
On Feb 7, 2012, at 6:21 PM, erik quanstrom wrote:
>>
>> Now gs builds (untested) on/for arm.
>
> gs already built/works on arm. did someone break it?
> it is too slow to use, though. does anyone know what's
> wrong with gs on amd64?
not sure, but it as also failing to build for 386 even
with
>
> Now gs builds (untested) on/for arm.
gs already built/works on arm. did someone break it?
it is too slow to use, though. does anyone know what's
wrong with gs on amd64?
- erik
On Feb 7, 2012, at 3:50 PM, Jeff Sickel wrote:
> don't forget to update /sys/include/ape/zlib.h
And for /sys/src/cmd/gs:
% diffy mkfile src/ld.tr
diff /n/dump/2012/0207/sys/src/cmd/gs/mkfile mkfile
141c141
< $CC $CFLAGS zlib/$stem.c; mv $stem.$O obj
---
> $CC $CFLAGS -D_C99_SNPRINT
don't forget to update /sys/include/ape/zlib.h
While hitting some ape pcc errors while building my arm tree,
I realized that zlib was quite a bit out of date. The latest
zlib-1.2.6 can be pulled down and installed in
/sys/src/cmd/gs/zlib
You'll need to remove gzio.c if you didn't do a complete replace,
and then modify the following:
I'm working on a file system that will keep most of the tree in memory
at all times (in fact, the "active" tree is only in memory). It archives frozen
temporary copies to a disk partition until it gets full (in which case the
oldest
is discarded) and an external program is going to make permanent
Just a quick question for other users of ARM based machines:
Should the ape/lib/openssl be ignored for ARM, or is there a decent alternative
for objtype=arm when trying to
build it? The current build fails as /sys/include/ape/openssl/opensslconf.h
errors out with 'unknown objtype'.
Otherwise,
