[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: gcl binutils copy
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Re: gcl binutils copy |
Date: |
Tue, 28 Sep 2010 08:56:37 -0400 |
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 <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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gcl-devel] Re: gcl binutils copy,
Camm Maguire <=