gcl currently not built on armel, needed as a build-dependency

david, please look into that

After resolving the linker issue I found other issues in the build. In the end, the only way I have been able to get this to build was by disabling thumb2, much like was done for hdf5. I did not like this answer, but I am attaching a patch/debdiff for doing this on armel so we can move forward.

This was not my preferred fix, but what I ended up doing for armel for this, and no worse than what was done for hdf5. If it can be confirmed as release critical I will be happy to attach sponsors.

Do we have a list of packages reverted to -marm, or a standard tag?

I sounds like we ought to review over them at some point.

This bug was fixed in the package gcl - 2.6.7-60ubuntu1

---------------
gcl (2.6.7-60ubuntu1) maverick; urgency=low

  * fix armel support and disable thumb2 on armel (LP: #636977)
 -- David Sugar <email address hidden> Thu, 16 Sep 2010 20:01:59 +0000

keep it open, because it's built with -marm

I did a little investigation of this issue on Friday. I'm not too familiar with gcl: it looks like it compiles via C, and the only architecture-dependent parts are in a fork of binutils internal to the gcl source tree.

Unfortunately gcl seems to be in a dormant state at present: the last news on the website (http://www.gnu.org/software/gcl/) dates from 2005. Also the version of binutils used appears to date from around the same time period, going by the ChangeLogs. Using a version of binutils that old isn't a great idea for Thumb-2 for various reasons: many bugs have been fixed since then, and e.g. the older version of binutils won't have the Cortex-A8 erratum workaround implemented in the linker, which may lead to problems sooner or later.

I'm not sure what it takes to update the binutils used by gcl to a modern version: that might be the easiest fix (it's then kind of a packaging issue, I guess), assuming the gcl version of binutils doesn't have significant local changes (otherwise cherry-picking and backporting changes would be necessary). It seems suboptimal to maintain a fork of binutils like this though: if at all feasible, it seems like it'd be better to use the "normal" version of binutils supplied with the distro. That might entail pushing local GCL changes -- if there are any -- upstream.

For Maverick and present release timelines, certainly disabling thumb2 is a valid temporary solution. But yes, we need to resolve this long term. I very much hate the idea of having a separate local fork of binutils inside a package as well.

I wrote to the Debian maintainer asking how we could avoid using the builtin binutils copy; he seems to be upstream for gcl as well.

----- Forwarded message from Camm Maguire <email address hidden> -----

From: Camm Maguire <email address hidden>
Date: Tue, 28 Sep 2010 08:56:37 -0400
Subject: Re: gcl binutils copy
Cc: <email address hidden>
To: Loïc Minier <email address hidden>
Message-ID: <email address hidden>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Greetings!

gcl has several modes for native object relocation, implemented via
configure switches:

--enable-statsysbfd -- use the system installed static bfd library,
  path probed at configure time using standard environment variables

--enable-dynsysbfd -- use the system installed dynamic bfd library,
  path probed at configure time using standard environment variables.
  This is not recommended, as bfd upstream does not maintain binary
  compatibility within identical sonames

--enable-locbfd -- use the local bfd copy cached in the source tree

--enable-custreloc -- use relocation code for elf, coff, and mach-o
  provided by gcl natively. armel is supported here in the -63 and
  above debian package series, and is the default here. Don't know
  about armhf, as debian-ports has not picked gcl up yet. This is the
  future direction, as it is smaller and simpler, and as bfd does not
  support all the targets gcl needs anyway.

--enable-dlopen -- load each file using dlopen. This is the worst
  option, as it cannot preserve relocated loaded code into the unexec
  saved image, as is typical in lisp usage.

If you are building -60, the default for arm should be --statsysbfd,
which means you are using the latest binutils installed on your
system. The local copy is never required, and is just there for users
who cannot or do not want to install binutils themselves.

Take care,

Loïc Minier <email address hidden> writes:

> Hey there
>
> we were looking into what seemed to be a binutils issue while building
> the gcl .deb at
> https://bugs.launchpad.net/ubuntu/+source/gcl/+bug/636977 but it turned
> out that it has a builtin copy of binutils.
>
> Apparently, it's also relatively old, at least in parts. I see that
> the Debian diff is quite large and patches the copy substantially, I
> guess pulling in new updates, but I couldn't find the exact version
> information of what's pulled in there. binutils/gas/ChangeLog is from
> 2005, binutils/bfd/ChangeLog as well.
>
> I wonder whether gcl could be built against regular binutils (the
> binutils package provides a copy of libbfd at least), or if we could
> patch binutils to allow this (perhaps providing more libs), or failing
> that if gcl could use binutils-source instead?
>
> Thanks!
> --
> Loïc Minier
>
>
>
>

--
Camm Maguire <email address hidden>
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

----- End forwarded message -----

--
Loïc Minier

----- Forwarded message from Loïc Minier <email address hidden> -----

From: Loïc Minier <email address hidden>
Date: Wed, 29 Sep 2010 00:59:47 +0200
Subject: Re: gcl binutils copy
Cc: <email address hidden>
To: Camm Maguire <email address hidden>
Message-ID: <email address hidden>

        Hey

On Tue, Sep 28, 2010, Camm Maguire wrote:
> gcl has several modes for native object relocation, implemented via
> configure switches

 Wow, awesome notes, thanks

> --enable-statsysbfd -- use the system installed static bfd library,
> path probed at configure time using standard environment variables

 Hmm I don't think Debian nor Ubuntu provide static bfd though; I
 remember asking that recently to Matthias Klose because the current
 shared libbfd generate painfully tight dependencies for packages like
 oprofile, or more recently the linux-tools' "perf" utility.

> --enable-custreloc -- use relocation code for elf, coff, and mach-o
> provided by gcl natively. armel is supported here in the -63 and
> above debian package series, and is the default here. Don't know
> about armhf, as debian-ports has not picked gcl up yet. This is the
> future direction, as it is smaller and simpler, and as bfd does not
> support all the targets gcl needs anyway.
[...]
> If you are building -60, the default for arm should be --statsysbfd,
> which means you are using the latest binutils installed on your
> system. The local copy is never required, and is just there for users
> who cannot or do not want to install binutils themselves.

 Sounds great; we shall just move to -63 for armel then; we will see
 whether that works fine with thumb2 binaries!

 As you note, it's a bit early to speak about armhf; let's see what
 happens :)

    Cheers,
--
Loïc Minier

----- End forwarded message -----

--
Loïc Minier

With David's patch in debian/rules, packages built fine. Can we close this bug then?

On 27.10.2010 15:10, Artur Rona wrote:
> With David's patch in debian/rules, packages built fine. Can we close
> this bug then?

No, the goal should be to build it with the current defaults.

gcl 2.6.7-87ubuntu1 builds for armv5t by default

2.6.7-101 in Quantal is building on armel, so I am marking this as Fix Released.