Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Dave Korn" <dave.korn@artimi.com>
To: "'Bruce Dubbs'" <bdubbs@linuxfromscratch.org>, 	<gdb@sourceware.org>
Subject: RE: Building gdb from source
Date: Fri, 07 Apr 2006 15:26:00 -0000	[thread overview]
Message-ID: <000801c65a55$21ffa580$a501a8c0@CAM.ARTIMI.COM> (raw)
In-Reply-To: <44367EE8.4090305@linuxfromscratch.org>

On 07 April 2006 16:02, Bruce Dubbs wrote:

> Dave Korn wrote:
>> On 07 April 2006 02:07, Bruce Dubbs wrote:
>> 
>>> I like to build packages from source.  When I build gdb-6.4:
>>> 
>>> ./configure  --prefix=/usr
>>> make
>>> make install
>>> 
>>> gdb's Makefile places the following files in /usr/lib:
>>> 
>>> libbfd.a  libbfd.la  libiberty.a  libopcodes.a  libopcodes.la
>>> 
>>> The problem is that these files already exist from binutils-2.16.1.
>>> 
>>> Is there any reason to prefer the libraries from binutils over gdb or
>>> vice versa?  I believe this could be a problem as the binutils libraries
>>> include dynamic libraries that could be out of sync with the gdb static
>>> libraries and that the gdb .la files do not recognize the dynamic
>>> libraries at all.
>> 
>>   Well, you shouldn't be configuring with --prefix=/usr unless you are
>> prepared to overwrite your basic O/S installation in any case.
> 
> I see you are not familiar with LinuxFromScratch.  :)

  Well, if you're replacing your binutils at the same time, what's the
problem?  The old libs are about to be overwritten in any case!

  The point is, that a distro should have a consistent set of gcc, binutils
and gdb.  Since binutils and gdb live in the same repository, if you either
take a consistent snapshot of the cvs, or if you take gdb and binutils
releases that are roughly-contemporary, they're bound to be 'in-sync' FAPP.

  So if you're building gdb to replace (or even to /be/) your system gdb, you
should already have chosen one that's compatible with your binutils version,
or you should be about to replace your binutils to match.  Either way,
overwriting the old libs won't matter.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


  reply	other threads:[~2006-04-07 15:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-07  1:16 Bruce Dubbs
2006-04-07  6:39 ` Daniel Jacobowitz
2006-04-07 15:02 ` Dave Korn
2006-04-07 15:19   ` Bruce Dubbs
2006-04-07 15:26     ` Dave Korn [this message]
2006-04-07 15:32       ` Daniel Jacobowitz
2006-04-07 15:39         ` Dave Korn
2006-04-07 15:40           ` 'Daniel Jacobowitz'
2006-04-07 15:49             ` Dave Korn
2006-04-07 15:58               ` 'Daniel Jacobowitz'
2006-04-07 16:27                 ` Dave Korn
2006-04-07 15:54       ` Bruce Dubbs
2006-04-07 20:01       ` DJ Delorie
2006-04-14  6:10     ` "Program received signal SIG33" error yinglcs2

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='000801c65a55$21ffa580$a501a8c0@CAM.ARTIMI.COM' \
    --to=dave.korn@artimi.com \
    --cc=bdubbs@linuxfromscratch.org \
    --cc=gdb@sourceware.org \
    /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