lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150917162354.GN11551@kernel.org>
Date:	Thu, 17 Sep 2015 13:23:54 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Adrian Hunter <adrian.hunter@...el.com>
Cc:	Vinson Lee <vlee@...pensource.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...hat.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Jiri Olsa <jolsa@...nel.org>,
	"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Wang Nan <wangnan0@...wei.com>,
	Victor Kamensky <victor.kamensky@...aro.org>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-perf-users@...r.kernel.org
Subject: Re: Linux 4.3-rc1 build error with older elfutils "util/symbol-elf.c:41:5: error: no previous prototype for ‘elf_getphdrnum’"

Em Thu, Sep 17, 2015 at 11:37:08AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Sep 17, 2015 at 11:06:19AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Sep 17, 2015 at 09:28:31AM +0300, Adrian Hunter escreveu:
> > > On 17/09/15 01:10, Vinson Lee wrote:
> > > > With Linux 4.3-rc1 I get a perf build error using toolchains with
> > > > older elfutils.
> > > > 
> > > > The following build error occurs on both CentOS 5.11 (elfutils 0.137)
> > > > and Ubuntu 10.04.4 (elfutils 0.143).
> > > > 
> > > >   CC       util/symbol-elf.o
> > > > cc1: warnings being treated as errors
> > > > util/symbol-elf.c:41: error: no previous prototype for ‘elf_getphdrnum’
> > > 
> > > commit f785f2357673d520a0b7b468973cdd197f336494
> > > removed the 'static' qualifier, presumably because there
> > > are cases where the prototype is in the header but the function is
> > > not in the library.
> > > 
> > > AFAICT gcc accepts multiple prototypes so long as they are the same
> > > so just adding the prototype should be ok i.e.
> > 
> > But that looks like a bandaid :-\
> > 
> > The comment I made in f785f2357673d520a0b7b468973cdd197f336494 was not
> > clear enough, now I'm the one trying to figure out why I did that... Duh
> > :-\
> > 
> > I.e. if:
> > 
> > "HAVE_ELF_GETPHDRNUM_SUPPORT is false" we shouldn't have any prototype
> > for that elf_getphdrnum function, i.e. the fact that it is in libelf.h
> > should mean that it is present, how come the feature test for it failed,
> > i.e. HAVE_ELF_GETPHDRNUM_SUPPORT wasn't defined?
> 
> So, on RHEL5.11 (aka, I guess, CentOS 5.11):
> 
>   [acme@...l5 linux]$ cat /etc/redhat-release 
>   Red Hat Enterprise Linux Server release 5.11 (Tikanga)
>   [acme@...l5 linux]$ rpm -q elfutils
>   elfutils-0.137-3.el5
>   [acme@...l5 linux]$ cat /tmp/build/perf/feature/test-libelf-getphdrnum.make.output
>   cc1: warnings being treated as errors
>   test-libelf-getphdrnum.c: In function ‘main’:
>   test-libelf-getphdrnum.c:7: warning: implicit declaration of function ‘elf_getphdrnum’
>   [acme@...l5 linux]$
> 
> If I revert my patch, it builds... I am now building this in more
> systems while trying to get my head around how
> HAVE_ELF_GETPHDRNUM_SUPPORT can be false while elf_getphdrnum() is
> defined.

The only thing I could think was if there are missing libraries to link with the
elf_getphdrnum() test, at:

  tools/build/feature/Makefile

  test-libelf-getphdrnum.bin:
          $(BUILD) -lelf

I.e. on normal builds we end up somehow indirectly getting what we need
and it all builds well, but when some extra lib is needed then the test
will fail, HAVE_ELF_GETPHDRNUM_SUPPORT will not be set even in the
presence of libelf.h with a valid elf_getphdrnum() prototype and the
problems manifests itself...

I'm reverting the patch now, as it was reported as breaking the build
for someone, will revisit this if/when we find out where is that this
breaks :-\

- Arnaldo


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