This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Debian binutils dependency policy
- From: Daniel Jacobowitz <dan at debian dot org>
- To: Camm Maguire <camm at enhanced dot com>
- Cc: Lionel Elie Mamane <lionel at mamane dot lu>, 328483 at bugs dot debian dot org,binutils at sources dot redhat dot com, debian-devel at lists dot debian dot org,gcl-devel at gnu dot org, binutils at packages dot debian dot org
- Date: Tue, 20 Sep 2005 10:13:37 -0400
- Subject: Re: Debian binutils dependency policy
- References: <20050915154442.GA302@harif.cs.kun.nl> <543bnzx24g.fsf@intech19.enhanced.com>
I have no idea why you've copied this to the binutils upstream list,
debian-devel, et cetera...
On Tue, Sep 20, 2005 at 10:09:03AM -0400, Camm Maguire wrote:
> Greetings!
>
> Do we have a plan or policy regarding packages which need to depend on
> binutils-dev? Is there now or will there ever be in the future a
> stable binary api, by which I mean one that might be good for a year
> or more of development on average? In such a case, would binary api
> compatibility be guaranteed by the soname of the shared library as
> with other libs? Could Debian consider maintaining old and new shared
> lib versions to ease transitions, as with other libraries?
No way.
dpkg -s binutils-dev:
Description: The GNU binary utilities (BFD development files)
This package includes header files and static libraries necessary to build
programs which use the GNU BFD library, which is part of binutils. Note
that building Debian packages which depend on the shared libbfd is Not
Allowed.
The same thing applies to any other form of dependency on the binutils
shared libraries.
> If the answer to the first question is no, then the only sensible
> policy would appear to be that everyone fork and locally maintain
> their own binutils snapshot for static linking. This appears terribly
> inefficient from a system design point of view. On the other hand,
> forcing a rebuild of gcl,maxima,acl2 and axiom on all platforms
> because of a binutils change which might in fact be completely
> innocuous is untenable as well.
Use binutils-dev, link to libbfd.a? The source API changes relatively
rarely, it probably won't bite you.
--
Daniel Jacobowitz
CodeSourcery, LLC