current HEAD is broken on old gcc (and warnings on current clang)

Fred Wright fw at fwright.net
Mon Feb 13 21:02:49 UTC 2017


On Mon, 13 Feb 2017, Gary E. Miller wrote:
> On Mon, 13 Feb 2017 01:18:58 -0800
> Hal Murray <hmurray at megapathdsl.net> wrote:
>
> > Debian wheezy
> > gcc (Debian 4.7.2-5) 4.7.2
> >
> > [96/97] Linking deb/main/ntpd/ntpd
> > /usr/bin/ld: libntp/pymodule.c.2.o: relocation R_X86_64_PC32 against
> > symbol `progname' can not be used when making a shared object;
> > recompile with -fPIC /usr/bin/ld: final link failed: Bad value
> > collect2: error: ld returned 1 exit status
>
> Yes, reported yesterday.  I'm working on a solution.
>
> What I need to know is the breakpoint between gccc versions that
> fail and those that work.

If it's going to use questionable compiler options, then it needs to have
something in the configure phase that determines whether said options are
legal.  GPSD already does this, though it looks like ntpsec has yet to
introduce the concept.  Technically, even -Wstrict-prototypes should be
tested before using it, though it apparently hasn't caused trouble yet.

Also some specifics:

The -fPIE/pie options aren't always available, and even when they are,
they may not be compatible with static linking, so they may not be usable
on all parts of the build even when legal (its cousin -fPIC is typically
only used when building shared libraries).  Also note that not all
platforms support ASLR; without it PIE just slows down the code for no
good reason.

The notion that -O1 implies _FORTIFY_SOURCE=2 seems suspect, and here's
something that suggests that that combination is suboptimal:

http://stackoverflow.com/questions/13517526/difference-between-gcc-d-fortify-source-1-and-d-fortify-source-2

In any case, if it were really necessary to use -O1 for some added
compile-time chceks, then it would be better to make that a different
build target, rather than inflicting poorer optimization than the default
on the runtime code.

The proper way to add (properly vetted) linker flags is via LDFLAGS, not
by adding them to CFLAGS with -Wl.  The latter only works when compiling
and linking are done in a single compiler invocation, which isn't always
the case.

I suggest reverting 287a00b9a until a more judicious way to apply the
appropriate options can be worked out.  Note that one can always get the
same effect temporarily for testing just by specifying CFLAGS/LDFLAGS on
the command line.

Fred Wright


More information about the devel mailing list