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.amor...@st.com>
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
...
Conflicts:
ldso/ldso/dl-elf.c
ldso/ldso/mips/elfinterp.c
ldso/ldso/x86_64/elfinterp.c
Signed-off-by: Carmelo Amoroso <carmelo.amor...@st.com>
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
7682323a3a798d6f15708f228f859a64cb869aa3
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.
Cheers,
Carmelo
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
