Re: Debian binutils dependency policy
Greetings, and thanks so much for your helpful reply!
Daniel Jacobowitz <firstname.lastname@example.org> writes:
> I have no idea why you've copied this to the binutils upstream list,
> debian-devel, et cetera...
Well, upstream for some idea of their release and versioning number
plans, debian-devel as this issue appears commensurate with libc and
gcc version change transition planning, etc.
> 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
> The same thing applies to any other form of dependency on the binutils
> shared libraries.
OK, but this is a pity. I still don't understand why this need be the
> > 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.
I agree that the source API is stable, but this strategy has has
bitten me at least once. GCL builds an internal bfd symbol table of
itself for use in relocating loaded object modules (much like lush).
Under most cases, it never invokes the linker again in the process of
building maxima, acl2, axiom, and any other dependent packages, and
all is well. On mips, mipsel, hppa, ia64 and alpha (GCL stable), and
ia64 and hppa (gclcvs), native object relocation is not yet
implemented, so GCL builds its dependent packages by running ld at
several points against a libgcl.a that it ships. I've had this link
produce garbage on these platforms due to a binary api incompatibility
between the binutils available at gcl build time, and that available
at dependent package build time. When I enforce the version
dependency (on the static libbfd) in the package control mechanism, I
run into these 'uninstallable' issues too frequently forcing a rebuild
anyway -- I might as well depend on a shared lib and have this happen
Of course the right thing to do is to extend the native object
relocation to ia64 and hppa -- this is of course GCL's problem, but it
will take some time. Perhaps the second best is to make use of a
configure option in GCL to build its own local bfd snapshot and ship
this in libgcl.a, but this is burdensome in the long run too. Another
alternative is to ship the C source of the bfd symbol building table
routines and compile and run this all over again when using GCL to
build its dependencies, but this truly appears too unwieldy.
> Daniel Jacobowitz
> CodeSourcery, LLC
Camm Maguire email@example.com
"The earth is but one country, and mankind its citizens." -- Baha'u'llah