I'm trying to emerge media-libs/tunepimp-0.4.0 on an ARM uClibc system. It fails because of "undefined reference" problems with libiconv. The first try was even without libiconv installed. tunepimp doesn't have a dependency for this (imho it should need "glibc or libiconv"), and the error I got was (sorry, that's all, forgot to copy the gcc call): ../lib/.libs/libtunepimp.so: undefined reference to `iconvert' Then after talking to yalaforge on freenode #musicbrainz, I installed dev-libs/libiconv-1.10 and tried again. This time the error was: Making all in examples make[2]: Entering directory `/var/tmp/portage/tunepimp-0.4.0/work/libtunepimp-0.4.0/examples' if armeb-softfloat-linux-uclibc-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../lib -I../lib/threads/posix -Wall -O2 -Os -march=armv5te -mtune=xscale -Wall -O2 -MT tagger.o -MD -MP -MF ".deps/tagger.Tpo" -c -o tagger.o tagger.c; \ then mv -f ".deps/tagger.Tpo" ".deps/tagger.Po"; else rm -f ".deps/tagger.Tpo"; exit 1; fi /bin/sh ../libtool --mode=link armeb-softfloat-linux-uclibc-gcc -Os -march=armv5te -mtune=xscale -Wall -O2 -o tp_tagger tagger.o ../lib/libtunepimp.la -lreadline -lncurses mkdir .libs armeb-softfloat-linux-uclibc-gcc -Os -march=armv5te -mtune=xscale -Wall -O2 -o .libs/tp_tagger tagger.o ../lib/.libs/libtunepimp.so -lpthread -L/usr/armeb-softfloat-linux-uclibc/bin -L/usr/armeb-softfloat-linux-uclibc/lib /usr/lib/libmusicbrainz.so /usr/lib/libexpat.so -lz -ldl /usr/lib/gcc/armeb-softfloat-linux-uclibc/3.4.4/libstdc++.so -lreadline -lncurses ../lib/.libs/libtunepimp.so: undefined reference to `libiconv_open' ../lib/.libs/libtunepimp.so: undefined reference to `libiconv_close' ../lib/.libs/libtunepimp.so: undefined reference to `libiconv' collect2: ld returned 1 exit status Note that this time the error message occurs quite a bit later and is a different one. Interesting is that the error occurs in the example "tagger.c" application, although I'm USEing "-examples". Some additional information: emerge -pv tunepimp: [ebuild N ] media-libs/tunepimp-0.4.0 -examples -flac +mp3 -perl +python +readline -vorbis 0 kB emerge info: Portage 2.0.51.22-r2 (uclibc/arm/2.4, gcc-3.4.4, uclibc-0.9.27-r0, 2.6.12.2 armv5teb) ================================================================= System uname: 2.6.12.2 armv5teb XScale-IXP42x Family rev 1 (v5b) Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.16-r1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.4.26-r1 ACCEPT_KEYWORDS="arm ~arm" AUTOCLEAN="yes" CBUILD="armeb-softfloat-linux-uclibc" CFLAGS="-Os -march=armv5te -mtune=xscale" CHOST="armeb-softfloat-linux-uclibc" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-Os -march=armv5te -mtune=xscale" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks nodoc noinfo noman sandbox sfperms strict" GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.informatik.rwth-aachen.de/gentoo-portage/" USE="arm bitmap-fonts bzip2 expat mad mp3 ncurses python readline ssl truetype-fonts type1-fonts uclibc zlib userland_GNU kernel_linux elibc_uclibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY
You have libiconv installed?
As I said: > Then after talking to yalaforge on freenode #musicbrainz, I > installed dev-libs/libiconv-1.10 and tried again. [...] However, some friend pointed out that libiconv seems to be not used at all in the gcc call, therefore I've added -liconv to LD_FLAGS and I'm trying to compile again right now.
(Taking over the bug as it's libiconv-related) Can you give me the config.log of when it failed? I see some strange tests for libiconv, maybe I can try to fix it using one of the GNU's m4 files.
I don't have that config.log anymore, because with LD_FLAGS="-liconv" it worked quite fine, tunepimp was installed. If you still need the log, I'll compile without LD_FLAGS again.
If you can provide me that config.log i can try to fix it, or it would linger there unresolved.
Created attachment 78288 [details] config.log for plain, unedited configure This was generated doing "ebuild .../tunepimp-0.4.0.ebuild unpack; cd ...; ./configure". I've talked to the MusicBrainz guys about that and they see the bug and try to fix it as well.
I need an econf-generated one for safety, tho I'll look into it.
Created attachment 78298 [details, diff] libtunepimp-0.4.0-iconv.patch Not sure if this should be listed here or as a new bug. But seeing as my inbox has been filling up all day with this bug for uClibc + tunepimp I thought I'd give it a try. Merging ~arch was fine (no problems). 4.0 however fails if no libiconv is installed. It's handling the iconvert() function incorrectly. uCtinderbox libtunepimp-0.4.0 # scanelf -qs 'iconvert' . -R iconvert ./lib/utf8/.libs/utf8util.o iconvert ./lib/utf8/utf8util.o iconvert ./lib/.libs/libtunepimp.so.3.0.0 uCtinderbox libtunepimp-0.4.0 # scanelf -Bqs 'iconvert' -R . -F%F#s | xargs nm | grep iconv U iconvert U iconvert U iconvert As expected in config.h we see /* #undef HAVE_ICONV */ /* #undef HAVE_ICONV_H */ Patched attached which solves this. I'm guessing the iconvert problem is why the user is attempting iconv in the first place on a uClibc system.
(In reply to comment #8) > Patched attached which solves this. I'm guessing the iconvert problem is why > the user is attempting iconv in the first place on a uClibc system. patch applied to tunepimp CVS, thx.
Considering this fixed by upstream as 0.4.2 is in portage. Reopen if it's not the case.
