Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Jeffrey Walton]

On Thu, Aug 23, 2012 at 9:13 AM, Jeffrey Walton  wrote:
> On Wed, Aug 22, 2012 at 9:41 PM, Mike Frysinger  wrote:
>> On Wednesday 22 August 2012 18:28:52 Russ Allbery wrote:
>>> special exceptions.  Being able to turn off executable stack as at least
>>> another easily-accessible option is an interesting idea, and I may raise
>>> that on debian-devel.  (Although it can be a little hard to predict which
>>> packages need that.
>>
>> it's trivial to locate:
>> readelf -lW /bin/bash | grep GNU_STACK
>> if it's set as RWE, that's bad.  if the ELF lacks a GNU_STACK, that's bad.
> I believe there is more to it. The PT_GNU_STACK marking must be
> present *and* have a size of 0. See Ian Lance Taylor's blog
Bad reference (my apologies). Try Ian's blog on Executable Stacks
instead http://www.airs.com/blog/archives/518.

Jeff

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Jeffrey Walton]

On Wed, Aug 22, 2012 at 9:41 PM, Mike Frysinger  wrote:
> On Wednesday 22 August 2012 18:28:52 Russ Allbery wrote:
>> special exceptions.  Being able to turn off executable stack as at least
>> another easily-accessible option is an interesting idea, and I may raise
>> that on debian-devel.  (Although it can be a little hard to predict which
>> packages need that.
>
> it's trivial to locate:
> readelf -lW /bin/bash | grep GNU_STACK
> if it's set as RWE, that's bad.  if the ELF lacks a GNU_STACK, that's bad.
I believe there is more to it. The PT_GNU_STACK marking must be
present *and* have a size of 0. See Ian Lance Taylor's blog
http://www.airs.com/blog/archives/120.

Trivia: How does one audit a Gentoo binary for no-exec heap
compliance. Hint: its not readelf because Gentoo did not modify the
utility to dump PaX flags. (I'm asking because it took me some time to
discover the information).

Jeff

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Jeffrey Walton]

On Wed, Aug 22, 2012 at 7:21 PM, Mike Frysinger  wrote:
> On Wednesday 22 August 2012 18:17:37 Jeffrey Walton wrote:
>> The posture would have saved a number of folks from, for example,
>> Pidgin's latest rounds of Critical Vulnerabilities (memory corruption
>> and code execution). No-exec stacks and heaps would have reduced
>> many/most to an annoying UI problem (a call to abort()).
>
> bad example: pidgin doesn't require execstacks (i'm not sure it ever has), so
> that would have made 0 difference.
I think Pidgin is a perfect example (humbly):
http://www.pidgin.im/news/security/ and
http://www.securityfocus.com/archive/105/515814.

If Pidgin does not require NX stacks and heaps, why was it running
with them? Not only did Pidgin not observe an SDLC on Linux, it did
not do so on Windows either. "Pidgin for Windows (2.10.6) - Missing
DEP and ASLR," http://developer.pidgin.im/ticket/15209,

Linux might not have an SDLC, but Microsoft certainly does.

> no one does exec-heaps by default ... the
> code itself has to explicitly do this, and there's nothing the toolchain could
> have done to stop that (not that pidgin enables exec on memory returned by
> malloc afaik).  only a kernel patch (such as PaX) which explicitly denies
> mprotect calls that try to enable exec & write bits simultaneously would have
> prevented this scenario proactively.
Its unfortunate that most Linux do not do no-exec heaps. Gentoo is an
exception with its PaX security.

X^W is fine, too. Nothing is befuddling since the defenses are there -
all a programmer has to do is ask for them.

> in fact, very little to no packages request an executable stack by default.
> binary-only packages tend to be the only ones nowadays that do, and that's
> usually because the people producing the pkgs have broken code.
All code has bugs. Its the reason we should be running with full defenses.

Jeff

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Mike Frysinger]

On Wednesday 22 August 2012 18:28:52 Russ Allbery wrote:
> special exceptions.  Being able to turn of executable stack as at least
> another easily-accessible option is an interesting idea, and I may raise
> that on debian-devel.  (Although it can be a little hard to predict which
> packages need that.

it's trivial to locate:
readelf -lW /bin/bash | grep GNU_STACK
if it's set as RWE, that's bad.  if the ELF lacks a GNU_STACK, that's bad.

or use scanelf to quickly find all ELFs on the system:
scanelf /{,usr/}{,s}bin -qry -F '%e %F'

very few packages in Gentoo have these (69 out of ~15k), and almost all of 
those are either binary-only packages or games.

> Hm, and I seem to recall that GCC does some stuff with executable stack
> automatically.)

yes, trampolines can trigger executable stacks, but usually that only happens 
with nested functions, which is usually pretty easy to rewrite to avoid.  i 
think i've seen maybe two packages where this came up (one of which was grub).

> > Autoconf could use ac_cflags as it being used now(?) and save
> > ac_warnings for later use (by Automake?) when real source files are
> > compiled.
> 
> It would be nice to have some additional support directly in standard
> Autoconf macros for handling compiler warning flags, although I suspect
> there is stuff in both the macro archive and in gnulib.

yes, the autoconf-archive has a bunch already written
-mike


signature.asc
Description: This is a digitally signed message part.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Mike Frysinger]

On Wednesday 22 August 2012 18:17:37 Jeffrey Walton wrote:
> The posture would have saved a number of folks from, for example,
> Pidgin's latest rounds of Critical Vulnerabilities (memory corruption
> and code execution). No-exec stacks and heaps would have reduced
> many/most to an annoying UI problem (a call to abort()).

