This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
cathy cobb <cathy_vm2000@yahoo.com> wrote: > Hi, > I get below error when I do the > > make all for target m68k-coff,: > > Kai Routtu: > I followed the suggestion you gav e me by copying the > libbfd.lib into bfd directory with name libbfd.a and > libopcodes.lib in opcodes to a libopcodes.a. > > After doing this I modified the makefiles kin binutils > directory as well as opcodes directory as > appropriately. > > NOw Im get below error: > > make[3]: Entering directory > `/cygdrive/c/downloads/binutils-2.14/binutils-2.14/binutils' > /bin/sh ./libtool --mode=link gcc -W -Wall > -Wstrict-prototypes -Wmissing-prototypes -g -O2 -o objdump.exe > objdump.o budemang.o prdbg.o rddbg.o debug.o stabs.o > ieee.o rdcoff.o bucomm.o version.o filemode.o > ../opcodes/libopcodes.a ../bfd/libbfd.a ../libiberty/libiberty.a > ./../intl/libintl.a > cygpath: can't convert empty path > gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes > -g -O2 -o objdump.exe objdump.o budemang.o prdbg.o rddbg.o > debug.o stabs.o ieee.o rdcoff.o bucomm.o version.o filemode.o > ../opcodes/libopcodes.a ../bfd/libbfd.a ../libiberty/libiberty.a > ./../intl/libintl.a > ../opcodes/libopcodes.a(disassemble.o)(.text+0x1f): In > function `disassembler' > /cygdrive/c/downloads/binutils-2.14/binutils-2.14/opcodes/disassemble.c:86: > undefined reference to `_print_insn_m68k' > collect2: ld returned 1 exit status If we look at the link order here : ../opcodes/libopcodes.a ../bfd/libbfd.a ../libiberty/libiberty.a ./../intl/libintl.a it is still wrong. The libbfd.a should be linked first, then libopcodes.a, libiberty.a and finally libintl.a, if one pass must be enough. My guess is that the undefined symbol `_print_insn_m68k' is in the libopcodes.a. In order to look inside this, you can use your native (Cygwin) 'nm', all these libs are produced for your native host, so : cd $build/opcodes nm libopcodes | grep _print_insn_m68k should tell whether it is there now... The BFD stuff is the main stuff in handling object formats, the opcodes has opcode names for assembler and disassembler etc., libiberty has generic support functions and libintl routines for internationalize... Why the linking must be done via the: /bin/sh ./libtool --mode=link gcc -W -Wall and why on the native Windoze host there comes the warning: cygpath: can't convert empty path is unknown to me. But on Linux when using either a Linux-x-Cygwin or Linux-x-MinGW cross-toolchain to produce the Windoze executables, this same process happens and 'cygpath' will be sought, a 'libbfd.la' will be tried instead of the '$build/bfd/.libs/libbfd.lib' and the '$build/opcodes/.libs/libopcodes.lib'. There making the symlinks: libbfd.a -> .libs/libbfd.lib and libopcodes.a -> .libs/libopcodes.lib and editing the '.la's to be '.a's in the $build/binutils, $build/gas and $build/ld 'Makefile's, has served as my workaround... Futhermore with using the Cygwin and MinGW target crosstools, the bfd and opcodes configures will fail to recognize these hosts, and assume the host being the very 'native' Windoze with MSVC, needing something like : *** libtool.orig Mon Dec 15 20:46:33 2003 --- libtool Mon Dec 15 23:47:08 2003 *************** *** 191,197 **** # Commands used to build and install an old-style archive. RANLIB="/usr/local/i586-cygwin/bin/ranlib" ! old_archive_cmds="lib /OUT:\$oldlib\$oldobjs\$old_deplibs" old_postinstall_cmds="\$RANLIB \$oldlib~chmod 644 \$oldlib" old_postuninstall_cmds="" --- 191,197 ---- # Commands used to build and install an old-style archive. RANLIB="/usr/local/i586-cygwin/bin/ranlib" ! old_archive_cmds="\$AR ruv \$oldlib\$oldobjs\$old_deplibs" old_postinstall_cmds="\$RANLIB \$oldlib~chmod 644 \$oldlib" old_postuninstall_cmds="" to patch the resulted 'libtool's in $build/bfd and $build/opcodes... So my suggestion is to edit the '$build/binutils/Makefile' to have a : ../bfd/libbfd.a ../opcodes/libopcodes.a ../libiberty/libiberty.a ./../intl/libintl.a in its link command for 'objdump.exe' and elsewhere where the order is wrong. Or you can add the 'libopcodes.a' being scanned again using a : ../opcodes/libopcodes.a ../bfd/libbfd.a ../libiberty/libiberty.a ./../intl/libintl.a ../opcodes/libopcodes.a This is quite common and for instance the default link command with GCC has something like '-lgcc -lc -lgcc', ie. the 'libgcc.a' being searched twice, it needing symbols from 'libc.a' and this then needing symbols from 'libgcc.a'. If the link order has not been thoroughly thought out, one may be prepared to do several passes with the libraries. Generally in this case something goes wrong and it would be the Cygwin people's homework to fix it. And the binutils people's homework to get building Cygwin and MinGW hosted stuff on other build hosts working ok. Or one can try to find the fixes and then suggest them into the FSF sources. Basically a Cygwin/MinGW target GCC works quite identically with any other GCCs, so there should be no reason to try to use MSVC's 'lib' and 'cygpath' if the $build_host is not Cygwin or MinGW. Assuming MSVC being the only possible C compiler for producing stuff for Windoze on other build hosts than Cygwin or MinGW, sounds wacky and tells about some lack in imagination. What the 'libtool' does with the native Linux or with any real Unix-like hosts (for instance '--build=i686-linux-gnu --host=sparc-solaris2.7'), seems to work ok, but using it with the Windoze-based hosts has problems now. Cheers, Kai ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |