So in general, CFLAGS must be passed to the linker (it contains optimization and debugging stuff that should be consistent). The -x option is very special in that it cannot be passed to the linker.
Oh yes, I didn’t describe my fix properly, but you’re right… From: [email protected] [mailto:[email protected]] On Behalf Of Jed Brown Sent: Thursday, May 24, 2012 7:34 PM To: For users of the development version of PETSc Subject: Re: [petsc-dev] Need a CFLAGS that does is *not* included in the link On Thu, May 24, 2012 at 9:31 PM, Chetan Jhurani <[email protected]> wrote: I faced a similar problem when using -x argument with nvcc during petsc configuration, which could be fixed if CFLAGS was not passed to the linker. So sending this info in case it is useful. So in general, CFLAGS must be passed to the linker (it contains optimization and debugging stuff that should be consistent). The -x option is very special in that it cannot be passed to the linker. [jhurani@enrico ~]$ cat a.c int main() { } [jhurani@enrico ~]$ nvcc a.c -x c++ -c [jhurani@enrico ~]$ nvcc a.o -x c++ a.o:1: error: stray '\177' in program a.o:1: error: stray '\2' in program a.o:1: error: stray '\1' in program a.o:1: error: stray '\1' in program a.o:1:8: warning: null character(s) ignored a.o:1: error: stray '\1' in program a.o:1:18: warning: null character(s) ignored and many more lines… Chetan From: [email protected] [mailto:[email protected]] On Behalf Of Jed Brown Sent: Thursday, May 24, 2012 7:09 PM To: For users of the development version of PETSc Subject: [petsc-dev] Need a CFLAGS that does is *not* included in the link Building PETSc with clang++ produces a warning about compiling *.c as C++ being deprecated. To silence the warning, we would need to pass "-x c++" to the compiler, but NOT to the linker. CFLAGS is currently also passed to the linker. Is this something we want to fix? Clang used to SEGV when "-x c++" is passed to the linker. Now (latest SVN) it just interprets the object file as C++ source (which obviously produces a ton of garbage). http://llvm.org/bugs/show_bug.cgi?id=12924