[racket] link errors on 64bit
At Tue, 28 May 2013 14:28:04 +0100, David Griffiths wrote:
> Hi Matthew,
>
> On 24/05/13 23:54, David Griffiths wrote:
> > On 24/05/13 18:44, Matthew Flatt wrote:
> >> At Thu, 23 May 2013 14:43:18 +0100, David Griffiths wrote:
> >>> I've been getting a problem for some time building against the racket
> >>> ubuntu packages on 64 bit:
> >>>
> >>> /usr/bin/ld: /usr/lib/libracket3m.a(salloc.o): relocation
> >>> R_X86_64_TPOFF32 against `scheme_thread_locals' can not be used when
> >>> making a shared object; recompile with -fPIC
> >>>
> >>> Any chance this can be resolved?
> >>
> >> Is this with a vanilla Racket build (e.g., no `--enable-shared')?
> >
> > Probably - this is using the packages in the main PLT ubuntu launchpad
> > ppa. I imagine they are built with vanilla settings.
> >
> >> And it's happening when you link your program to "libracket3m.a", as
> >> opposed to just building Racket, right?
> >
> > Right.
> >
> >> Is your code compiled `-fPIC' (while the Racket code isn't, I think)?
> >
> > It is indeed, as I'm building shared objects to load as racket modules.
> >
> > I'm not clear why this is a problem with 64bit and not with 32, but I am
> > a little rusty on this stuff...
>
> Any ideas on where the solution to this would be?
> Are the Ubuntu package maintainers on this list?
A drawback of adding `-fPIC' to the Racket build by default is that
everyone would pay a little of performance. For example,
racket -c -l racket
seems to take 5-8% longer when Racket is compiled with -fPIC. That's
probably about the worst-case hit, though, since loading `racket' from
source spends a lot of time in the C-implemented run-time system. An
example that spends all its time in JIT-generated code is unaffected.
(I also tried GC-intensive examples, but `-fPIC' doesn't seem to have
much effect on the Racket GC.)
Since the cost isn't so big, so I think it might be ok to add -fPIC to
the Ubuntu PPA's build. Another option is adding it as a default flag
for 64-bit Linux at the `configure' level, but that seems more complex.
But how important is it in your context to use the PPA-supplied
"libracket3m.a"? You could build your own "libracket3m.a" from the
Racket source, suppling `CPPFLAGS=-fPIC' to `configure'.
(On 32-bit x86 Linux, -fPIC isn't required for shared libraries.)