workaround for problems with relocation on the x32 architecture

[czurnieden]

A proposal for a workaround for the x32 relocation problem.

[sjaeckel]

@dod38fr can you please try if this solves the problems described in #154 ?

[dod38fr]

@sjaeckel I'm trying first a newer version of libtool as debian wiki mentions that old libtool may trigger issues related to relocation (although the error messages between the wiki and the logs are not the same). As it happens, I've a Debian bug that asks me to stop using old version of libtool while building Debian package...

After that, I'll try this patch.

[czurnieden]

@dod38fr seems to work with the patch attached to bug 912838. Please drop a note when it is official, so I can declare this branch as obsolete and delete it. (it's nothing I would mourn for, it wasn't the most elegant piece of code in the first place ;-) ) Is it known what libtool bug(s) caused it?

[czurnieden]

@dod38fr No, I have to take it back, sorry. Seems as if I did a bad job cleaning all caches. *sigh*

[dod38fr]

@czurnieden I've uploaded a libtommath version 1.1.0-3~exp1 to debian experimental. This new verson contains the patch of this PR.

The build results look good on x32.

[czurnieden]

@dod38fr saw the problems with m68k, tried a patch. See #156 if you want to give it a try.

[minad]

I am not convinced that the visibility attributes are a good solution. What is the reason for the relocation error?

Furthermore we should decide on an API concerning the tuning parameters instead of exposing mp_get_KARATSUBA_* and mp_set_KARATSUBA_* functions depending on compile flags.

[czurnieden]

I am not convinced that the visibility attributes are a good solution.

Neither am I, but that is the best solution offered yet. One of the better solutions would be getter/setter functions.

What is the reason for the relocation error?

The linker does not know enough at linking time and thinks it needs to export them outside of the lib, too. A short search with Google shows some results that seem to show a tendency to accept it, the visbility(hidden) that is, as good enough. Vid. e.g.: https://bugs.chromium.org/p/webm/issues/detail?id=46#c6

Furthermore we should decide on an API concerning the tuning parameters instead of exposing mp_get_KARATSUBA_* and mp_set_KARATSUBA_* functions depending on compile flags.

Tuning is a one-time activity at compile time and I think a macro should suffice, as long as it is documented. Everything else needs some automatic configuration method (e.g.: autoconf).

[sjaeckel]

@dod38fr do I understand correctly that debian on x32 builds now without this patch? (after you updated libtool)

[dod38fr]

@sjaeckel No. This PR is required to build Debian on x32. The libtool update did not change the result

All the best

[minad]

@czurnieden Since these tuning parameters should be constant, could we instead use macros? Then we could allow overwriting these macros for tuning.

#ifndef KARATSUBA_CUTOFF
#define KARATSUBA_CUTOFF value-determined-by-tuning
#endif

Compilation for the demo will then overwrite this as follows

#define KARATSUBA_CUTOFF get_karatsuba_cutoff()

and the function can be defined in the tuning program. This would reduce the ugliness of this issue a bit. We would still need the visibility attributes though.

[sjaeckel]

I don't like the idea of having a different ABI&API on x32 than on the other architectures, so I'm also tending towards a "won't fix" until 2.0.0

@dod38fr which way do you suggest to go? what do the debian guidelines say?

[minad]

Wontfix is appropriate 👍 x32 is a dead end.

[sjaeckel]

@dod38fr would it be fine for you (and debian) if we won't fix this? I also don't see much future for x32

[dod38fr]

@sjaeckel x32 is not "officially" supported by Debian, so skipping x32
is fine.

This means that perl6 and some other reverse dependencies like
firebird won't be available on x32. I suspect that nobody will
complain.

I'll remove this arch from the list of target of libtomath
package.

[czurnieden]

I'll remove this arch from the list of target of libtomath package.

Ah, thanks! One headache less.

[minad]

Ok good, I close this then. If the need comes up from the perl6 guys or other interested parties, this issue can be reopened.