On Wednesday 28 January 2009 19:01:07 C. Bergström wrote:
> It builds.. it runs.. and now trying to get it to run correctly..
> (forgive the verbose post please)  I've been building everything as
> 64bit.. and wonder if I need a 32bit libsandbox.so as well?  (I need to
> fix scanelf as it's been broken, but that wouldn't account for why rm
> gave the same error)

you need a binary version for whatever you want to protect.  if you arent 
running 32bit programs during normal build/install, then you wont need a 32bit 
libsandbox.  not sure multilib will even work atm with non-standard lib paths 
though.

> Small note.. this seems to be needed..
> SANDBOX_WRITE="/dev/fd:/proc/self/fd:/dev/dtrace/helper"

i'm guessing you're only talking about /dev/dtrace/helper ... in that case, 
you should be able to drop that into /etc/sandbox.d/

> ld.so.1: install: fatal: libsandbox.so: open failed: No such file or
> directory

this should be fixed in latest sandbox already ... so make sure you're using 
sandbox-1.3.3 or newer

> "../libsbutil/sbutil.h", line 101: warning: attribute parameter
> "__printf__" is undefined

i imagine there's an autoconf test somewhere for this i can steal.  or we just 
ignore it.

> "wrapper-funcs/__wrapper_simple.c", line 31:
> warning: assignment type mismatch: pointer to function(pointer to const
> char, unsigned long) returning int "=" pointer to void
> "symbols.h", line 30: warning: syntax error:  empty declaration

could you post symbols.h as an attachment ?  this is generated on the fly, so 
line numbers are useless w/out the generated file.

> "wrapper-funcs/__wrapper_simple.c", line 21: syntax error before or at:
> __off64_t

will have to figure out how LFS is handled on opensolaris ... maybe assuming 
the __XXX form exists is bad mojo.
-mike