public inbox for gas2@sourceware.org
 help / color / mirror / Atom feed
From: Ken Raeburn <raeburn@cygnus.com>
To: hjl@nynexst.com (H.J. Lu)
Cc: gas2@cygnus.com, bfd@cygnus.com
Subject: Re: procfs patches for Linux
Date: Tue, 25 Apr 1995 09:52:00 -0000	[thread overview]
Message-ID: <9504251652.AA05837@cujo.cygnus.com> (raw)
In-Reply-To: <9504251425.AA21877@titanic.nynexst.com>

   > Because of the way BFD is set up, core file support is compiled in even
   > for cross configurations.  (This is a bug, and I'll happily take patches
   > to fix it.)  So the Linux core file support has to compile, because

   Will you? Please take a look at below.

   > people may be using Linux as a development system for a cross-assembler.


   That was what I faced more than 2 years ago while bootstrapping
   gcc for Linux in a cross-compile environment. One solution is:

   # cd bfd
   # mdkir targets
   # cd targets

   We move all the target stuff from bfd/hosts to bfd/targets. In
   bfd/configure, we do:

   2. if [ -f $srcdir/targets/target.h ]; then
	   link $srcdir/targets/target.h to tsysdep.h.
	   link $srcdir/hosts/host.h to hsysdep.h.
	   echo include "hsysdep.h" > sysdep.h
	   echo include "tsysdep.h" >> sysdep.h
      else
	   link $srcdir/hosts/host.h to sysdep.h.
      fi

The core file support is often dependent on system header files that
we don't duplicate in the binutils distribution.  Trying to include
sunos header files when building a sunos cross-assembler hosted on
linux won't work because you don't have the sunos header files.  And
you shouldn't have to copy them all over from one system to the other
just to build binutils.

In a cross configuration, it generally shouldn't be built.  There may
be cases where we do have enough information to do it, I don't know.
But I don't think that's going to be the common case.  (Currently I
don't think cross-debuggers are expected to handle core files, so it'd
be no real loss to omit the core file support altogether in cross
configurations.)

   > I'm disabling HAVE_PROCFS for Linux in BFD for now, until you can give
   > me something that supports both system environments, with sys/procfs.h
   > and without.

   I will fix it on the linux side.

Thanks.

   BTW, do you need a patch for elf32.em to fix the -Lxxxx bug?

Maybe.  I want to check it against the behavior on Solaris or some
other non-GNU ELF system.


  reply	other threads:[~1995-04-25  9:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9504250459.AA05647@cujo.cygnus.com>
1995-04-25  7:27 ` H.J. Lu
1995-04-25  9:52   ` Ken Raeburn [this message]
1995-04-25 10:51     ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9504251652.AA05837@cujo.cygnus.com \
    --to=raeburn@cygnus.com \
    --cc=bfd@cygnus.com \
    --cc=gas2@cygnus.com \
    --cc=hjl@nynexst.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).