Re: [PATCH 1/2] AC_CONFIG_MACRO_DIR: accept more than one argument
Reference:
http://lists.gnu.org/archive/html/autoconf-patches/2012-07/msg0.html
On 07/04/2012 01:51 PM, Stefano Lattarini wrote:
On 07/04/2012 01:28 PM, Eric Blake wrote:
On 07/04/2012 05:03 AM, Eric Blake wrote:
Would it also make sense to allow multiple calls to AC_CONFIG_MACRO_DIR
to stack, as in:
AC_CONFIG_MACRO_DIR([dir1])
AC_CONFIG_MACRO_DIR([dir2])
And should we mention that the first directory listed has special
significance to other tools like libtool that use the first directory
(and ignore subsequent directories) when first preparing a package with
libtoolize? For that matter, I'd have to investigate whether libtoolize
uses grep or autoconf tracing;
Libtool 2.4.2 (the current release) uses grep tracing; but libtool
commit 2a71b02b has already converted over to m4 tracing. I'm not sure
if the m4 tracing will gracefully handle whitespace-separated
directories or multiple invocations, but the old code:
- /AC_CONFIG_MACRO_DIR(/ {
- s,^.*AC_CONFIG_MACRO_DIR([[ ]*\([^])]*\).*$,ac_macro_dir=\1,
- p
-}
definitely does NOT handle whitespace lists, and with multiple calls,
appears to reassign $ac_macro_dir to the last call rather than the first
(yuck).
Thanks for digging this out (and sorry for duplicating part of it in my
earlier reply).
I think we're stuck for compatibility with providing a new macro for
listing subsidiary directories, and that users that plan to interact
with old libtool must use something like:
AC_CONFIG_MACRO_DIR([dir1])
AC_CONFIG_MACRO_DIRS([dir2 dir3])
AC_CONFIG_MACRO_DIRS([dir4])
where the new macro can stack or take whitespace lists. The new macro
can also auto-call AC_CONFIG_MACRO_DIR() for its first argument for new
libtool that traces rather than using sed, but if you are porting to
older libtool, explicitly spelling out the old name is important.
OK. The new code to support this in aclocal will amount to one line of
code :-) And the 'AC_CONFIG_MACRO_DIRS' name is preferable IMHO, being
more faithful to the intended semantics (several directories supported).
Anyway, to avoid a continuous accretion of backward-compatibility cruft, I
think we should also deprecate AC_CONFIG_MACRO_DIR in the documentation,
stating that it should only be required by older libtools, and add a FIXME
comment to its definition in general.m4 telling that it should be removed
by 2014 or so.
Ping on this?
Regards,
Stefano
Problems Configuring (C Compiler cannot produce executables)
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: unrecognized option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:2887: $? = 4
configure:2907: checking whether the C compiler works
configure:2929: gcc -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 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:2933: $? = 1
configure:2971: 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:2976: error: in `/home/jeffrey/Desktop/sipwitch-1.3.1':
Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)
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: unrecognized option '-qversion' gcc: fatal error: no input files compilation terminated. configure:2887: $? = 4 configure:2907: checking
Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)
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 mpsuz...@hiroshima-u.ac.jp 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 /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)
Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)
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 mpsuz...@hiroshima-u.ac.jp 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 /usr/bin/gcc
Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)
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)
Jeffrey Walton noloa...@gmail.com 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) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)
On Wed, Aug 22, 2012 at 12:20 AM, Russ Allbery r...@stanford.edu wrote: Jeffrey Walton noloa...@gmail.com 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)
Jeffrey Walton noloa...@gmail.com 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) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)
On Wed, Aug 22, 2012 at 12:44 AM, Russ Allbery r...@stanford.edu wrote: Jeffrey Walton noloa...@gmail.com 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)
Jeffrey Walton noloa...@gmail.com 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) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [autoconf] Problems Configuring (C Compiler cannot produce executables)
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