bad example: pidgin doesn't require execstacks (i'm not sure it ever has), so 
that would have made 0 difference.  no one does exec-heaps by default ... the 
code itself has to explicitly do this, and there's nothing the toolchain could 
have done to stop that (not that pidgin enables exec on memory returned by 
malloc afaik).  only a kernel patch (such as PaX) which explicitly denies 
mprotect calls that try to enable exec & write bits simultaneously would have 
prevented this scenario proactively.

in fact, very little to no packages request an executable stack by default.  
binary-only packages tend to be the only ones nowadays that do, and that's 
usually because the people producing the pkgs have broken code.
-mike


signature.asc
Description: This is a digitally signed message part.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Jeffrey Walton]

On Wed, Aug 22, 2012 at 6:17 PM, Jeffrey Walton  wrote:
> On Wed, Aug 22, 2012 at 3:36 PM, Russ Allbery  wrote:
>> Jeffrey Walton  writes:
>>
>> Here's what Debian is using:
>>
>> CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat 
>> -Werror=format-security
>> CPPFLAGS=-D_FORTIFY_SOURCE=2
>> CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat 
>> -Werror=format-security
>> FFLAGS=-g -O2
>> LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now
> Debian does a good job. I think there is room for improvement (such as
> DEP and ASLR), and hope the maintainers stiffen their security posture
> in the future.
Forgot to mention I know some folks in DoD that have some really
interesting stack based attacks. They can take out an innocent looking
frame in an area different than the call site. Hence the reason to
consider -fstack-protector-all (make it as painful as possible on
them).

Jeff

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Russ Allbery]

Jeffrey Walton  writes:

> Debian does a good job. I think there is room for improvement (such as
> DEP and ASLR), and hope the maintainers stiffen their security posture
> in the future. The idea: make it secure out of the box, and let those
> who want to shot themselves in the foot do so. For example, apply
> -z,noexecstack out of the box, and let folks turn it off with
> -z,execstack.

Right.  Debian took a fairly conservative approach (in fact, pie and
bindnow are off by default, but can be easily turned on) because we were
trying to do something archive-wide without having to make a lot of
special exceptions.  Being able to turn of executable stack as at least
another easily-accessible option is an interesting idea, and I may raise
that on debian-devel.  (Although it can be a little hard to predict which
packages need that.  Hm, and I seem to recall that GCC does some stuff
with executable stack automatically.)

> This was a very good point and I had to think about it for a while.

> Are there Autoconf variable for this? For example, rather than:
>   ./configure "CFLAGS=..." "CXXFLAGS=..."

> could we instead use Autoconf defined stuff:
>   ./configure "ac_warnings=-Wall -Wextra -Wconversion" \
> "ac_cflags=-fstack-protector-all..." \
> ac_so_flags=... ac_exe_flags=...

There are not, at least so far as I know.

It's a little tricky to add the flags after the fact unless you override
all of CFLAGS at build time and provide the full set of hardening flags
again.  One of the standard tricks is to override CC instead, with
something like:

make CC="gcc -Wall -Wextra"

> Autoconf could use ac_cflags as it being used now(?) and save
> ac_warnings for later use (by Automake?) when real source files are
> compiled.

It would be nice to have some additional support directly in standard
Autoconf macros for handling compiler warning flags, although I suspect
there is stuff in both the macro archive and in gnulib.

-- 
Russ Allbery (r...@stanford.edu) 

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Jeffrey Walton]

On Wed, Aug 22, 2012 at 3:36 PM, Russ Allbery  wrote:
> Jeffrey Walton  writes:
>
>> $ ./configure CFLAGS="-Wall -Wextra -Wconversion -fPIE
>> -Wno-unused-parameter -Wformat=2 -Wformat-security
>> -fstack-protector-all -Wstrict-overflow -Wl,-pie -Wl,-z,noexecstack
>> -Wl,-z,relro -Wl,-z,now"
>
> The thing that jumps out at me as different between what Debian uses for
> its normal hardening flags and what you're using is the -Wl,-pie flag in
> CFLAGS.  Debian just uses -fPIE in CFLAGS and then adds -fPIE -pie to
> LDFLAGS.  I'm not sure if that would make a difference.
Yea, I usually use -fPIE -pie (or -fPIC -pic),  but I was having so
much trouble I tried passing -pie directly to the linker.

> You in general want to avoid ever using -Wl if you can help it, since
> you're hiding the flag from the compiler by using that.  If the compiler
> needed to know that you were linking that way so that it could do other
> magic itself, you break that support by using -Wl.
I've never really thought of it that way - it was more like :I'm
talking to the linker." Good point, taken.

> Here's what Debian is using:
>
> CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat 
> -Werror=format-security
> CPPFLAGS=-D_FORTIFY_SOURCE=2
> CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat 
> -Werror=format-security
> FFLAGS=-g -O2
> LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now
Debian does a good job. I think there is room for improvement (such as
DEP and ASLR), and hope the maintainers stiffen their security posture
in the future. The idea: make it secure out of the box, and let those
who want to shot themselves in the foot do so. For example, apply
-z,noexecstack out of the box, and let folks turn it off with
-z,execstack.

The posture would have saved a number of folks from, for example,
Pidgin's latest rounds of Critical Vulnerabilities (memory corruption
and code execution). No-exec stacks and heaps would have reduced
many/most to an annoying UI problem (a call to abort()).

> Also, you should generally not add -Wall -Wextra to the configure flags,
> and instead add it after configure completes, since many of the tricks
> configure has to use will result in warnings when you turn on all the
> compiler warnings, which can confuse configure.
This was a very good point and I had to think about it for a while.

Are there Autoconf variable for this? For example, rather than:
  ./configure "CFLAGS=..." "CXXFLAGS=..."

could we instead use Autoconf defined stuff:
  ./configure "ac_warnings=-Wall -Wextra -Wconversion" \
"ac_cflags=-fstack-protector-all..." \
ac_so_flags=... ac_exe_flags=...

