[racket] link errors on 64bit

[David Griffiths]

Hi all,

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?

cheers,

dave
____________________
Racket Users list:
http://lists.racket-lang.org/users

[Matthew Flatt]

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')?

And it's happening when you link your program to "libracket3m.a", as
opposed to just building Racket, right? Is your code compiled `-fPIC'
(while the Racket code isn't, I think)?

[David Griffiths]

Hi Matthew,

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...

cheers,

dave

[David Griffiths]

Hi Matthew,

Any ideas on where the solution to this would be?
Are the Ubuntu package maintainers on this list?

[Matthew Flatt]

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.)

[David Griffiths]

On 29/05/13 02:03, Matthew Flatt wrote:
> 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.)

I see, interesting...

> 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'.

I've been trying to avoid maintaining my own racket package, but it
sounds like that might be the best option at this stage.

It's tempting to static link libracket3m - it does break the spirit of
debian packaging, but the argument for this is a bit stronger as I'm
only using a small proportion of what racket provides.

Hmm, I will have a think...

cheers,

dave