On Wed, 2 May 2012 12:21:55 -0700 (PDT) Edwin Beasant wrote:
> I'll send them in, with the bug description: I'll leave out the ones
> that have been fixed in the 2012 release?
yes, that might avoid confusion
> I believe its a combination of things:
> uname on solaris doesn't cleanly distinguish between 64 bit and 32 bit
> architectures:
> Additionally, bitness has to be explicitly specified to the compiler
> with -32 or -64 as appropriate (default 32, yes, that probably needs
> fixing ;-)
that's the biggest problem
> > if that doesn't work to your satisfaction a cc wrapper is probably the way
> > to go
> >
> > first make sure
> > bin/package
> > lists an appropriate ast hosttype
> > probably something like
> > sol11.i386-64
> > bin/package uses cc along with uname to determine the hosttype
> > (ast hosttypes do not get as detailed as say gcc host identifiers)
> Thats where I think we get the issues (see above)...
> x86:
> # bin/package
> sol11.i386
> sparc:
> # bin/package
> sol11.sun4
> So, I'm not entirely certain exactly how it can determine its
> 64-bit-ness, except by explicitly specifying it to bin/package as a
> HOSTTYPE?
> > then create a wrapper script
> > src/cmd/INIT/cc.sol11.i386-64
name the scripts
src/cmd/INIT/cc.sol11.i386-64
src/cmd/INIT/cc.sol11.sun4-64
and then specify the matching HOSTTYPE
bin/package make HOSTTYPE=sol11.i386-64
bin/package make HOSTTYPE=sol11.sun4-64
since bin/package does a viewpath build that puts all generated files in
arch/$HOSTTYPE/
you can point different hosts/HOSTTYPEs to the same package root
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