Autoconf could use ac_cflags as it being used now(?) and save
ac_warnings for later use (by Automake?) when real source files are
compiled.

Jeff

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Russ Allbery]

Jeffrey Walton  writes:

> $ ./configure CFLAGS="-Wall -Wextra -Wconversion -fPIE
> -Wno-unused-parameter -Wformat=2 -Wformat-security
> -fstack-protector-all -Wstrict-overflow -Wl,-pie -Wl,-z,noexecstack
> -Wl,-z,relro -Wl,-z,now"

The thing that jumps out at me as different between what Debian uses for
its normal hardening flags and what you're using is the -Wl,-pie flag in
CFLAGS.  Debian just uses -fPIE in CFLAGS and then adds -fPIE -pie to
LDFLAGS.  I'm not sure if that would make a difference.

You in general want to avoid ever using -Wl if you can help it, since
you're hiding the flag from the compiler by using that.  If the compiler
needed to know that you were linking that way so that it could do other
magic itself, you break that support by using -Wl.

Here's what Debian is using:

CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security
CPPFLAGS=-D_FORTIFY_SOURCE=2
CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security
FFLAGS=-g -O2
LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now

Also, you should generally not add -Wall -Wextra to the configure flags,
and instead add it after configure completes, since many of the tricks
configure has to use will result in warnings when you turn on all the
compiler warnings, which can confuse configure.

-- 
Russ Allbery (r...@stanford.edu) 

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Mike Frysinger]

On Wednesday 22 August 2012 15:15:07 Jeffrey Walton wrote:
> On Wed, Aug 22, 2012 at 3:06 PM, Mike Frysinger  wrote:
> > On Wednesday 22 August 2012 13:47:30 Jeffrey Walton wrote:
> >> -Wall -Wextra -Wconversion -fPIE -pie -Wno-unused-parameter -Wformat=2
> > 
> > read the log you actually posted.  you aren't using -pie (which would be
> > correct), you're using -Wl,-pie (which is wrong).
> 
> Believe it or not, you need both -fPIE and -pie. The linker consumes
> the -pie switch. The -Wl just passes the switch through the compiler
> drive to the linker.

believe it or not, i understand how PIE works.  i think you missed my point 
that your latest config.log is using wrong flags and it has nothing to do with 
autotools -- you cannot link with -pie only as the compiler driver must see it 
in order to adjust the startup files used.
-mike


signature.asc
Description: This is a digitally signed message part.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Jeffrey Walton]

Hi Mike,

On Wed, Aug 22, 2012 at 3:06 PM, Mike Frysinger  wrote:
> On Wednesday 22 August 2012 13:47:30 Jeffrey Walton wrote:
>> -Wall -Wextra -Wconversion -fPIE -pie -Wno-unused-parameter -Wformat=2
>
> read the log you actually posted.  you aren't using -pie (which would be
> correct), you're using -Wl,-pie (which is wrong).
Believe it or not, you need both -fPIE and -pie. The linker consumes
the -pie switch. The -Wl just passes the switch through the compiler
drive to the linker.

If you omit -pie, `readelf -l xxx.exe | grep -i "Type"` will return
the file type is an EXE (without ASLR); and not DYN (with ASLR).

Jeff

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Jeffrey Walton]

On Wed, Aug 22, 2012 at 3:00 PM, Bob Friesenhahn
 wrote:
> On Wed, 22 Aug 2012, Jeffrey Walton wrote:
>>
>>
>> No wonder GNU programmers don't use any security features
>
>
> GNU programmers don't need to use any security features since they write
> code which does not contain any bugs.
:)

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Mike Frysinger]

On Wednesday 22 August 2012 13:47:30 Jeffrey Walton wrote:
> -Wall -Wextra -Wconversion -fPIE -pie -Wno-unused-parameter -Wformat=2

read the log you actually posted.  you aren't using -pie (which would be 
correct), you're using -Wl,-pie (which is wrong).
-mike


signature.asc
Description: This is a digitally signed message part.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Bob Friesenhahn]

On Wed, 22 Aug 2012, Jeffrey Walton wrote:


No wonder GNU programmers don't use any security features


GNU programmers don't need to use any security features since they 
write code which does not contain any bugs.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Jeffrey Walton]

On Wed, Aug 22, 2012 at 2:17 PM, Russ Allbery  wrote:
> Jeffrey Walton  writes:
>
>> Here are the flags I am interested in. Again, the developers generally
>> don't supply them ("it compiles, so ship it!"). I'm interested in
>> warnings too because I need to see dumb, CompSci 101 mistakes such as
>> ignoring return values, truncation problems, and conversion problems.
>> When I find them, I need to fix them because developers don't care about
>> these things ("it compiles, so ship it!")
>
>> EXECUTABLE:
>> -Wall -Wextra -Wconversion -fPIE -pie -Wno-unused-parameter -Wformat=2
>> -Wformat-security -fstack-protector-all -Wstrict-overflow
>> -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now
>
>> SHARED OBJECT:
>> -Wall -Wextra -Wconversion -fPIC -shared -Wno-unused-parameter
>> -Wformat=2 -Wformat-security -fstack-protector-all -Wstrict-overflow
>> -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now
>
> *If* the package uses libtool, which I realize is a big if, just pass
> -fPIE in CFLAGS and don't worry about the difference.  Libtool is already
> adding -fPIC -shared when building the shared objects, and is smart enough
> to drop -fPIE from the shared objects as pointless.
Thanks Russ. No joy.

