Re: build error while building binutils for i686-pc-cygwin

["Kai Ruottu" <karuottu at mbnet dot fi>]

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