[petsc-dev] Need a CFLAGS that does is *not* included in the link

[Matthew Knepley]

On Thu, May 24, 2012 at 10:09 PM, Jed Brown  wrote:

> 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?


According to autoconf, CFLAGS goes with both. CPPFLAGS is only for the
compiler.

   Matt


> 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
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL: 

[petsc-dev] Need a CFLAGS that does is *not* included in the link

[Jed Brown]

On Thu, May 24, 2012 at 9:50 PM, Matthew Knepley  wrote:

> According to autoconf, CFLAGS goes with both. CPPFLAGS is only for the
> compiler.


Cool, where do I add to CPPFLAGS based on the type of compiler? It would be
natural in compilerOptions.py, but it's not clear to me where to put it.
-- next part --
An HTML attachment was scrubbed...
URL: 

[petsc-dev] Need a CFLAGS that does is *not* included in the link

[Jed Brown]

On Thu, May 24, 2012 at 9:31 PM, Chetan Jhurani 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 at enrico ~]$ cat a.c
>
> int main()
>
> {
>
> }
>
> ** **
>
> [jhurani at enrico ~]$ nvcc a.c -x c++ -c
>
> [jhurani at 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:* petsc-dev-bounces at mcs.anl.gov [mailto:
> petsc-dev-bounces at mcs.anl.gov] *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
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120524/006421ef/attachment.html>

[petsc-dev] Need a CFLAGS that does is *not* included in the link

[Jed Brown]

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
-- next part --
An HTML attachment was scrubbed...
URL: 

[petsc-dev] Need a CFLAGS that does is *not* included in the link

[Chetan Jhurani]

> 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: petsc-dev-bounces at mcs.anl.gov [mailto:petsc-dev-boun...@mcs.anl.gov] 
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  
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 at enrico ~]$ cat a.c

int main()

{

}

 

[jhurani at enrico ~]$ nvcc a.c -x c++ -c

[jhurani at 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: petsc-dev-bounces at mcs.anl.gov [mailto:petsc-dev-boun...@mcs.anl.gov] 
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

 

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120524/97c98350/attachment.html>

[petsc-dev] Need a CFLAGS that does is *not* included in the link

[Chetan Jhurani]

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.

 

[jhurani at enrico ~]$ cat a.c

int main()

{

}

 

[jhurani at enrico ~]$ nvcc a.c -x c++ -c

[jhurani at 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: petsc-dev-bounces at mcs.anl.gov [mailto:petsc-dev-boun...@mcs.anl.gov] 
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

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120524/be1a3504/attachment.html>