|
Home > Archive > Debian Developers > August 2004 > gcl/axiom/acl2/maxima versioned depends on binutils-dev
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
gcl/axiom/acl2/maxima versioned depends on binutils-dev
|
|
| Camm Maguire 2004-08-11, 2:51 am |
| Greetings! All programs built atop the gcl common lisp system are
capable of loading compiled binary objects and relinking and saving a
new system image, in most cases via libbfd. The bfd compiled into gcl
must be compatible with that against which the system ld is
dynamically linked for this to work. The simple solution is to make a
versioned depends on binutils-dev, but I don't want to be in the
position of having to re-upload all these programs when binutils
changes. Rather, I'd like a new (incompatible) binutils to trigger a
rebuild first of gcl and then of maxima,acl2, and axiom automatically
via the autobuilders if possible. Can this be done?
Take care,
--
Camm Maguire camm@enhanced.com
========================================
==================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-08-11, 2:51 am |
| Camm Maguire <camm@enhanced.com> writes:
> Greetings! All programs built atop the gcl common lisp system are
> capable of loading compiled binary objects and relinking and saving a
> new system image, in most cases via libbfd. The bfd compiled into gcl
> must be compatible with that against which the system ld is
> dynamically linked for this to work. The simple solution is to make a
> versioned depends on binutils-dev, but I don't want to be in the
> position of having to re-upload all these programs when binutils
> changes. Rather, I'd like a new (incompatible) binutils to trigger a
> rebuild first of gcl and then of maxima,acl2, and axiom automatically
> via the autobuilders if possible. Can this be done?
No.
Why not? Every new upload to the archive has to have a version higher
than the one present. That means that at the minimum you need to patch
the changelog file to make a binary-only recompile upload
(e.g. x.y-z.0.1). While the buildds have a mechanism to patch sources
on build and to requeue sources for a rebuild there is no mechanism in
place to distribute such patches or to autogenerate them when another
package is uploaded.
Alos note that you have to recompile the package on all architectures
anyway, so (unless you have a huge diff) uploading a new debian
revision is far simpler.
Since I am involved in packages with a similar problem
(sourcerer-kernel-builder, amd64-libs and grub) I have spend some
thoughts on this. I think the best thing is to setup a cron job or an
apt watcher (see sourcerer-kernel-builder) that monitors updates of
the respective packages, generates a new source package in the
background and mails the maintainer for testing and uploading.
> Take care,
> --
> Camm Maguire camm@enhanced.com
> ========================================
==================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Daniel Jacobowitz 2004-08-11, 5:57 pm |
| On Wed, Aug 11, 2004 at 04:41:48PM -0400, Camm Maguire wrote:
> OK, given what you state, the 'natural' way to do this of course is to
> have gcl dynamically link against libbfd -- then soname changes
> automatically make the old package uninstallable without a recompile.
Don't do this.
> Part of the issue is the bfd soname numbering system. Minor point
> changes are deemed backward binary incompatible. Were it more like
> libc, for example, the situation would be more tolerable. I'm
> wondering if now that binutils is at 2.15, future development might
> follow a more conventional major/minor numbering scheme maintaining
> backward binary compatibility for a longer period of time.
No.
BFD is not an exported library; its API is subject to continual and
random flux. The only reason Debian installs a shared version is that
it saves a lot of disk space.
I see that binutils-dev includes the libbfd.so and libopcodes.so
symlinks. IMVHO, it shouldn't.
--
Daniel Jacobowitz
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Camm Maguire 2004-08-11, 5:57 pm |
| Greetings, and thanks so much for your helpful reply!
OK, given what you state, the 'natural' way to do this of course is to
have gcl dynamically link against libbfd -- then soname changes
automatically make the old package uninstallable without a recompile.
Problem with this is that given that maxima,acl2, and axiom are
'dumps' of the whole (modified) gcl image, each of these will also
depend in this manner on the libbfd soname. Rebuilding acl2 and axiom
on all platforms takes about 2 weeks, and given the history of a
binutils version change every few months in 2003, this gets to be
onerous.
Part of the issue is the bfd soname numbering system. Minor point
changes are deemed backward binary incompatible. Were it more like
libc, for example, the situation would be more tolerable. I'm
wondering if now that binutils is at 2.15, future development might
follow a more conventional major/minor numbering scheme maintaining
backward binary compatibility for a longer period of time.
Right now, gcl links in libbfd statically for this reason, and waits
for somebody to report a FTBFS error on one of the gcl outputs. This
of course is less than optimal. I think a middle ground might be to
hand insert a versioned bintutils depends for gcl only for the
following reason.
GCL uses binutils in two places 1) loading compiled binary objects
(output by ld), and 2) relinking itself and building its own bfd
symbol hash table. 1) is used by maxima, acl2, and axiom all the
time, whereas 2) requires gcl to be installed in any case. I'm hoping
that the functionality in 1), which is simply a call to
bfd_get_relocated_section_contents, will work more reliably with
future ld output than 2), but of course this is not guaranteed.
Perhaps the binutils developers could comment.
Take care,
Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
> Camm Maguire <camm@enhanced.com> writes:
>
>
> No.
>
> Why not? Every new upload to the archive has to have a version higher
> than the one present. That means that at the minimum you need to patch
> the changelog file to make a binary-only recompile upload
> (e.g. x.y-z.0.1). While the buildds have a mechanism to patch sources
> on build and to requeue sources for a rebuild there is no mechanism in
> place to distribute such patches or to autogenerate them when another
> package is uploaded.
>
> Alos note that you have to recompile the package on all architectures
> anyway, so (unless you have a huge diff) uploading a new debian
> revision is far simpler.
>
>
> Since I am involved in packages with a similar problem
> (sourcerer-kernel-builder, amd64-libs and grub) I have spend some
> thoughts on this. I think the best thing is to setup a cron job or an
> apt watcher (see sourcerer-kernel-builder) that monitors updates of
> the respective packages, generates a new source package in the
> background and mails the maintainer for testing and uploading.
>
>
> MfG
> Goswin
>
>
>
--
Camm Maguire camm@enhanced.com
========================================
==================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|