gcc-7 toolchain triggers bug in build system causing non snmp drivers failing to be linked
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
nut (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
It was building a week ago, so likely gcc7 as you expect, taking a look ...
View might first fall on:
al175.c:400:28: warning: ‘%2X’ directive output may be truncated writing between 2 and 4 bytes into a region of size between 3 and 5 [-Wformat-
But that is only a warning due to:
-Wformat-truncation being default on -Wall now [1]
But the actual "break" are errors like:
/usr/bin/ld: al175.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
Actually -fPIC was used on parts of the build pre and post gcc-7 as seen in the buildlogs [2] [3].
The root cause seems in a change that dropped the former:
"-fPIE"
options and replaced them with
-specs=
Since no change was made to nut this likely is from the toolchain upgrade.
This is kind of inverse to what I knew - like [4] where it is about enabling pie.
Did we intentionally drop that - I don't think so?
When analyzing the build it seems there are two times hardning options.
- The first one got the no-pie spec
- And the second lost the -fPIE
--- old 2017-08-16 09:14:46.667114832 +0200
+++ new 2017-08-16 09:14:47.275115931 +0200
@@ -1,15 +1,15 @@
gcc -DHAVE_CONFIG_H -I. -I../include -Wdate-time -D_FORTIFY_SOURCE=2 -I../include -DNETSNMP_
-
+-specs=
-fstack-
--fPIE
--fstack-
-/bin/bash ../libtool --tag=CC --mode=link gcc -I../include -DNETSNMP_
It almost seems to have two hardening entries one behaving one and one the other way.
I've found the source (form nut's POV) of both changes:
1. loosing -fPIE is the actual configure call changing from
CFLAGS="-g -O2 -fdebug-
to
CFLAGS="-g -O2 -fdebug-
This can be checked when comparing zesty with artful calling:
$ DEB_BUILD_
(Lets assume for now it is dropped because it is considered default anyway?)
2. gaining the no-pie spec is from net-snmp by configure
checking for Net-SNMP cflags... [...] -specs=
checking for Net-SNMP libs... [...] -specs=
While in the past this was without pie reference at all.
The options of #2 come later than #1 and so even if #1 would have -fPIE it would be disabled again.
The real source for the change in #2 is actually outside of the nut package.
On its build it wants to build a net-snmp plugin and to do so gets the build options that used.
And a change from zesty [5] to artful [6] is to add the -specs=
The source for that is there since a long time (2013), in d/rules of net-snmp:
# without -pie build fails during perl module build somehow...
export DEB_BUILD_
There is also a "-specs=
And in fact that should be used, so in the linking call replacing no-pie-
Of course that is hidden in auto-generated makefiles, so debug there if a reasonable way to make the (properly detected) net-snmp lib flags appear.
These (correct) flags are used in:
snmp_ups_LDADD = $(LDADD_DRIVERS) $(LIBNETSNMP_LIBS)
[...]
snmp-ups$(EXEEXT): $(snmp_ups_OBJECTS) $(snmp_
@rm -f snmp-ups$(EXEEXT)
But they are missing on the failing object which has:
al175$(EXEEXT): $(al175_OBJECTS) $(al175_
@rm -f al175$(EXEEXT)
The reason is that there is a mis-assumption in the makefile:
# Avoid per-target CFLAGS, because this will prevent re-use of object
# files. In any case, CFLAGS are only -I options, so there is no harm,
# but only add them if we really use the target.
AM_CFLAGS = -I$(top_
In am__append_2 are the cflags which carry "no-pie-
That mismatch causes the breakage as CFLAGS are not "In any case, CFLAGS are only -I options, so there is no harm".
This bug was fixed in the package nut - 2.7.4-5ubuntu4
---------------
nut (2.7.4-5ubuntu4) artful; urgency=medium
* d/p/fix- snmp-driver- compile- options. patch: fix cflags/ldflags .symbols: fix symbols in regard to gcc-7 (LP: #1711091).
mismatch (LP: #1711092).
* d/libnutclient0
-- Christian Ehrhardt <email address hidden> Wed, 16 Aug 2017 12:44:26 +0200