Building gdb from source

Building gdb from source

[Bruce Dubbs]

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.

  -- Bruce Dubbs

Re: Building gdb from source

[Daniel Jacobowitz]

On Thu, Apr 06, 2006 at 08:07:15PM -0500, 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.

Binutils and GDB are maintained in the same CVS repository.  In
general, you should use whichever copy of the shared libraries is
newer, but it's rarely a big deal.  For all these I would just stick
with the copy from binutils.

> 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.

GDB will never use the shared versions anyway; it always uses its own
copies.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Building gdb from source

[Dave Korn]

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.

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

Re: Building gdb from source

[Bruce Dubbs]

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.  :)

  -- Bruce

RE: Building gdb from source

[Dave Korn]

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....

Re: Building gdb from source

[Daniel Jacobowitz]

On Fri, Apr 07, 2006 at 04:08:31PM +0100, Dave Korn wrote:
>   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.

This is not true.  There's no reason to believe that "roughly
contemporary" is good enough.

But it completely fails to matter.  Very little uses these libraries
and most of what does will work with both.  If you install binutils
with shared libraries, then you should use the binutils copy; otherwise
use either.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Building gdb from source

[Dave Korn]

On 07 April 2006 16:19, Daniel Jacobowitz wrote:

> On Fri, Apr 07, 2006 at 04:08:31PM +0100, Dave Korn wrote:
>>   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.
> 
> This is not true.  There's no reason to believe that "roughly
> contemporary" is good enough.

  ?  Is this because releases could be coming from branches that were branched
at very different times?  Would it have been more reasonable if I had said
"releases that are based on roughly-contemporary branches"?



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

Re: Building gdb from source

['Daniel Jacobowitz']

On Fri, Apr 07, 2006 at 04:25:55PM +0100, Dave Korn wrote:
>   ?  Is this because releases could be coming from branches that were branched
> at very different times?  Would it have been more reasonable if I had said
> "releases that are based on roughly-contemporary branches"?

But there are no such releases.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Building gdb from source

[Dave Korn]

On 07 April 2006 16:33, 'Daniel Jacobowitz' wrote:

> On Fri, Apr 07, 2006 at 04:25:55PM +0100, Dave Korn wrote:
>>   ?  Is this because releases could be coming from branches that were
>> branched at very different times?  Would it have been more reasonable if I
>> had said "releases that are based on roughly-contemporary branches"?
> 
> But there are no such releases.


  Ok, I give up, I haven't got the faintest idea what you're talking about.  I
can't even parse that.


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

Re: Building gdb from source

['Daniel Jacobowitz']

On Fri, Apr 07, 2006 at 04:39:42PM +0100, Dave Korn wrote:
> On 07 April 2006 16:33, 'Daniel Jacobowitz' wrote:
> 
> > On Fri, Apr 07, 2006 at 04:25:55PM +0100, Dave Korn wrote:
> >>   ?  Is this because releases could be coming from branches that were
> >> branched at very different times?  Would it have been more reasonable if I
> >> had said "releases that are based on roughly-contemporary branches"?
> > 
> > But there are no such releases.
> 
> 
>   Ok, I give up, I haven't got the faintest idea what you're talking about.  I
> can't even parse that.

Binutils and GDB releases are branched at unpredictably different
times.  How close in time they are doesn't matter if there's been an
interface change in between.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Building gdb from source

[Dave Korn]

On 07 April 2006 16:49, 'Daniel Jacobowitz' wrote:

> On Fri, Apr 07, 2006 at 04:39:42PM +0100, Dave Korn wrote:
>> On 07 April 2006 16:33, 'Daniel Jacobowitz' wrote:
>> 
>>> On Fri, Apr 07, 2006 at 04:25:55PM +0100, Dave Korn wrote:
>>>>   ?  Is this because releases could be coming from branches that were
>>>> branched at very different times?  Would it have been more reasonable if
>>>> I had said "releases that are based on roughly-contemporary branches"?
>>> 
>>> But there are no such releases.
>> 
>> 
>>   Ok, I give up, I haven't got the faintest idea what you're talking
>> about.  I can't even parse that.
> 
> Binutils and GDB releases are branched at unpredictably different
> times.  How close in time they are doesn't matter if there's been an
> interface change in between.

  Ah, ok, we're basically in agreement.  I understand that interface changes
are the one thing that can break compatibility.  I was simply inferring that
if the interval between a binutils branch and a gdb branch is smaller rather
than larger, the odds of someone having made such a change are smaller rather
than greater, even though that change is technically a delta that could take
place in an instant.


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

Re: Building gdb from source

[Bruce Dubbs]

Dave Korn wrote:

>   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!

Actually, the user decides when to add gdb.

>   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.

From my examination of gdb's source, it looks like it is using
binutils-2.16.91 and the latest stable release of binutils is 2.16.1.
Now this probably doesn't make any practical difference, but we really
don't want our users replacing these files without knowing it.

In any case, another editor pointed me to a workaround:

make -C gdb install

that does the right thing for us.  I suppose the discussion from our
point of view now is really moot, but there are some subtle bugs,
harmless for the most part, in the implementation of binutils' bfd and
libiberty build procedures with regard to the -disable-install-libbfd
and --disable-install-libiberty switches.  I've posted the issue on the
binutils mailing list.

  -- Bruce

Re: Building gdb from source

[DJ Delorie]

>   The point is, that a distro should have a consistent set of gcc,
> binutils and gdb.

Since gcc, binutils, and gdb do not coordinate their release cycles,
it's impossible to do so.

As a side note, libiberty was never intended to be *installed* as a
library.  It exists to help port projects within their build tree, and
we DO NOT guarantee any usefulness outside a build tree (although we
try to avoid gratuitously breaking binary compatibility).

I suspect that the installation of libiberty bits has "just happened"
over time, and probably should be disabled by default anyway.

"Program received signal SIG33" error

[yinglcs2]

Hi,

I am trying to debug a problem on gdb
(6.3.0.0-1.122rh)

During initialization,  the application just dies and
here is the error message:

Program received signal SIG33, Real-time event 33.
[Switching to Thread -1274475616 (LWP 22380)]
0x0098c402 in __kernel_vsyscall ()

Can you tell me what is the reason for that?
Thank you.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com