Re: [osol-code] Build failure of snv_95 uts AMD64

Please reference the answer I got in -help from a delightful fellow. all should reference the very informative fact that (as one did mention in this thread) - it'z time for sun studio 12. Thanks for taking the time guys. dan. -- This message posted from opensolaris.org _

Re: [osol-code] documenting dependencies / External dependencies for building ON

Garrett D'Amore wrote: > I can't believe that we've got this kind of breakage.. did we also EOF > Studio 10 when we switched to Studio 11? Effectively, yes. The compiler team will only sell support contracts for and support customers using Studio 10 on releases older than Nevada - on Nevada, it'

Re: [osol-code] documenting dependencies / External dependencies for building ON

Alan Coopersmith wrote: > James Carlson wrote: > >> In other cases, that's not true. For example, the fact that we now >> need SS12 to build ON isn't subject to ARC review. That's a gate >> management issue, but it affects those who have build machines just as >> much as one of those architect

Re: [osol-code] documenting dependencies / External dependencies for building ON

James Carlson wrote: > In other cases, that's not true. For example, the fact that we now > need SS12 to build ON isn't subject to ARC review. That's a gate > management issue, but it affects those who have build machines just as > much as one of those architectural dependencies. Though given re

Re: [osol-code] documenting dependencies / External dependencies for building ON

John Plocher writes: > Nils Goroll wrote: > > And how is the problem of > > inter-consolidation dependencies solved for Solaris? > > One of the key activities we use to manage this is the ARC process, > specifically its interface taxonomy and focus on only allowing > components to consume Commit

Re: [osol-code] documenting dependencies / External dependencies for building ON

Nils Goroll wrote: > And how is the problem of > inter-consolidation dependencies solved for Solaris? One of the key activities we use to manage this is the ARC process, specifically its interface taxonomy and focus on only allowing components to consume Committed interfaces from others. If you

Re: [osol-code] Build failure of snv_95 uts AMD64

Jürgen Keil pisze: >> I'm building the kernel portion of snv_95, and after >> bldenv'ing and a dmake all of src/uts I receive the >> following error: >> >> --cut >> cc: Warning: illegal option -m64 >> cc: -xmodel should be used with -xarch={amd64|generic64} >> genoffsets: /opt/onbld/bin

Re: [osol-code] weirdness in SCSA dma stuff

"Garrett D'Amore" <[EMAIL PROTECTED]> wrote: > So, I've gotten reports of a strange bug in my SDcard, which seems to be > limited to using the card during single user mode on a laptop. The > message that comes through is: > > Sep 25 13:23:22 martin-nb rootnex: [ID 561485 kern.warning] WARNING:

Re: [osol-code] ARG_MAX vs. 64/32 Bit find(1) built into the Shell

> > > My questions are: > > > > > > - How do I get the 32 bit ARG_MAX value from > inside a > > > 64 bit program? > > > > Well, unless someone adds an _SC_ARG32_MAX and > _SC_ARG64_MAX, > > There is > > #define _ARG_MAX32 1048320 /* max length of args > to exec 32-bit program */ > #define

Re: [osol-code] Build failure of snv_95 uts AMD64

> I'm building the kernel portion of snv_95, and after > bldenv'ing and a dmake all of src/uts I receive the > following error: > > --cut > cc: Warning: illegal option -m64 > cc: -xmodel should be used with -xarch={amd64|generic64} > genoffsets: /opt/onbld/bin/i386/cw failed with statu

[osol-code] weirdness in SCSA dma stuff

So, I've gotten reports of a strange bug in my SDcard, which seems to be limited to using the card during single user mode on a laptop. The message that comes through is: Sep 25 13:23:22 martin-nb rootnex: [ID 561485 kern.warning] WARNING: sdcard: coding error detected, the driver is using dd

Re: [osol-code] Build failure of snv_95 uts AMD64

Doh. I thought it would pull all the content into this thread. Here's the original thread: (http://www.opensolaris.org/jive/thread.jspa?threadID=76221&tstart=0) All, I'm building the kernel portion of snv_95, and after bldenv'ing and a dmake all of src/uts I receive the following error:

Re: [osol-code] Build failure of snv_95 uts AMD64

Danny Webster wrote: > CC'ing this thread into code. Pretty useless without any context. Which mailing list did you start this thread on? James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog

Re: [osol-code] Build failure of snv_95 uts AMD64

CC'ing this thread into code. -- This message posted from opensolaris.org ___ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Re: [osol-code] what is the difference in LEX and Flex....

Hi bison is the GNU version of yacc. It supports extra semantics and new functionality. Without seeing the errors, I am unable to assist further. flex (the "F"ast Lexer) is the GNU version of lex. My wild guess is that the windows-compiled (cygwin?) version is perhaps updated to support the

Re: [osol-code] ARG_MAX vs. 64/32 Bit find(1) built into the Shell

"Richard L. Hamilton" <[EMAIL PROTECTED]> wrote: > > My questions are: > > > > - How do I get the 32 bit ARG_MAX value from inside a > > 64 bit program? > > Well, unless someone adds an _SC_ARG32_MAX and _SC_ARG64_MAX, There is #define _ARG_MAX32 1048320 /* max length of args to exec 32

Re: [osol-code] documenting dependencies / External dependencies for building ON

Hi, firstly, thanks to everyone having contributed to the discussion so far, reading it has been very interesting and helpful to understand better the structures OpenSolaris development teams act in. I totally agree that the top priority should be making Indiana a supported build platform, b