Bug 217000 - devel/elfutils: fails to build with lang/gcc6 or later
Summary: devel/elfutils: fails to build with lang/gcc6 or later
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Conrad Meyer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-11 14:22 UTC by Jan Beich
Modified: 2018-06-21 17:51 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2017-02-11 14:22:49 UTC
readelf.c: In function 'process_elf_file':
readelf.c:1448:47: error: potential null pointer dereference [-Werror=null-dereference]
   Elf_Scn *symscn = elf_getscn (ebl->elf, shdr->sh_link);
                                           ~~~~^~~~~~~~~
readelf.c: In function 'handle_hash':
readelf.c:3338:12: error: potential null pointer dereference [-Werror=null-dereference]
    if (shdr->sh_type == SHT_HASH)
        ~~~~^~~~~~~~~
readelf.c: In function 'handle_hash':
readelf.c:3346:17: error: potential null pointer dereference [-Werror=null-dereference]
    else if (shdr->sh_type == SHT_GNU_HASH)
             ~~~~^~~~~~~~~
readelf.c: In function 'print_debug_exception_table':
readelf.c:7966:7: error: 'landing_pad' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       printf (gettext (" [%4u] Call site start:   %#" PRIx64 "\n"
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          "        Call site length:  %" PRIu64 "\n"
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          "        Landing pad:       %#" PRIx64 "\n"
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          "        Action:            %u\n"),
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        u++, call_site_start, call_site_length, landing_pad, action);
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
readelf.c:7966:7: error: 'call_site_length' may be used uninitialized in this function [-Werror=maybe-uninitialized]
readelf.c:7966:7: error: 'call_site_start' may be used uninitialized in this function [-Werror=maybe-uninitialized]
unstrip.c: In function 'copy_elided_sections':
unstrip.c:1427:19: error: potential null pointer dereference [-Werror=null-dereference]
       sec->outscn = scn;
       ~~~~~~~~~~~~^~~~~

gcc6 build log: http://sprunge.us/GHgD

asm_newsym.c: In function 'asm_newsym':
asm_newsym.c:67:41: error: '%07u' directive output may be truncated writing between 7 and 10 bytes into a region of size 8 [-Werror=format-truncation=]
       snprintf (tempsym, TEMPSYMLEN, ".L%07u", asmscn->ctx->tempsym_count++);
                                         ^~~~
asm_newsym.c:67:38: note: using the range [1, 4294967295] for directive argument
       snprintf (tempsym, TEMPSYMLEN, ".L%07u", asmscn->ctx->tempsym_count++);
                                      ^~~~~~~~
