Greetings, and thanks so much for your helpful reply! Daniel Jacobowitz <[EMAIL PROTECTED]> 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 > Allowed. > > 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 case. > > 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 automatically. 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. Take care, > -- > Daniel Jacobowitz > CodeSourcery, LLC > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]