Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3

Carmelo AMOROSO carmelo.amoroso at
Mon Dec 5 12:04:44 UTC 2011

On 01/12/2011 20.40, Khem Raj wrote:
>>> yes I tried the elf_machine_relocations patch and it did not help
>>> I am at 7682323a3a798d6f15708f228f859a64cb869aa3
>>> which is merge commit.
>> so if you do reset --hard HEAD~1 you have something working again ?
> yes

Hi guys,
starting from SHA1 7682323a3a798d6f15708f228f859a64cb869aa3, and
resetting back to HEAD~1, we ends in SHA1

commit 3004ce0c9619f89bf8e64931edd696bf4df8d2e1
Merge: 3b3285b 4916fd8
Author: Carmelo Amoroso <carmelo.amoroso at>
Date:   Wed May 4 08:31:16 2011 +0200

    Merge remote-tracking branch 'origin/master' into prelink

    * origin/master: (32 commits)
      libubacktrace: fix backtrace support on arm-eabi, which needs
libgcc_eh linked too
      getaddrinfo.c: fix incorrect check for ERANGE from gethostbyaddr_r
      getaddrinfo.c: improve code readability. No functional changes
      string: remove unused variable
      x86_64: silence warning if !TLS
      buildsys: prettify ssp.c handling
      madvise is LINUX_SPECIFIC
      test_nptl: fix expected result for tst-cputimer[123]
      test_nptl: fix expected result for tst-clock2 test
      buildsys: make $(LOCAL_INSTALL_PATH) phony
      ether_aton: reject invalid input
      tests: disable ether tests if !HAS_SOCKET
      inet: add ether_aton testcase
      sysconf: clock_getres depends on HAS_REALTIME
      __rt_sigwaitinfo: depends on HAS_REALTIME
      buildsys: minor fixes in Makefile.arch for C6X
      buildsys: minor fixes in Makefile.arch for microblaze
      libubacktrace: enabled for all archs indeed.
      sparc: don't access fp registers when configured for no fpu
      libubacktrace: generic implementation based dwarf


    Signed-off-by: Carmelo Amoroso <carmelo.amoroso at>

That already includes both STANDALONE, PRELINK and symbol lookup re-design.

Filippo and my self have thoroughly looked again at
prelink/stand-alone/global scope work included from the prelink branch,
and we can't see any issue (except for the fdpic archs under discussion
with Mike).

My suspect is in the merge process itself (badly handled conflicts), or
in the commits (in master) between
3004ce0c9619f89bf8e64931edd696bf4df8d2e1 and

So I'll look again at all merge commits I've done focusing on conflicts.

I'd kindly ask Khem to confirm if he is seeing or not problem with
master @3004ce0c9.


More information about the uClibc mailing list