Did I mention I tried to do an end around, and add platform hardening
after the fact ("Add compiler and linker hardening after the fact,"
http://sourceware.org/ml/binutils/2012-03/msg00309.html)? No joy
there, either.

No wonder GNU programmers don't use any security features

Jeff

$ ./configure CFLAGS="-Wall -Wextra -Wconversion -fPIE
-Wno-unused-parameter -Wformat=2 -Wformat-security
-fstack-protector-all -Wstrict-overflow -Wl,-pie -Wl,-z,noexecstack
-Wl,-z,relro -Wl,-z,now"
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/jeffrey/Desktop/ucommon-5.5.0':
configure: error: C compiler cannot create executables
See `config.log' for more details

*

configure:2957: checking whether the C compiler works
configure:2979: gcc -Wall -Wextra -Wconversion -fPIE
-Wno-unused-parameter -Wformat=2 -Wformat-security
-fstack-protector-all -Wstrict-overflow -Wl,-pie -Wl,-z,noexecstack
-Wl,-z,relro -Wl,-z,now   conftest.c  >&5
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crt1.o:
relocation R_X86_64_32S against `__libc_csu_fini' can not be used when
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crt1.o:
could not read symbols: Bad value
collect2: ld returned 1 exit status
configure:2983: $? = 1
configure:3021: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3026: error: in `/home/jeffrey/Desktop/ucommon-5.5.0':
configure:3028: error: C compiler cannot create executables
See `config.log' for more details

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Russ Allbery]

Jeffrey Walton  writes:

> Here are the flags I am interested in. Again, the developers generally
> don't supply them ("it compiles, so ship it!"). I'm interested in
> warnings too because I need to see dumb, CompSci 101 mistakes such as
> ignoring return values, truncation problems, and conversion problems.
> When I find them, I need to fix them because developers don't care about
> these things ("it compiles, so ship it!")

> EXECUTABLE:
> -Wall -Wextra -Wconversion -fPIE -pie -Wno-unused-parameter -Wformat=2
> -Wformat-security -fstack-protector-all -Wstrict-overflow
> -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now

> SHARED OBJECT:
> -Wall -Wextra -Wconversion -fPIC -shared -Wno-unused-parameter
> -Wformat=2 -Wformat-security -fstack-protector-all -Wstrict-overflow
> -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now

*If* the package uses libtool, which I realize is a big if, just pass
-fPIE in CFLAGS and don't worry about the difference.  Libtool is already
adding -fPIC -shared when building the shared objects, and is smart enough
to drop -fPIE from the shared objects as pointless.

-- 
Russ Allbery (r...@stanford.edu) 

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Jeffrey Walton]

Hi Suzuki,

Keep in mind I am a library user (so I run configure/make/make
install); not a library developer; and not a Autoconf/Automake/Make
expert.

On Wed, Aug 22, 2012 at 1:17 AM, suzuki toshiya
 wrote:
> Jeffrey Walton wrote:
>> I just wish everyone would get in line so things function as expected
>> from cradle to grave. There's too much "it's not my fault." It reminds
>> me of the old Macs.
>
> It's a pity that you got so many "it's not my fault", but what I can
> say is only "please describe what you want to do in detail, and please
> ask the experts where you can consult for the solution".

