Re: [gentoo-alt] Any interest in sandbox on (open)solaris?

[Mike Frysinger]

On Tuesday 18 November 2008 18:32:13 C. Bergström wrote:
> Mike Frysinger wrote:
> > On Tuesday 18 November 2008 17:33:55 C. Bergström wrote:
> >> Ok. I pulled the latest git work and with a few really dirty hacks to
> >> the configure it was rolling..
> >>
> >> (Here's some of the output of the failure.. I haven't looked at it at
> >> all) http://rafb.net/p/fELaK960.html
> >
> > very first rule if you want to make this work: never post log files to an
> > external site, especially one like rafb.net where things expire quickly.
> >
> > you're hitting an issue with what i hinted at earlier ... symbol
> > versioning. iirc, the symbol version script (for our purposes) should be
> > the same between the GNU linker and the Solaris linker.  but how you tell
> > the linker about the version script obviously wont be the same.  you'll
> > have to figure that out and we can add a configure test to detect the
> > linker in use.
> >
> > all those warnings are kind of painful too ... probably have to find a
> > autoconf macro for detecting attribute support in the compiler.  iirc,
> > glibc tends to use __GNUC__ type CPP macros though.
> >
> > the memory (xmalloc, etc...) arent too surprising.  that's a bit of a
> > mess atm and i intend to clean that stuff up anyways ...
> >
> > the symbols.h errors are odd.  probably a CPP difference between your
> > compiler and the GNU C compiler.
> >
> > you should figure out how solaris forces C++ exception handling.  clearly
> > it doesnt use the same flag as GCC: -fexceptions.  that'll have to be
> > turned into a configure compiler test as well.
> >
> > g'luck ... seems you got your work cut out for you :p
>
> Aww.. not even a little optimism? :P
>
> I could cheat and use cw which converts gcc flags over to sun cc flags
> and vice versa, but that's cheating..
>
> Down to the nitty gritty to get this to build.. Which is goal #1 to just
> get the thing to build..
>
> For "the symbols.h errors are odd. probably a CPP difference between
> your compiler and the GNU C compiler." did you mean
>
> "../libsbutil/sbutil.h", line 102: warning: attribute parameter
> "__printf__" is undefined

no, i was referring to the lines that have "symbols.h" in it.  probably macro 
pasting behavior difference ...

> 7284 inline  _Bool __check_arg_fd (int fd, const char *file, const char
> *func,   size_t line);

these functions are weird and something i know i need to clean up.  i would 
try dropping the inline/static markings from them all for now and worry about 
the other issues ... they're probably much more important.
-mike