uClibc missing symbols (undefined reference to `__fini_array_end')

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>

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

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

From: "Arnout Vandecappelle (Essensium/Mind)" <[email protected]>

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.

---
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(-)

index 508ed56..b6636f1 100755
@@ -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

Hello Arnout,

Le Thu, 1 Mar 2012 00:50:31 +0000,
"Arnout Vandecappelle (Essensium/Mind)" <[email protected]> a ?crit :

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

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

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 <[email protected]>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120301/4786e843/attachment-0001.html>