asm_newsym.c:67:7: note: format output between 10 and 13 bytes into a destination of size 10
       snprintf (tempsym, TEMPSYMLEN, ".L%07u", asmscn->ctx->tempsym_count++);
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ar.c: In function 'do_oper_insert':
ar.c:1460:42: error: '%-*ld' directive output may be truncated writing between 16 and 20 bytes into a region of size 17 [-Werror=format-truncation=]
     snprintf (tmpbuf, sizeof (tmpbuf), "/%-*ld",
                                          ^~~~~
ar.c:1460:40: note: using the range [1, -9223372036854775808] for directive argument
     snprintf (tmpbuf, sizeof (tmpbuf), "/%-*ld",
                                        ^~~~~~~~
ar.c:1460:5: note: format output between 18 and 22 bytes into a destination of size 18
     snprintf (tmpbuf, sizeof (tmpbuf), "/%-*ld",
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        (int) sizeof (arhdr.ar_name), all->long_name_off);
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ar.c:1076:56: error: '%-*ld' directive output may be truncated writing between 12 and 20 bytes into a region of size 13 [-Werror=format-truncation=]
   snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
                                                        ^~~~~
ar.c:1076:55: note: using the range [1, -9223372036854775808] for directive argument
   snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
                                                       ^~~~~~~
ar.c:1076:3: note: format output between 13 and 21 bytes into a destination of size 13
   snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ar.c:1076:56: error: '%-*ld' directive output may be truncated writing between 6 and 10 bytes into aregion of size 7 [-Werror=format-truncation=]
   snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
                                                        ^~~~~
ar.c:1076:55: note: directive argument in the range [0, 4294967295]
   snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
                                                       ^~~~~~~
ar.c:1076:3: note: format output between 7 and 11 bytes into a destination of size 7
   snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ar.c:1076:56: error: '%-*ld' directive output may be truncated writing between 6 and 10 bytes into aregion of size 7 [-Werror=format-truncation=]
   snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
                                                        ^~~~~
ar.c:1076:55: note: directive argument in the range [0, 4294967295]
   snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
                                                       ^~~~~~~
ar.c:1076:3: note: format output between 7 and 11 bytes into a destination of size 7
   snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ar.c:1076:56: error: '%-*ld' directive output may be truncated writing between 10 and 20 bytes into a region of size 11 [-Werror=format-truncation=]
   snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
                                                        ^~~~~
ar.c:1076:55: note: using the range [1, -9223372036854775808] for directive argument
   snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
                                                       ^~~~~~~
ar.c:1076:3: note: format output between 11 and 21 bytes into a destination of size 11
   snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Comment 1 Gerald Pfeifer freebsd_committer 2017-02-11 14:38:45 UTC
It appears this port is using -Werror, which generally is not a good
idea for "production" use.  (Great to test and develop software upstream,
but it is going to keep breaking the port again and again.)
Comment 2 Conrad Meyer freebsd_committer 2017-02-11 17:23:23 UTC
If someone will approve this, I can commit it.  I've tested the -Wno-error is added after the -Werror flag:

--- Makefile    (revision 433893)
+++ Makefile    (working copy)
@@ -36,6 +36,9 @@
 CFLAGS+=       -Wno-unused-parameter
 # Give i386 a prayer of building, and we can fix the warnings later:
 CFLAGS_i386+=  -Wno-error
+.if ${CC} == gcc6
+CFLAGS+=       -Wno-error
+.endif

 # Avoid conflict with binutils / elftoolchain programs with the same names:
 CONFIGURE_ARGS+=       --program-prefix=eu-
Comment 3 Jan Beich freebsd_committer 2017-02-11 17:30:45 UTC
(In reply to Conrad Meyer from comment #2)
> +.if ${CC} == gcc6

Nop as USE_GCC alters ${CC} value only after bsd.port.post.mk. Not to mention, DragonFly or architectures en route to external toolchain (sparc64, mips*) may end up with GCC 6.x as /usr/bin/cc.
Comment 4 Gerald Pfeifer freebsd_committer 2017-02-11 17:33:08 UTC
This will then break again with GCC 7 and later, I'm afraid (which will
retain the warnings from what I can tell).
Comment 5 Conrad Meyer freebsd_committer 2017-02-11 17:35:13 UTC
--- Makefile	(revision 433893)
+++ Makefile	(working copy)
@@ -29,7 +29,7 @@

 USES=		gmake libtool tar:bzip2
 USE_AUTOTOOLS=	automake:env
-USE_GCC=	4.8+
+USE_GCC=	4.8
 GNU_CONFIGURE=	yes
 USE_LDCONFIG=	yes
Comment 6 Gerald Pfeifer freebsd_committer 2017-02-11 19:11:32 UTC
If this worked with GCC 4.9 as well, I suggest to make this USE_GCC=4.9
instead of USE_GCC=4.8.

("Later is better", as a general rule of thumb.)
Comment 7 Conrad Meyer freebsd_committer 2017-02-11 19:26:29 UTC
4.9 fails in configure due to what appears to be incomplete LTO support.  GCC 5.0 fails due to what looks like a bad stdio.h header in the port.  4.8 works.
Comment 8 Conrad Meyer freebsd_committer 2017-02-11 19:26:59 UTC
> GCC 5.0 fails due to what looks like a bad stdio.h header in the port.

Fails in configure as well, I should say.
Comment 9 Conrad Meyer freebsd_committer 2017-04-13 22:20:19 UTC
Gerald changed this to drop the 4.8 dependency after my suggestion to hardcode 4.8 for now.  He can figure out how to close out this bug.
Comment 10 commit-hook freebsd_committer 2017-05-01 10:58:26 UTC
A commit references this bug:

Author: gerald
Date: Mon May  1 10:58:18 UTC 2017
New revision: 439866
URL: https://svnweb.freebsd.org/changeset/ports/439866

Log:
  Force the use of GCC 4.8 (strictly), since this port fails with newer
  versions.

  PR:		217000
  Requested by:	cem (maintainer)

Changes:
  head/devel/elfutils/Makefile
Comment 11 Gerald Pfeifer freebsd_committer 2017-05-01 11:02:18 UTC
Okay, so this should now build again on architectures supported by
GCC 4.8.  AArch64 and in generally newer architectures or flavors
won't, so leaving this open and re-assigning to cem as port maintainer.

Also see comment #3 by Jan.

(I believe similar issues should appear on GNU/Linux, so have you
tried reaching out to the upstream developers?)
Comment 12 w.schwarzenfeld freebsd_triage 2018-02-14 18:15:34 UTC
Feedback timeout?
Comment 13 Conrad Meyer freebsd_committer 2018-02-14 18:22:36 UTC
(In reply to w.schwarzenfeld from comment #12)
On what?

Probably the upstream authors see the same issues with new GCC and have munged the code to fix the warnings; a refresh from upstream may resolve the warnings with newer GCC.
Comment 14 w.schwarzenfeld freebsd_triage 2018-02-14 18:36:43 UTC
No, sorry. My statement was wrong. I don't know why this happen. Sorry!
Comment 15 Conrad Meyer freebsd_committer 2018-06-21 17:43:18 UTC
May be addressed by latest elfutils, 0.172.
Comment 16 Conrad Meyer freebsd_committer 2018-06-21 17:51:57 UTC
Ah, right, this was already addressed / removed by 0.170 (r454110).