Here's the example I am working with: SIP Witch
(https://www.gnu.org/software/sipwitch/). It creates one or more LIBS,
and one or more EXES. You will experience it with any GNU library if
it supplies a test program. In that case, you will likely build (1)
static lib, (2) dynamic lib (shared object), and (3) test harness
(executable).

>From INSTALL: "The simplest way to compile this package is:  1. `cd'
to the directory containing the package's source code and
type`./configure' to configure the package for your system "

Now I know from experience developers don't use secure settings, so I
know I have to supply hardened settings with `configure` via
CFLAGS/CPPFLAGS/LDFLAGS, etc. I want to do it with configure because:
(1) it should be "one stop shopping", and (2) I don't know how to
modify Automake/Autoconf files.

Here are the flags I am interested in. Again, the developers generally
don't supply them ("it compiles, so ship it!"). I'm interested in
warnings too because I need to see dumb, CompSci 101 mistakes such as
ignoring return values, truncation problems, and conversion problems.
When I find them, I need to fix them because developers don't care
about these things ("it compiles, so ship it!")

EXECUTABLE:
-Wall -Wextra -Wconversion -fPIE -pie -Wno-unused-parameter -Wformat=2
-Wformat-security -fstack-protector-all -Wstrict-overflow
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now

SHARED OBJECT:
-Wall -Wextra -Wconversion -fPIC -shared -Wno-unused-parameter
-Wformat=2 -Wformat-security -fstack-protector-all -Wstrict-overflow
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now

The difference between EXE's and SO's is -fPIE -pie (ASLR) and -fPIC
-shared. By definition, shared objects are relocatable (some hand
waiving), so I need to be sure the EXEs are compiled correctly. ASLR
comes into play when the dynamic linker answers the question: "where
is the library relocated when loaded into memory"?

Unfortunately, we cannot differentiate between compilation of an EXE
or SO, so we can't pass different flags (i.e., either  -fPIE -pie or
-fPIC -shared).

>> I think the solution is to update Make so that there are separate
>> LD_EXE_FLAGS and LD_SO_FLAGS. But that was rejected too...
>
> I don't understand what you mean with the word "update Make" (I'm not
> playing dumb, I'm really wondering what you did). And, I wonder who
> told you to use LD_EXE_FLAGS and LD_SO_FLAGS (because they are not
> managed by autotools, I guess).
I asked this question some time ago on GNU Make.

Make only offers LDFLAGS. When software architectures changed (i.e.,
shared objects were introduced), Make did not evolve. Hence the reason
we are pigeon hole'd here. If Make would have evolved with software
architectures, then we would have something like LD_EXE_FLAGS and
LD_SO_FLAGS (and this would not be a problem).

Jeff

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[suzuki toshiya]

Jeffrey Walton wrote:
> I just wish everyone would get in line so things function as expected
> from cradle to grave. There's too much "it's not my fault." It reminds
> me of the old Macs.

It's a pity that you got so many "it's not my fault", but what I can
say is only "please describe what you want to do in detail, and please
ask the experts where you can consult for the solution".

> I think the solution is to update Make so that there are separate
> LD_EXE_FLAGS and LD_SO_FLAGS. But that was rejected too...

I don't understand what you mean with the word "update Make" (I'm not
playing dumb, I'm really wondering what you did). And, I wonder who
told you to use LD_EXE_FLAGS and LD_SO_FLAGS (because they are not
managed by autotools, I guess).

Regards,
mpsuzuki

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Russ Allbery]

Jeffrey Walton  writes:

> I think the solution is to update Make so that there are separate
> LD_EXE_FLAGS and LD_SO_FLAGS. But that was rejected too...

Yeah, I understand both the reason why the idea was rejected and the
reason why it's appealing.

Autoconf isn't the place to look for new flags to pass only to shared
library links (which I think would be the right way to go about that), but
the Automake folks might be interested in talking that over.  I've run
into a few places where I'd like to do that as well (for example,
-Wl,-Bsymbolic).

Currently, the way this works in the Automake world is that the shared
library builds are done via Libtool, which adds the appropriate additional
flags for shared libraries on the local platform.  This generally works
quite well, but so far as I know there isn't a good way to do that
globally across the project.  You can set individual flags for specific
libraries with the _LDFLAGS setting in Automake, but that's for the
developer (since it requires modifying Makefile.am), not for the person
doing the compile.

This would be something that would need to be added to Automake, at least
as I understand it.

In any event, I don't think passing -Wl,-shared into a configure script is
ever going to make sense unless I'm missing some subtlety.  That flag is
specifically for creating shared libraries, and if the package is already
building a shared library, it's (necessarily) already going to add that
flag in exactly the places where it's appropriate.

Note that it is safe to pass -fPIE globally via CFLAGS even if shared
libraries (which must use -fPIC instead of -fPIE) are in play provided
Libtool is in use, since Libtool is smart enough to not pass -fPIE into
shared library builds.

-- 
Russ Allbery (r...@stanford.edu) 

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Jeffrey Walton]

On Wed, Aug 22, 2012 at 12:44 AM, Russ Allbery  wrote:
> Jeffrey Walton  writes:
>
>> According to Pinksi at GCC, -fPIC can be used for both. Both -fPIC and
>> -fPIE produce a relocatable section. I know from experience readelf(1)
>> produces the same result (DYN).
>
>> When using -fPIE, the optimizer can begin optomizing sooner. Andrew
>> Pinski (GCC developer): "With PIE, global variables and functions are
>> considered to bind local while with PIC they are considered to bind
>> globally (aka override able)." [1]
>
>> Pinski specifically recommended -fPIC because of this situation
>> (inability to configure executables and shared objects separately when
>> using the GNU tool chain).
>
> Well, all that's fine and good, but then you passed those flags into GCC
> and they didn't, er, work.  :)  So reality seems to have come into
> conflict with the advice you got.
:)

> I know for certain that the Debian set of hardening flags, which use
> -fPIE, not -fPIC, for executables, work across a *very large* array of
> open source software (although we do have to omit -fPIE from the default
> set since -fPIE breaks some software), and I believe that other
> distributions do the same.  I won't venture to express an opinion on the
> relative merits of -fPIC versus -fPIE, particularly to compiler experts,
> but in my humble opinion you should prefer flags that actually function.
:)

I think the solution is to update Make so that there are separate
LD_EXE_FLAGS and LD_SO_FLAGS. But that was rejected too...

I just wish everyone would get in line so things function as expected
from cradle to grave. There's too much "it's not my fault." It reminds
me of the old Macs.

Jeff

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Russ Allbery]

Jeffrey Walton  writes:

> According to Pinksi at GCC, -fPIC can be used for both. Both -fPIC and
> -fPIE produce a relocatable section. I know from experience readelf(1)
> produces the same result (DYN).

> When using -fPIE, the optimizer can begin optomizing sooner. Andrew
> Pinski (GCC developer): "With PIE, global variables and functions are
> considered to bind local while with PIC they are considered to bind
> globally (aka override able)." [1]

> Pinski specifically recommended -fPIC because of this situation
> (inability to configure executables and shared objects separately when
> using the GNU tool chain).

Well, all that's fine and good, but then you passed those flags into GCC
and they didn't, er, work.  :)  So reality seems to have come into
conflict with the advice you got.

This definitely isn't Autoconf's fault, at least.

I suspect the actual problem may be more the -Wl,-shared than the -fPIC,
since ld -shared specifically means that you are *not* creating an
executable, but rather are creating a shared library:

   -shared
   -Bshareable
   Create a shared library.  This is currently only supported on ELF,
   XCOFF and SunOS platforms.  On SunOS, the linker will automatically
   create a shared library if the -e option is not used and there are
   undefined symbols in the link.

But you're passing it *only* to the linker (via -Wl), not to the compiler,
so the compiler and the linker now disagree on whether the result is going
to be a shared library or an executable, and badness happens.

So, well, don't do that.  :)

I know for certain that the Debian set of hardening flags, which use
-fPIE, not -fPIC, for executables, work across a *very large* array of
open source software (although we do have to omit -fPIE from the default
set since -fPIE breaks some software), and I believe that other
distributions do the same.  I won't venture to express an opinion on the
relative merits of -fPIC versus -fPIE, particularly to compiler experts,
but in my humble opinion you should prefer flags that actually function.

-- 
Russ Allbery (r...@stanford.edu) 

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Jeffrey Walton]

On Wed, Aug 22, 2012 at 12:20 AM, Russ Allbery  wrote:
> Jeffrey Walton  writes:
>
>> I want hardened executables and shared objects. That includes ASLR,
>> which means -fPIE -pie for executables; -fPIC and -shared for shared
>> objects. According to the dialog from the GCC feature request, -fPIC and
>> -shared should be used as it appears to be a "superset" of -fPIE -pie.
>
> -fPIC is only for libraries.  For executables, such as what's created by
> configure, you want -fPIE.  See, for example, the documentation for how to
> deploy hardening flags in Debian (as one of many examples of distributions
> doing this that I just happen to be familiar with personally):
According to Pinksi at GCC, -fPIC can be used for both. Both -fPIC and
-fPIE produce a relocatable section. I know from experience readelf(1)
produces the same result (DYN).

When using -fPIE, the optimizer can begin optomizing sooner. Andrew
Pinski (GCC developer): "With PIE, global variables and functions are
considered to bind local while with PIC they are considered to bind
globally (aka override able)." [1]

Pinski specifically recommended -fPIC because of this situation
(inability to configure executables and shared objects separately when
using the GNU tool chain).

Jeff

[1] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared
as appropriate, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Russ Allbery]

Jeffrey Walton  writes:

> I want hardened executables and shared objects. That includes ASLR,
> which means -fPIE -pie for executables; -fPIC and -shared for shared
> objects. According to the dialog from the GCC feature request, -fPIC and
> -shared should be used as it appears to be a "superset" of -fPIE -pie.

-fPIC is only for libraries.  For executables, such as what's created by
configure, you want -fPIE.  See, for example, the documentation for how to
deploy hardening flags in Debian (as one of many examples of distributions
doing this that I just happen to be familiar with personally):

http://wiki.debian.org/Hardening/

-- 
Russ Allbery (r...@stanford.edu) 

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Mike Frysinger]

On Tuesday 21 August 2012 23:10:28 Jeffrey Walton wrote:
> Hi Suzuki,
> > Anyway, you didn't clarified how such special flags are required,
> > and the coverages of the objects to be compiled with the special
> > flags, so nobody will be able to the answer to be used immediately.
> 
> I was not aware hardeneing was considered "special flags" and we had
> to justify their usage :)

-fPIC is not "hardening flags", -fPIE is.  suzuki is correct that your flag 
selection is wrong.
-mike


signature.asc
Description: This is a digitally signed message part.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[suzuki toshiya]

Jeffrey Walton wrote:
> Hi Suzuki,
> 
>> So I wonder why you want autoconf
>> to "fix" the result caused by your CFLAGS
> I was trying to set CFLAGS, CPPFLAGS, etc though `configure`. Its a
> supported option, and Autoconf produced the configure file. Where else
> would you suggest I look?

In your environment,

gcc "your set of CFLAGS" -o hello.exe hello.c

can generate the executable successfully?

>> Anyway, you didn't clarified how such special flags are required,
>> and the coverages of the objects to be compiled with the special
>> flags, so nobody will be able to the answer to be used immediately.
> I was not aware hardeneing was considered "special flags" and we had
> to justify their usage :) Security conscious folks usually look at it
> the other way: we look at a typical project's configuration, and ask
> why they are not being used. Anyway, the flags have actually been
> around for some time, but most folks don't use them. -1 to those folks
> for ignoring awesome platform security measures.
> 
> Projects use `configure` to configure all binaries output in a project
> - regardless of the binary type (executable or shared object). Though
> there may be multiple executables and shared objects, there is only
> one configure. So I need something that provides what I
> want/desire/require at the single configure point.
> 
> I want hardened executables and shared objects. That includes ASLR,
> which means -fPIE -pie for executables; -fPIC and -shared for shared
> objects. According to the dialog from the GCC feature request, -fPIC
> and -shared should be used as it appears to be a "superset" of -fPIE
> -pie.
> 
> Jeff
> 
> On Tue, Aug 21, 2012 at 9:59 PM, suzuki toshiya
>  wrote:
>> I think your set of CFLAGS makes GCC disabled to make a simple
>> executables like "hello world". So I wonder why you want autoconf
>> to "fix" the result caused by your CFLAGS. For generic CFLAGS,
>> you must set CFLAGS that the compiler can make an executable
>> successfully. You gave CFLAGS that the compiler cannot make
>> an executable.
>>
>> Also I've checked the discussion on GCC bugzilla; Andrew Pinski
>> mentioned automake, but I don't think he recommends a method using
>> "CFLAGS=blahblahblah ./configure". I guess he recommends to write
>> configure.am & Makefile.am to insert non-generic & special flags
>> in the compiling for shared object.
>>
>> Anyway, you didn't clarified how such special flags are required,
>> and the coverages of the objects to be compiled with the special
>> flags, so nobody will be able to the answer to be used immediately.
>>
>> Regards,
>> mpsuzuki
>>
>> Jeffrey Walton wrote:
>>> Hi All,
>>>
>>> Any ideas on how to fix this? I was using -fPIC/-shared due to
>>> limitations in Make and LDFLAGS. According to [1], we can use
>>> -fPIC/-shared all the time.
>>>
>>> $ ./configure CFLAGS="-Wall -Wextra -Wconversion -fPIC
>>> -Wno-unused-parameter -Wformat=2 -Wformat-security
>>> -fstack-protector-all -Wstrict-overflow -Wl,-shared -Wl,-z,noexecstack
>>> -Wl,-z,relro -Wl,-z,now"
>>> checking build system type... x86_64-unknown-linux-gnu
>>> checking host system type... x86_64-unknown-linux-gnu
>>> checking target system type... x86_64-unknown-linux-gnu
>>> checking for gcc... gcc
>>> checking whether the C compiler works... no
>>> configure: error: in `/home/jeffrey/Desktop/sipwitch-1.3.1':
>>> configure: error: C compiler cannot create executables
>>> See `config.log' for more details
>>>
>>> Jeff
>>>
>>> [1] "Request: Add -aslr switch that invokes -fPIE/-pie or
>>> -fPIC/-shared as appropriate,"
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885
>>>
>>> *
>>>
>>> This file contains any messages produced by compilers while
>>> running configure, to aid debugging if configure makes a mistake.
>>>
>>> It was created by configure, which was
>>> generated by GNU Autoconf 2.68.  Invocation command line was
>>>
>>>   $ ./configure CFLAGS=-Wall -Wextra -Wconversion -fPIC
>>> -Wno-unused-parameter -Wformat=2 -Wformat-security
>>> -fstack-protector-all -Wstrict-overflow -Wl,-shared -Wl,-z,noexecstack
>>> -Wl,-z,relro -Wl,-z,now
>>>
>>> ## - ##
>>> ## Platform. ##
>>> ## - ##
>>>
>>> hostname = mint-12-x64
>>> uname -m = x86_64
>>> uname -r = 3.0.0-12-generic
>>> uname -s = Linux
>>> uname -v = #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011
>>>
>>> /usr/bin/uname -p = unknown
>>> /bin/uname -X = unknown
>>>
>>> /bin/arch  = unknown
>>> /usr/bin/arch -k   = unknown
>>> /usr/convex/getsysinfo = unknown
>>> /usr/bin/hostinfo  = unknown
>>> /bin/machine   = unknown
>>> /usr/bin/oslevel   = unknown
>>> /bin/universe  = unknown
>>>
>>> PATH: /usr/lib/lightdm/lightdm
>>> PATH: /usr/local/sbin
>>> PATH: /usr/local/bin
>>> PATH: /usr/sbin
>>> PATH: /usr/bin
>>> PATH: /sbin
>>> PATH: /bin
>>> PATH: /usr/games
>>>
>>>
>>> ## --- ##
>>> ## Core tests. ##
>>> ## --- ##
>>>
>>> configure:2456: checking build system type
>>> configure:2470: 

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[Jeffrey Walton]

Hi Suzuki,

> So I wonder why you want autoconf
> to "fix" the result caused by your CFLAGS
I was trying to set CFLAGS, CPPFLAGS, etc though `configure`. Its a
supported option, and Autoconf produced the configure file. Where else
would you suggest I look?

> Anyway, you didn't clarified how such special flags are required,
> and the coverages of the objects to be compiled with the special
> flags, so nobody will be able to the answer to be used immediately.
I was not aware hardeneing was considered "special flags" and we had
to justify their usage :) Security conscious folks usually look at it
the other way: we look at a typical project's configuration, and ask
why they are not being used. Anyway, the flags have actually been
around for some time, but most folks don't use them. -1 to those folks
for ignoring awesome platform security measures.

Projects use `configure` to configure all binaries output in a project
- regardless of the binary type (executable or shared object). Though
there may be multiple executables and shared objects, there is only
one configure. So I need something that provides what I
want/desire/require at the single configure point.

I want hardened executables and shared objects. That includes ASLR,
which means -fPIE -pie for executables; -fPIC and -shared for shared
objects. According to the dialog from the GCC feature request, -fPIC
and -shared should be used as it appears to be a "superset" of -fPIE
-pie.

Jeff

On Tue, Aug 21, 2012 at 9:59 PM, suzuki toshiya
 wrote:
> I think your set of CFLAGS makes GCC disabled to make a simple
> executables like "hello world". So I wonder why you want autoconf
> to "fix" the result caused by your CFLAGS. For generic CFLAGS,
> you must set CFLAGS that the compiler can make an executable
> successfully. You gave CFLAGS that the compiler cannot make
> an executable.
>
> Also I've checked the discussion on GCC bugzilla; Andrew Pinski
> mentioned automake, but I don't think he recommends a method using
> "CFLAGS=blahblahblah ./configure". I guess he recommends to write
> configure.am & Makefile.am to insert non-generic & special flags
> in the compiling for shared object.
>
> Anyway, you didn't clarified how such special flags are required,
> and the coverages of the objects to be compiled with the special
> flags, so nobody will be able to the answer to be used immediately.
>
> Regards,
> mpsuzuki
>
> Jeffrey Walton wrote:
>> Hi All,
>>
>> Any ideas on how to fix this? I was using -fPIC/-shared due to
>> limitations in Make and LDFLAGS. According to [1], we can use
>> -fPIC/-shared all the time.
>>
>> $ ./configure CFLAGS="-Wall -Wextra -Wconversion -fPIC
>> -Wno-unused-parameter -Wformat=2 -Wformat-security
>> -fstack-protector-all -Wstrict-overflow -Wl,-shared -Wl,-z,noexecstack
>> -Wl,-z,relro -Wl,-z,now"
>> checking build system type... x86_64-unknown-linux-gnu
>> checking host system type... x86_64-unknown-linux-gnu
>> checking target system type... x86_64-unknown-linux-gnu
>> checking for gcc... gcc
>> checking whether the C compiler works... no
>> configure: error: in `/home/jeffrey/Desktop/sipwitch-1.3.1':
>> configure: error: C compiler cannot create executables
>> See `config.log' for more details
>>
>> Jeff
>>
>> [1] "Request: Add -aslr switch that invokes -fPIE/-pie or
>> -fPIC/-shared as appropriate,"
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885
>>
>> *
>>
>> This file contains any messages produced by compilers while
>> running configure, to aid debugging if configure makes a mistake.
>>
>> It was created by configure, which was
>> generated by GNU Autoconf 2.68.  Invocation command line was
>>
>>   $ ./configure CFLAGS=-Wall -Wextra -Wconversion -fPIC
>> -Wno-unused-parameter -Wformat=2 -Wformat-security
>> -fstack-protector-all -Wstrict-overflow -Wl,-shared -Wl,-z,noexecstack
>> -Wl,-z,relro -Wl,-z,now
>>
>> ## - ##
>> ## Platform. ##
>> ## - ##
>>
>> hostname = mint-12-x64
>> uname -m = x86_64
>> uname -r = 3.0.0-12-generic
>> uname -s = Linux
>> uname -v = #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011
>>
>> /usr/bin/uname -p = unknown
>> /bin/uname -X = unknown
>>
>> /bin/arch  = unknown
>> /usr/bin/arch -k   = unknown
>> /usr/convex/getsysinfo = unknown
>> /usr/bin/hostinfo  = unknown
>> /bin/machine   = unknown
>> /usr/bin/oslevel   = unknown
>> /bin/universe  = unknown
>>
>> PATH: /usr/lib/lightdm/lightdm
>> PATH: /usr/local/sbin
>> PATH: /usr/local/bin
>> PATH: /usr/sbin
>> PATH: /usr/bin
>> PATH: /sbin
>> PATH: /bin
>> PATH: /usr/games
>>
>>
>> ## --- ##
>> ## Core tests. ##
>> ## --- ##
>>
>> configure:2456: checking build system type
>> configure:2470: result: x86_64-unknown-linux-gnu
>> configure:2490: checking host system type
>> configure:2503: result: x86_64-unknown-linux-gnu
>> configure:2523: checking target system type
>> configure:2536: result: x86_64-unknown-linux-gnu
>> configure:2611: checking for gcc
>> configure:2627: found /

Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)

[suzuki toshiya]

I think your set of CFLAGS makes GCC disabled to make a simple
executables like "hello world". So I wonder why you want autoconf
to "fix" the result caused by your CFLAGS. For generic CFLAGS,
you must set CFLAGS that the compiler can make an executable
successfully. You gave CFLAGS that the compiler cannot make
an executable.

Also I've checked the discussion on GCC bugzilla; Andrew Pinski
mentioned automake, but I don't think he recommends a method using
"CFLAGS=blahblahblah ./configure". I guess he recommends to write
configure.am & Makefile.am to insert non-generic & special flags
in the compiling for shared object.

Anyway, you didn't clarified how such special flags are required,
and the coverages of the objects to be compiled with the special
flags, so nobody will be able to the answer to be used immediately.

Regards,
mpsuzuki

Jeffrey Walton wrote:
> Hi All,
> 
> Any ideas on how to fix this? I was using -fPIC/-shared due to
> limitations in Make and LDFLAGS. According to [1], we can use
> -fPIC/-shared all the time.
> 
> $ ./configure CFLAGS="-Wall -Wextra -Wconversion -fPIC
> -Wno-unused-parameter -Wformat=2 -Wformat-security
> -fstack-protector-all -Wstrict-overflow -Wl,-shared -Wl,-z,noexecstack
> -Wl,-z,relro -Wl,-z,now"
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... x86_64-unknown-linux-gnu
> checking target system type... x86_64-unknown-linux-gnu
> checking for gcc... gcc
> checking whether the C compiler works... no
> configure: error: in `/home/jeffrey/Desktop/sipwitch-1.3.1':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
> 
> Jeff
> 
> [1] "Request: Add -aslr switch that invokes -fPIE/-pie or
> -fPIC/-shared as appropriate,"
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885
> 
> *
> 
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> 
> It was created by configure, which was
> generated by GNU Autoconf 2.68.  Invocation command line was
> 
>   $ ./configure CFLAGS=-Wall -Wextra -Wconversion -fPIC
> -Wno-unused-parameter -Wformat=2 -Wformat-security
> -fstack-protector-all -Wstrict-overflow -Wl,-shared -Wl,-z,noexecstack
> -Wl,-z,relro -Wl,-z,now
> 
> ## - ##
> ## Platform. ##
> ## - ##
> 
> hostname = mint-12-x64
> uname -m = x86_64
> uname -r = 3.0.0-12-generic
> uname -s = Linux
> uname -v = #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011
> 
> /usr/bin/uname -p = unknown
> /bin/uname -X = unknown
> 
> /bin/arch  = unknown
> /usr/bin/arch -k   = unknown
> /usr/convex/getsysinfo = unknown
> /usr/bin/hostinfo  = unknown
> /bin/machine   = unknown
> /usr/bin/oslevel   = unknown
> /bin/universe  = unknown
> 
> PATH: /usr/lib/lightdm/lightdm
> PATH: /usr/local/sbin
> PATH: /usr/local/bin
> PATH: /usr/sbin
> PATH: /usr/bin
> PATH: /sbin
> PATH: /bin
> PATH: /usr/games
> 
> 
> ## --- ##
> ## Core tests. ##
> ## --- ##
> 
> configure:2456: checking build system type
> configure:2470: result: x86_64-unknown-linux-gnu
> configure:2490: checking host system type
> configure:2503: result: x86_64-unknown-linux-gnu
> configure:2523: checking target system type
> configure:2536: result: x86_64-unknown-linux-gnu
> configure:2611: checking for gcc
> configure:2627: found /usr/bin/gcc
> configure:2638: result: gcc
> configure:2867: checking for C compiler version
> configure:2876: gcc --version >&5
> gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> configure:2887: $? = 0
> configure:2876: gcc -v >&5
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
> 4.6.1-9ubuntu3'
> --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
> --program-suffix=-4.6 --enable-shared --enable-linker-build-id
> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
> --enable-objc-gc --disable-werror --with-arch-32=i686
> --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
> configure:2887: $? = 0
> configure:2876: gcc -V >&5
> gcc: error: unrecognized option '-V'
> gcc: fatal error: no input files
> compilation terminated.
> configure:2887: $? = 4
> configure:2876: gcc -qversion >&5
> gcc: error: unreco