[Buildroot] uClibc missing symbols (undefined reference to `__fini_array_end')

[Buildroot] uClibc missing symbols (undefined reference to `__fini_array_end')

[Éric ALBER]

Hi,

I'm using buildroot on an ARM9 (Marvel Kirkwood). I have configured
buildroot to generate gcc on the target. But if I want to use it (gcc on
the target), I get linker errors when I try to link a shared library like
libpython2.7.so
I guess I have something wrong with my uClibc or gcc setup but I can't
figure out what. I use buildroot 2012.02-rc3, uClibc 0.9.32.1, linux 3.2.6

# gcc -shared -lpython2.7 -o test.so test.o
/usr/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.6.2/../../../libc.a(__uClibc_main.os):
In function `__uClibc_fini':
__uClibc_main.c:(.text+0x140): undefined reference to `__fini_array_end'
__uClibc_main.c:(.text+0x144): undefined reference to `__fini_array_start'
__uClibc_main.c:(.text+0x148): undefined reference to `__fini_array_start'
/usr/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.6.2/../../../libc.a(__uClibc_main.os):
In function `__uClibc_main':
__uClibc_main.c:(.text+0x3f8): undefined reference to
`__preinit_array_start'
__uClibc_main.c:(.text+0x3fc): undefined reference to `__preinit_array_end'
__uClibc_main.c:(.text+0x400): undefined reference to `__init_array_start'
__uClibc_main.c:(.text+0x404): undefined reference to `__init_array_end'
/usr/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.6.2/../../../../arm-unknown-linux-uclibcgnueabi/bin/ld:
test.so: hidden symbol `__fini_array_end' isn't defined
/usr/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.6.2/../../../../arm-unknown-linux-uclibcgnueabi/bin/ld:
final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

I have built uClibc as a shared library.
I googled these errors but I didn't find any solution when similar problems
showed up. One person noticed that these symbols exist in libc.a but that
they are defined as HIDDEN

# readelf -s /usr/lib/libc.a | grep _array_
    22: 00000000     0 NOTYPE  GLOBAL HIDDEN  UND __fini_array_end
    23: 00000000     0 NOTYPE  GLOBAL HIDDEN  UND __fini_array_start
    40: 00000000     0 NOTYPE  GLOBAL HIDDEN  UND __preinit_array_start
    41: 00000000     0 NOTYPE  GLOBAL HIDDEN  UND __preinit_array_end
    42: 00000000     0 NOTYPE  GLOBAL HIDDEN  UND __init_array_start
    43: 00000000     0 NOTYPE  GLOBAL HIDDEN  UND __init_array_end

In
http://git.uclibc.org/uClibc/tree/libc/misc/internals/__uClibc_main.c#n291 I
can see that disabling __UCLIBC_CTOR_DTOR__ skips this code path, so I
tried to uncheck "General Library Settings" > "Support global constructors
and destructors" in uClibc configuration but than the compilation on the
host fails: the build process is looking for crt1.o and doesn't find it.

I tried several uClibc and gcc versions and nothing helped. Before each
try, I completely erased buildroot and unpacked it again, I only kept the
buildroot, kernel and uClibc config files. I attach these files to this mail

Did anyone on this list run into the same problems ? Any clue on the cause
or on how to fix this ?

Thanks

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120229/1e1b8d9f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildroot-2012.02-rc3.config
Type: application/octet-stream
Size: 26704 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120229/1e1b8d9f/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-3.2.6.config
Type: application/octet-stream
Size: 60146 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120229/1e1b8d9f/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclibc-0.9.32.1.config
Type: application/octet-stream
Size: 6539 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120229/1e1b8d9f/attachment-0005.obj>

[Buildroot] uClibc missing symbols (undefined reference to `__fini_array_end')

[Arnout Vandecappelle]

On Wednesday 29 February 2012 13:34:38 ?ric ALBER wrote:
> I'm using buildroot on an ARM9 (Marvel Kirkwood). I have configured
> buildroot to generate gcc on the target. But if I want to use it (gcc on
> the target), I get linker errors when I try to link a shared library like
> libpython2.7.so
> I guess I have something wrong with my uClibc or gcc setup but I can't
> figure out what. I use buildroot 2012.02-rc3, uClibc 0.9.32.1, linux 3.2.6
> 
> # gcc -shared -lpython2.7 -o test.so test.o
> /usr/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.6.2/../../../libc.a(__uClibc_main.os):
> In function `__uClibc_fini':
> __uClibc_main.c:(.text+0x140): undefined reference to `__fini_array_end'
> __uClibc_main.c:(.text+0x144): undefined reference to `__fini_array_start'

 These symbols are defined by the linker script, to allow the source code
to find the addresses of the static constructors/destructors.  So it's
not surprising that these symbols are undefined when linking a shared
library, because then you're not using a linker script.

 What _is_ surprising is that it's trying to link against libc.a.  Since
you're building a shared library, I'd expect it to link against libc.so...
So can you run gcc with the -v option to see how the linker is called?
And with -Wl,-M to make the linker print the libraries it loads.

 You do get 
/usr/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.6.2/../../../libc.so
on your target, right?  It's copied in by target-finalize.

 (I'm trying to reproduce your build but it takes a while.  And anyway
I can't run it, unless I set up a qemu for it...)

 Regards,
 Arnout


-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] uClibc missing symbols (undefined reference to `__fini_array_end')

[Arnout Vandecappelle]

On Thursday 01 March 2012 00:27:33 Arnout Vandecappelle wrote:
>  You do get 
> /usr/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.6.2/../../../libc.so
> on your target, right?  It's copied in by target-finalize.

 Actually, it's not...  There's your bug!  Give me a minute to prepare 
a patch.


 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] target-finalize: Also copy .so files if BR2_HAVE_DEVFILES is enabled

[Arnout Vandecappelle]

From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>

If BR2_HAVE_DEVFILES is enabled, target-finalizes copies the static
libraries from STAGING_DIR to TARGET_DIR.  However, there may also
be .so files that are not present on the target (because only the
versioned .so.x file is present).  In particular, this is the case
for libc.so.  So copy these ones as well.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
Note that the whole copy.sh script could use a bit of refactoring.  It
could be called directly from the Makefile with something like:

for FILE_PATH in `find $(addprefix $(STAGING_DIR),lib usr/lib) -name *.a -o -name *.la -o -name *.so`; do
	STAGING_STRIPPED=$${FILE_PATH##$(STAGING_DIR)}
	mkdir -p $(TARGET_DIR)`dirname $${STAGING_STRIPPED}`
	if [ ! -e $(TARGET_DIR)$${STAGING_STRIPPED}]; then
		cp -a $${FILE_PATH} $(TARGET_DIR)$${STAGING_STRIPPED}
	fi
done

But I didn't have time to test that...
---
 support/scripts/copy.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/support/scripts/copy.sh b/support/scripts/copy.sh
index 508ed56..b6636f1 100755
--- a/support/scripts/copy.sh
+++ b/support/scripts/copy.sh
@@ -8,7 +8,7 @@ echo "Copying development files to target..."
 cp -af ${STAGING_DIR}/usr/include ${TARGET_DIR}/usr
 
 for LIBSDIR in /lib /usr/lib; do
-	for WILDCARD in *.a *.la; do
+	for WILDCARD in *.a *.la *.so; do
 		for FILE_PATH in `find ${STAGING_DIR}${LIBSDIR} -name ${WILDCARD}`; do
 			STAGING_STRIPPED=${FILE_PATH##${STAGING_DIR}}
 			EXTENDED_DIR=${STAGING_STRIPPED%/${WILDCARD}}
-- 
1.7.9

[Buildroot] [PATCH] target-finalize: Also copy .so files if BR2_HAVE_DEVFILES is enabled

[Thomas Petazzoni]

Hello Arnout,

Le Thu,  1 Mar 2012 00:50:31 +0000,
"Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be> a ?crit :

> From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
> 
> If BR2_HAVE_DEVFILES is enabled, target-finalizes copies the static
> libraries from STAGING_DIR to TARGET_DIR.  However, there may also
> be .so files that are not present on the target (because only the
> versioned .so.x file is present).  In particular, this is the case
> for libc.so.  So copy these ones as well.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

I was going to ack the patch, but I have a little comment about it.
Some packages seem to always install the .so symlink, some packages seem
to not install the .so symlink (but most seem to do). So maybe instead
of forcefully copying those .so files back to $(O)/target when
BR2_HAVE_DEVFILES is selected, we should settle on what packages should
do with their .so files in order to have a coherent thing.

See this partial output from a random build (which has
BR2_HAVE_DEVFILES *not* set):

lrwxrwxrwx 1 test test      19 Jan  2 13:08 target/usr/lib/libarchive.so -> libarchive.so.2.8.4
lrwxrwxrwx 1 test test      19 Jan  2 13:08 target/usr/lib/libarchive.so.2 -> libarchive.so.2.8.4
-rwxr-xr-x 1 test test  175012 Jan  2 13:17 target/usr/lib/libarchive.so.2.8.4
lrwxrwxrwx 1 test test      23 Jan  2 13:08 target/usr/lib/libart_lgpl_2.so -> libart_lgpl_2.so.2.3.21
lrwxrwxrwx 1 test test      23 Jan  2 13:08 target/usr/lib/libart_lgpl_2.so.2 -> libart_lgpl_2.so.2.3.21
-rwxr-xr-x 1 test test   86316 Jan  2 13:17 target/usr/lib/libart_lgpl_2.so.2.3.21
lrwxrwxrwx 1 test test      22 Jan  2 13:03 target/usr/lib/libcairo.so -> libcairo.so.2.10800.10
lrwxrwxrwx 1 test test      22 Jan  2 13:03 target/usr/lib/libcairo.so.2 -> libcairo.so.2.10800.10
-rwxr-xr-x 1 test test  210204 Jan  2 13:17 target/usr/lib/libcairo.so.2.10800.10
lrwxrwxrwx 1 test test      19 Jan  2 13:08 target/usr/lib/libconfuse.so -> libconfuse.so.0.0.0
lrwxrwxrwx 1 test test      19 Jan  2 13:08 target/usr/lib/libconfuse.so.0 -> libconfuse.so.0.0.0
-rwxr-xr-x 1 test test   34956 Jan  2 13:17 target/usr/lib/libconfuse.so.0.0.0

And this bizarre case:

-rwxr-xr-x 1 test test   76196 Jan  2 13:17 target/usr/lib/libslang.so
lrwxrwxrwx 1 test test      11 Jan  2 13:15 target/usr/lib/libslang.so.1 -> libslang.so

So maybe all packages *should* always install the .so file (be it a
symbolic link or the libc.so linker script), and then:

 * When BR2_HAVE_DEVFILES is not set, we get rid of those .so symbolic
   links

 * When BR2_HAVE_DEVFILES is set, we keep them

That's just a proposal here, other options would be fine with me as
well. It's just that the fact most packages already install the .so
symlink *and* we re-do it in target-finalize when BR2_HAVE_DEVFILES is
set looks confusing.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] uClibc missing symbols (undefined reference to `__fini_array_end')

[Éric ALBER]

Thanks a lot Arnout !
I didn't realize gcc was trying to link with /usr/lib/libc.a instead of
/lib/libc.so.0
I just tried by creating a symlink /usr/lib/libc.so -> /lib/libc.so.0 and
everything work now.

Again, thanks for your help :)

2012/3/1 Arnout Vandecappelle <arnout@mind.be>

> On Thursday 01 March 2012 00:27:33 Arnout Vandecappelle wrote:
> >  You do get
> > /usr/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.6.2/../../../libc.so
> > on your target, right?  It's copied in by target-finalize.
>
>  Actually, it's not...  There's your bug!  Give me a minute to prepare
> a patch.
>
>
>  Regards,
>  Arnout
>
> --
> Arnout Vandecappelle                               arnout at mind be
> Senior Embedded Software Architect                 +32-16-286540
> Essensium/Mind                                     http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR
> Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120301/4786e843/attachment-0001.html>

[Buildroot] [PATCH] target-finalize: Also copy .so files if BR2_HAVE_DEVFILES is enabled

[Arnout Vandecappelle]

On Thursday 01 March 2012 07:48:31 Thomas Petazzoni wrote:
> So maybe all packages should always install the .so file (be it a
> symbolic link or the libc.so linker script), and then:
> 
>  * When BR2_HAVE_DEVFILES is not set, we get rid of those .so symbolic
>    links
> 
>  * When BR2_HAVE_DEVFILES is set, we keep them
> 
> That's just a proposal here, other options would be fine with me as
> well. It's just that the fact most packages already install the .so
> symlink and we re-do it in target-finalize when BR2_HAVE_DEVFILES is
> set looks confusing.

 Removing the .so symlinks seems a bit too much work and too much risk for 
what it is bringing.

 It wouldn't be a bad idea though to only copy over files if they don't 
exist yet.  However, I considered that not to be worth the effort.  Even
if you have 1000 shared libraries installed, overwriting those symlinks
will take you less than a second - in any case much less than the equally
redundant copying of the corresponding .a archives :-)

 In fact, since we're starting to use rsync more and more, we could rely
on its filtering rules to select the .a, .la and .so files for us.

 I would whip up a patch, but I'm too tired now :-)

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F