This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with using libtool dependencies in opcodes


"H. J. Lu" <hjl@lucon.org> wrote:

> I don't have any problems with cross compilers. Maybe it is because
> I am using "-L../bfd -lbfd".

 I have... For some time the cross-build cases for Cygwin and MinGW
runtime hosts have failed in configure, a case like:

  --build=i686-linux-gnu --host=i686-mingw32 --target=something

will assume the build/runtime hosts to be Windoze with MSVC, the libtools
in $build/bfd and $build/opcodes to require a patch like:

------------------ clip ---------------------------
*** 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=""

------------------ clip ---------------------------

 The bug seems to be somewhere in those 'ltconf*'-something
scripts in the maindir, I remember fixing it sometimes in my
local sources.

 Another bug is that those generated '$build/libbfd.la' and
'$build/libopcodes.la' don't work in linking and workarounds
like symlinking the '$build/bfd/.libs/libbfd.lib' and
'$build/opcodes/.libs/libopcodes.lib' to '.a' files seen
in bfd and opcodes and editing the binutils, gas and ld
Makefiles to use these instead of the '.la's, must be done.
But this probably was caused by the main bug, not recognizing
any other build/runtime host than Windoze with MSVC, when the
build host is neither Cygwin, nor MinGW...

 Why Windoze+MSVC is the assumed build/runtime host for non-Cygwin,
non-MinGW cases?  For all sanity it should then be some Unix-like
platform (like Linux), with Cygwin/MinGW target crosstools.

Cheers, Kai
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]