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....
next prev parent 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