I'm currently trying to build a cross-compiler toolchain for mipsel based on the packages in FC4, and I'm getting the following message when running configure for gcc:
/usr/mipsel-linux/bin/as: symbol lookup error: /usr/mipsel-linux/bin/as: undefined symbol: bfd_mips16_num_opcodes
The binutils package I'm using is located here:
http://fedora.ivazquez.net/files/extras/binutils-mipsel.spec http://fedora.ivazquez.net/files/extras/binutils-mipsel-2.15.94.0.2.2-1.src....
My current gcc-mipsel-minimal specfile, rpmbuild log, and obj-mipsel-linux/gcc/config.log are located here:
http://fedora.ivazquez.net/files/current/
Does anyone have any idea what is going on, or where I should go for further assistance?
On Tue, 2005-07-05 at 01:28 -0400, Ignacio Vazquez-Abrams wrote:
I'm currently trying to build a cross-compiler toolchain for mipsel based on the packages in FC4, and I'm getting the following message when running configure for gcc:
/usr/mipsel-linux/bin/as: symbol lookup error: /usr/mipsel-linux/bin/as: undefined symbol: bfd_mips16_num_opcodes
Wild guess (Without having tried to build your packages):
Your binutils seem to be dynamically linked against libbfd. At runtime you therefore get the libbfd as being shipped by FC, not the version having been built as part of your toolchain built.
I would assume statically linking your binutils against the libbfd having been build during building your toolchain (--disable-shared) will fix this issue.
Another possibility would be to install your toolchain's libbfd outside of /usr/lib into a target dependent directory and to apply rpath during linkage.
Finally you could consider to use a different prefix (!= /usr).
The binutils package I'm using is located here:
http://fedora.ivazquez.net/files/extras/binutils-mipsel.spec http://fedora.ivazquez.net/files/extras/binutils-mipsel-2.15.94.0.2.2-1.src....
My current gcc-mipsel-minimal specfile, rpmbuild log, and obj-mipsel-linux/gcc/config.log are located here:
http://fedora.ivazquez.net/files/current/
Does anyone have any idea what is going on, or where I should go for further assistance?
The GCC list, the binutils list, the crossgcc list probably are appropriate.
Also, I'd assume there are enough toolchain developers on this list and on Extras.
Ralf
On Tue, 2005-07-05 at 08:46 +0200, Ralf Corsepius wrote:
On Tue, 2005-07-05 at 01:28 -0400, Ignacio Vazquez-Abrams wrote:
I'm currently trying to build a cross-compiler toolchain for mipsel based on the packages in FC4, and I'm getting the following message when running configure for gcc:
/usr/mipsel-linux/bin/as: symbol lookup error: /usr/mipsel-linux/bin/as: undefined symbol: bfd_mips16_num_opcodes
Wild guess (Without having tried to build your packages):
Your binutils seem to be dynamically linked against libbfd. At runtime you therefore get the libbfd as being shipped by FC, not the version having been built as part of your toolchain built.
Yep, that was it, thanks.
ivazquez@ivazquez.net (Ignacio Vazquez-Abrams) writes:
I'm currently trying to build a cross-compiler toolchain for mipsel based on the packages in FC4, and I'm getting the following message when running configure for gcc:
Have you looked at crosstool? The tarball has probably patches for your architecture/version.
Okay, new problem.
stage1/xgcc -Bstage1/ -B/usr/mipsel-linux-elf/bin/ -O2 -g -pipe -fexceptions -fasynchronous-unwind-tables -I/usr/include/mipsel-linux-elf -I/usr/include -L/usr/lib/mipsel-linux-elf -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genmodes \ build/genmodes.o build/errors.o ../build-i686-pc-linux-gnu/libiberty/libiberty.a /usr/mipsel-linux-elf/bin/ld: ../build-i686-pc-linux-gnu/libiberty/libiberty.a(hashtab.o): Relocations in generic ELF (EM: 3) ../build-i686-pc-linux-gnu/libiberty/libiberty.a: could not read symbols: File in wrong format collect2: ld returned 1 exit status
Once again the spec and log are in:
http://fedora.ivazquez.net/files/current/
How do I point it to /usr/lib/mipsel-linux-elf/libiberty.a instead, if that's what's needed?
On Tue, 2005-07-05 at 15:04 -0400, Ignacio Vazquez-Abrams wrote:
Okay, new problem.
Never mind. Got it thanks to pinskia in #gcc.
SO close...
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stkfvvzH/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stknjimJ/_gcov.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/st1IbzLJ/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/stCS0KgK/_gcov.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stykxIiN/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stlyWRIN/_gcov.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stcW3fTL/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stlQTjfM/_gcov.o: Invalid operation error: Bad exit status from /var/tmp/rpm-tmp.36667 (%install)
http://fedora.ivazquez.net/files/current/
How can I tell rpmbuild to not strip those files, or to point it to the proper strip?
On Tue, 2005-07-05 at 19:23 -0400, Ignacio Vazquez-Abrams wrote:
SO close...
- /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
/usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stkfvvzH/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stknjimJ/_gcov.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/st1IbzLJ/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/stCS0KgK/_gcov.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stykxIiN/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stlyWRIN/_gcov.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stcW3fTL/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stlQTjfM/_gcov.o: Invalid operation error: Bad exit status from /var/tmp/rpm-tmp.36667 (%install)
http://fedora.ivazquez.net/files/current/
How can I tell rpmbuild to not strip those files, or to point it to the proper strip?
By redefining __os_install_post (cf. rpm --showrc) and/or by providing your own brp-strip-static-archive (AFAICT, the "strip" is hard-coded into /usr/lib/rpm/brp-strip-static-archive).
The brute-force way would be to disable __os_install_post: %define __os_install_post %{nil}
Ralf
On Wed, 2005-07-06 at 01:54 +0200, Ralf Corsepius wrote:
On Tue, 2005-07-05 at 19:23 -0400, Ignacio Vazquez-Abrams wrote:
SO close...
- /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
/usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stkfvvzH/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stknjimJ/_gcov.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/st1IbzLJ/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/stCS0KgK/_gcov.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stykxIiN/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stlyWRIN/_gcov.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stcW3fTL/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stlQTjfM/_gcov.o: Invalid operation error: Bad exit status from /var/tmp/rpm-tmp.36667 (%install)
http://fedora.ivazquez.net/files/current/
How can I tell rpmbuild to not strip those files, or to point it to the proper strip?
By redefining __os_install_post (cf. rpm --showrc) and/or by providing your own brp-strip-static-archive (AFAICT, the "strip" is hard-coded into /usr/lib/rpm/brp-strip-static-archive).
I managed to figure it out thanks to some nudging in the right direction from jbj.
FTR, you can define %__strip to change what you use to strip.
On Tue, 2005-07-05 at 20:38 -0400, Ignacio Vazquez-Abrams wrote:
On Wed, 2005-07-06 at 01:54 +0200, Ralf Corsepius wrote:
On Tue, 2005-07-05 at 19:23 -0400, Ignacio Vazquez-Abrams wrote:
SO close...
- /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
/usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stkfvvzH/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/stknjimJ/_gcov.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/st1IbzLJ/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/soft-float/eb/stCS0KgK/_gcov.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stykxIiN/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/stlyWRIN/_gcov.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stcW3fTL/_m16addsf3.o: Invalid operation /usr/bin/strip: /var/tmp/gcc-root/usr/lib/gcc/mipsel-linux-elf/4.0.0/eb/stlQTjfM/_gcov.o: Invalid operation error: Bad exit status from /var/tmp/rpm-tmp.36667 (%install)
http://fedora.ivazquez.net/files/current/
How can I tell rpmbuild to not strip those files, or to point it to the proper strip?
By redefining __os_install_post (cf. rpm --showrc) and/or by providing your own brp-strip-static-archive (AFAICT, the "strip" is hard-coded into /usr/lib/rpm/brp-strip-static-archive).
I managed to figure it out thanks to some nudging in the right direction from jbj.
FTR, you can define %__strip to change what you use to strip.
/usr/lib/rpm/brp-strip-static-archive has "strip" hard-coded into it:
sed -n -e 's/^\(.*\):[ ]*current ar archive/\1/p'`; do strip -g $fdone
Ralf
On Wed, 2005-07-06 at 02:57 +0200, Ralf Corsepius wrote:
On Tue, 2005-07-05 at 20:38 -0400, Ignacio Vazquez-Abrams wrote:
FTR, you can define %__strip to change what you use to strip.
/usr/lib/rpm/brp-strip-static-archive has "strip" hard-coded into it:
sed -n -e 's/^\(.*\):[ ]*current ar archive/\1/p'`; do strip -g $fdone
/usr/lib/rpm/redhat/brp-strip-static-archive takes the command as the first argument:
[ -z "$STRIP" -a -n "$1" ] && STRIP="$1" [ -z "$STRIP" ] && STRIP=strip
...
$STRIP -g $f
And in /usr/lib/rpm/redhat/macros:
%__os_install_post \ /usr/lib/rpm/redhat/brp-compress \ /usr/lib/rpm/redhat/brp-strip %{__strip} \ /usr/lib/rpm/redhat/brp-strip-static-archive %{__strip} \ /usr/lib/rpm/redhat/brp-strip-comment-note %{__strip} %{__objdump} \ %{nil}
Okay, *almost* there.
Which of these files are important?
/usr/bin/stVv16b0 /usr/bin/stdTtJd1 /usr/bin/stnIJwI1 /usr/bin/stxfFoJZ /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/gsyslimits.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/README /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/float.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/iso646.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/limits.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/stdarg.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/stdbool.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/stddef.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/unwind.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/varargs.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/macro_list /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/mkheaders.conf /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/fix-header /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/fixinc.sh /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/fixproto /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/stXW4r1X /usr/libexec/gcc/mipsel-linux-elf/4.0.0/stb6V9S0 /usr/libexec/gcc/mipsel-linux-elf/4.0.0/stzwRUzZ /usr/libexec/getconf/default
http://fedora.ivazquez.net/files/current/
On Tue, 2005-07-05 at 23:02 -0400, Ignacio Vazquez-Abrams wrote:
Okay, *almost* there.
Which of these files are important?
These are a side effect of a bug somewhere [1]:
/usr/bin/stVv16b0 /usr/bin/stdTtJd1 /usr/bin/stnIJwI1 /usr/bin/stxfFoJZ
These are not of any importance on linux targets:
/usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/gsyslimits.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/README /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/float.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/iso646.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/limits.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/stdarg.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/stdbool.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/stddef.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/unwind.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/include/varargs.h /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/macro_list /usr/lib/gcc/mipsel-linux-elf/4.0.0/install-tools/mkheaders.conf /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/fix-header /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/fixinc.sh /usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/fixproto
More side-effects of the before mentioned bug
/usr/libexec/gcc/mipsel-linux-elf/4.0.0/install-tools/stXW4r1X /usr/libexec/gcc/mipsel-linux-elf/4.0.0/stb6V9S0 /usr/libexec/gcc/mipsel-linux-elf/4.0.0/stzwRUzZ
Don't know about this one:
/usr/libexec/getconf/default
BTW:
1. This line from your spec is meaningless for mipsel targets (and bogus for i386 targets): cp -a libstdc++-v3/config/cpu/i{4,3}86/atomicity.h
2. You'll also probably want to add --enable-version-specific-runtime-libs to the args being passed to configure.
Ralf
[1] I don't know about the cause, but I am occasionally seeing them with my toolchains too.
On Wed, 2005-07-06 at 09:24 +0200, Ralf Corsepius wrote:
On Tue, 2005-07-05 at 23:02 -0400, Ignacio Vazquez-Abrams wrote: These are a side effect of a bug somewhere [1]:
/usr/bin/stVv16b0 /usr/bin/stdTtJd1 /usr/bin/stnIJwI1 /usr/bin/stxfFoJZ
It looks like a bug in strip whereby it doesn't remove the temporary file if it doesn't recognize the file format.
On Wed, 2005-07-06 at 07:24 -0400, Ignacio Vazquez-Abrams wrote:
On Wed, 2005-07-06 at 09:24 +0200, Ralf Corsepius wrote:
On Tue, 2005-07-05 at 23:02 -0400, Ignacio Vazquez-Abrams wrote: These are a side effect of a bug somewhere [1]:
/usr/bin/stVv16b0 /usr/bin/stdTtJd1 /usr/bin/stnIJwI1 /usr/bin/stxfFoJZ
It looks like a bug in strip whereby it doesn't remove the temporary file if it doesn't recognize the file format.
Sounds plausible to me. If this holds, the origin of these files probably is brp-strip-*, because it blindly runs strip rsp. "<target>-strip" on all binaries and doesn't distinguish between foreign and native binaries.
A straight forward work-around would be to hard-code the directories containing native/foreign binaries into brp-*.
Ralf
On Wed, 2005-07-06 at 14:12 +0200, Ralf Corsepius wrote:
On Wed, 2005-07-06 at 07:24 -0400, Ignacio Vazquez-Abrams wrote:
On Wed, 2005-07-06 at 09:24 +0200, Ralf Corsepius wrote:
On Tue, 2005-07-05 at 23:02 -0400, Ignacio Vazquez-Abrams wrote: These are a side effect of a bug somewhere [1]:
/usr/bin/stVv16b0 /usr/bin/stdTtJd1 /usr/bin/stnIJwI1 /usr/bin/stxfFoJZ
It looks like a bug in strip whereby it doesn't remove the temporary file if it doesn't recognize the file format.
Sounds plausible to me. If this holds, the origin of these files probably is brp-strip-*, because it blindly runs strip rsp. "<target>-strip" on all binaries and doesn't distinguish between foreign and native binaries.
A straight forward work-around would be to hard-code the directories containing native/foreign binaries into brp-*.
Or to patch binutils to not leave its junk lying around.
On Wed, 2005-07-06 at 08:49 -0400, Ignacio Vazquez-Abrams wrote:
On Wed, 2005-07-06 at 14:12 +0200, Ralf Corsepius wrote:
On Wed, 2005-07-06 at 07:24 -0400, Ignacio Vazquez-Abrams wrote:
On Wed, 2005-07-06 at 09:24 +0200, Ralf Corsepius wrote:
On Tue, 2005-07-05 at 23:02 -0400, Ignacio Vazquez-Abrams wrote: These are a side effect of a bug somewhere [1]:
/usr/bin/stVv16b0 /usr/bin/stdTtJd1 /usr/bin/stnIJwI1 /usr/bin/stxfFoJZ
It looks like a bug in strip whereby it doesn't remove the temporary file if it doesn't recognize the file format.
Sounds plausible to me. If this holds, the origin of these files probably is brp-strip-*, because it blindly runs strip rsp. "<target>-strip" on all binaries and doesn't distinguish between foreign and native binaries.
A straight forward work-around would be to hard-code the directories containing native/foreign binaries into brp-*.
Or to patch binutils to not leave its junk lying around.
s/Or/And/
These actually are 2 independent issues. brp-*'s deficiencies trigger a bug in binutils.
Ralf
-
Ignacio Vazquez-Abrams -
Mathieu Chouquet-Stringer -
Ralf Corsepius