Re: [Plplot-devel] KCC flags

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > On Thu, 26 Dec 2002, Maurice LeBrun wrote:
 > 
 > > On another note, I need to modify the command line args used by the compiler
 > > or linker.  Although I've made progress, so far I still haven't gotten a
 > > completely successful build on either: Solaris, OSF1, or IRIX.  As for the
 > > first two, the build is trying to pass the "-fPIC" option to the KCC compiler
 > > which isn't supported.  So I need to get rid of that, or change it to +KPIC.
 > > I'm reading through the AM info pages now, what a pain.
 > >
 > > As for IRIX, I need to pass "-64 -mips4" somehow.  This at least I know I can
 > > do in principle, probably by using flags like I did before:
 > >
 > > USER_FLAGS_CXX:	add these to CXXFLAGS
 > > USER_FLAGS_CC:	add these to CCFLAGS

(oops, typo, the latter should just be 1 "C")

 > Can you just set LDFLAGS to +KPIC and CXXFLAGS and CFLAGS to "-64 -mips4" in
 > the environment before you configure?  

Potentially, yes.  However my old configure script modified CXXFLAGS and
CFLAGS according to the various command line flags: --with-debug,
--with-profile, --with-opt.  So I used the "USER_FLAGS.." variables to
only add to that as needed for the vendor compiler, architecture, etc.

In other words, setting USER_FLAGS_CXX means: I trust the CXXFLAGS the
configure script is giving me, just add these.  We can still set CXXFLAGS
directly, but then we're giving up control through the usual command-line
flags.  That's what much of the previous logic in sysconf.in was for.

Are the --with-profile, --with-debug, etc, options even being honored any more?

 > I believe autotools tries really hard
 > to allow the user to override that way.  

Yeah I noticed that autotools uses AM_CXXFLAGS, etc, instead of CXXFLAGS, etc,
passing the latter along unmodified.

 > Of course, this suggestion will
 > only work if the KCC compiler only warns about the -fPIC flag rather than
 > aborting completely if it encounters it.  If this works with environment
 > variables, then it will be easier to proceed to automating it.

I just realized I misread the build output.  Indeed, KCC is only warning about
the -fPIC flag, so no need to do anything about it just yet.  The real problem
is a lot more sinister:

/bin/bash ../../libtool --mode=compile KCC -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include  -I../../libltdl   +K2 -O2 -c -o plstream.lo `test -f 'plstream.cc' || echo './'`plstream.cc
mkdir .libs
KCC -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../libltdl +K2 -O2 -c plstream.cc  -fPIC -DPIC -o .libs/plstream.lo
KCC: Option -fPIC not recognized.
cc: illegal suffix of output filename
make[2]: *** [plstream.lo] Error 1

Uh oh.. KCC always uses the vendor compiler as its backend.  And in this case
it looks like Sun cc doesn't support other than ".o" for the suffix.  This
could potentially be a real problem for Geoff & I.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)