[Ecls-list] fatal: relocation errors on Solaris x86 and OpenSolaris 64-bit.

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Mon Aug 30 12:18:59 UTC 2010


On Mon, Aug 30, 2010 at 1:52 PM, Dr. David Kirkby
<david.kirkby at onetel.net>wrote:

> But Solaris 10 has not died, neither or x86 or SPARC. The issues are seen
> on Solaris 10 SPARC too, so it not just an x86 problem. Maxima is not
> complaining on SPARC, but the elfdump command clearly shows the problem is
> in the ECL library file. That problem exits on 64-bit SPARC  too.
>
> kirkby at t2:64 ~/t2/64/sage-4.5.3.alpha2/local/lib$ uname -a
> SunOS t2 5.10 Generic_141414-02 sun4v sparc SUNW,T5240
> kirkby at t2:64 ~/t2/64/sage-4.5.3.alpha2/local/lib$ elfdump -d libecl.so |
> fgrep TEXTREL
>      [18]  TEXTREL           0
>      [30]  FLAGS             0x4                 [ TEXTREL ]
>

The output of fgrep is not at all informative. If TEXTREL is a signature of
non-PIC code then elfdump must also provide the names of the symbols that
have this problem. This will in turn provide a clue as to which object files
were not compiled with PIC. Could you please provide this information, as I
suggested in the previous email.

The problem can't be Maxima, as I don't need to even build Maxima to show
> the ECL code has this problem.
>

Please understand my statements in the appropriate context. Maxima is
compiled with ECL and while ECL runs just fine, the Maxima executable does
not. The problem might be in the compilation statements that build the
resulting code, since ECL seems to work just fine -- even if as you suggest
there are non-PIC sections.


> Note also, that there's this compiler warnings when I build on Solaris (or
> any sort)
>
> /export/home/drkirkby/sage-4.5.3.alpha2/spkg/build/ecl-10.2.1.p2/src/src/c/dpp.c:680:13:
> warning: too many arguments for format
>

The compiler is probably wrong. gcc here does not detect any problem and I
do not see any obvious one in dpp.c In any case this file is not related to
the relocation issues since its only responsibility is to preprocess C files
when bootstrapping ECL and it seems to be doing it just fine.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100830/e7a38b7d/attachment.html>


More information about the ecl-devel mailing list