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
<address@hidden> 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