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); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.)
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-
(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.
This will then break again with GCC 7 and later, I'm afraid (which will retain the warnings from what I can tell).
--- 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
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.)
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.
> 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.
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.
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
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?)
Feedback timeout?
(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.
No, sorry. My statement was wrong. I don't know why this happen. Sorry!
May be addressed by latest elfutils, 0.172.
Ah, right, this was already addressed / removed by 0.170 (r454110).