[Gcl-devel] Re: gcl binutils copy

[Camm Maguire]

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 <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                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah