gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Unrelocated symbol: __aeabi_unwind_cpp_pr1


From: Camm Maguire
Subject: Re: [Gcl-devel] Unrelocated symbol: __aeabi_unwind_cpp_pr1
Date: Tue, 09 Sep 2014 11:09:39 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Greetings!

GCL parses its own elf symbol table when constructing the saved image
for subsequent use in linking.  The general idea (in 2.6.x) is that
loaded compiled code will only refer directly to symbols in the base
image. 

There are two machines, hppa and aarch64, which wind up needing helper
symbols in libgcc that were unused in the base image.  If such symbols
are cross-platform, we usually try to resolve this by constructing a
reference in the base image.  Otherwise, as is the case on hppa and
aarch64, we link in libgcc statically:

Here are the relevant lines in configure.in:

                aarch64*)
                        TLIBS="$TLIBS -lgcc_s";;
                hppa*)
                        TCFLAGS="$TCFLAGS -mlong-calls "
                        TLIBS="$TLIBS -lgcc_s" # workaround hppa __moddi3 local 
func symbols with default linker flags

In truth, I am not sure if this work around is relying on an artifact of
ld, but nevertheless, the latter is currently writing the needed symbols
when thus invoked.  If you modify configure.in to add TLIBS="$TLIBS
-lgcc_s"; for your machine and run autoconf, that should do it.

Alternatively, you could edit the function use_symbols in sfasli.c and
put in dummy calls to the functions you need.

Will Newton's very helpful suggestion on --shared-libgcc will probably
also work, but it will insert trampolines for the symbols and will be
somewhat less efficient.  

I'm thinking if we can assure ourselves that -lgcc_s will work into the
future, we might as well make that the default for all targets and
dispense with this.

Take care,



Will Newton <address@hidden> writes:

> On 9 September 2014 04:12, Jerry James <address@hidden> wrote:
>> Hi,
>>
>> I attempted to build gcl 2.6.11 for Fedora tonight.  The builds for
>> i386 and x86_64 seem fine, but the 32-bit ARM build failed, like so:
>>
>> Finished compiling /builddir/build/BUILD/gcl/unixport/../pcl/gcl_pcl_pkg.o.
>> Loading binary of GCL_PCL_PKG...
>> Loading /builddir/build/BUILD/gcl/unixport/../pcl/gcl_pcl_pkg.o
>> Error: The assertion !fprintf(stderr,"Unrelocated non-local symbol:
>> %s\n",st1+sym->st_name) on line 236 of sfaslelf.c in function
>> relocate_symbols failed
>> Fast links are on: do (si::use-fast-links nil) for debugging
>> Error signalled by OR.
>> Broken at OR.  Type :H for Help.
>>>>Unrelocated non-local symbol: __aeabi_unwind_cpp_pr1
>> makefile:34: recipe for target 'gcl_pcl_boot.c' failed
>> make[1]: Leaving directory '/builddir/build/BUILD/gcl/pcl'
>> make[1]: *** [gcl_pcl_boot.c] Error 255
>> makefile:83: recipe for target 'unixport/saved_pcl_gcl' failed
>> make: *** [unixport/saved_pcl_gcl] Error 2
>>
>> A little web searching revealed that the symbol __aeabi_unwind_cpp_pr1
>> is defined in libgcc.  It is one of the exception handling personality
>> routines, and has reloc type R_ARM_NONE.  What does this assertion
>> failure imply, and what can I do to fix it?
>
> It's possible that this patch might fix it:
>
> http://lists.gnu.org/archive/html/gcl-devel/2014-07/msg00030.html
>
> Although the R_ARM_NONE reloc type sounds like maybe we should just
> ignore it (could be a linker bug?).

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]