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

[Gary E. Miller]

Yo Fred!

On Mon, 13 Feb 2017 13:26:31 -0800 (PST)
Fred Wright  wrote:

> On Mon, 13 Feb 2017, Gary E. Miller wrote:
> > On Mon, 13 Feb 2017 13:02:49 -0800 (PST)
> > Fred Wright  wrote:
> >  
> > > I suggest reverting 287a00b9a until a more judicious way to apply
> > > the appropriate options can be worked out.  
> >
> > Sorry, can't do that.  Can only move forward, not back.  
> 
> I contend that any properly conditional means of adding those flags
> will look completely different from 287a00b9a, so the change as it
> stands has no value (not to mention negative value on some
> platforms).  I've already locally reverted it just to get something
> that isn't broken.

Feel free to do what you will in your private branch.  Better yet, just
wait a day.

> > > Note that one can always get
> > > the same effect temporarily for testing just by specifying
> > > CFLAGS/LDFLAGS on the command line.  
> >
> > Except doing that with buildbot is a PITA.  
> 
> Don't the buildbots have a way to specify environment variables?
> Travis certainly does.
> 
> It would also be useful to have the buildbots feed from a testing
> branch, so that the master branch doesn't get used as a testing
> sandbox (e.g., 016eda025/4ca79909a).

I inherited a pretty cranky buildbot structure.  In theory what you
say is true, in practice it is a PTIA.  And a pointless PITA to
customize buildbot for each worker since that is the purpose of waf.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgp_TPKrnJkKx.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

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

[Fred Wright]

On Mon, 13 Feb 2017, Gary E. Miller wrote:
> On Mon, 13 Feb 2017 01:18:58 -0800
> Hal Murray  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
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

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

[Gary E. Miller]

Yo Hal!

On Mon, 13 Feb 2017 01:18:58 -0800
Hal Murray  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.



RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpIC0NP6wJ9I.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel