_dl_app_init_array and _dl_app_fini_array problems

Kevin Day thekevinday at gmail.com
Mon Oct 9 01:52:46 UTC 2006


On 10/7/06, Kevin Day <thekevinday at gmail.com> wrote:
> regardless, gcc 4.1.1 is causing the problem.
> I just switched to gcc 3.4.6.  No other changes to the system and the
> toolchain works properly.
> So gcc-4.1.1 is somehow breaking the ld.
>
> (Given all that has been discussed here, I am wondering how the
> uClibc-0.9.28 host system has the ld linked as dynamic...The host
> system was built using gcc-4.1.1 so perhaps this is yet another form
> of the same problem.)
>
Looks like I screwed up.  There was a tiny line of code that ( a hack
) that i forgot to reset when switching to gcc-3.4.6. Once I fixed
this, I decided to look around uClibc Make system to find the code
where all went wrong.

I did manage to fix this problem with the following patch (from the
most recent svn I have):
--- uClibc-20061006/libc/Makefile.in.orig       2006-10-08
20:42:57.000000000 -0500
+++ uClibc-20061006/libc/Makefile.in    2006-10-08 20:48:10.000000000 -0500
@@ -17,7 +17,7 @@

 LDFLAGS-libc.so := $(LDFLAGS) $(VERSION_SCRIPT) -init __uClibc_init

-LIBS-libc.so := $(interp) $(ldso) $(top_builddir)lib/$(NONSHARED_LIBNAME)
+LIBS-libc.so := $(interp) $(top_srcdir)ldso/ldso/ld-uClibc_so.a
$(top_builddir)lib/$(NONSHARED_LIBNAME)

 # we have SHARED_MAJORNAME=libc.so.$(MAJOR_VERSION) defined in Rules.mak
 libc_FULL_NAME := libuClibc-$(MAJOR_VERSION).$(MINOR_VERSION).$(SUBLEVEL).so



-- 
Kevin Day



More information about the uClibc mailing list