Bug #1443
Illegal instruction
Description
I sent a compressed stripped binary to Matteo via email, but he reports a problem with Illegal instruction.
Investigate and fix.
Related issues
History
#1
Updated by John Abbott about 4 years ago
Updated by - Status changed from New to In Progress
- % Done changed from 0 to 10
I do not know what the problem can be at the moment.
I would not expect stripping a binary to cause such a problem; anyway, I have sent a split, compressed, unstripped binary, and am awaiting feedback.
A possibility is that the compiler on my "recent" processor, used some machine instructions which do not exist on some "old" processor.
I'm not sure what compilation flags to set to force the binary to be portable.
#2
Updated by John Abbott about 4 years ago
- % Done changed from 10 to 20
Maybe the correct flag is NO! This did not work (see comment 5)-march=i686.
Presumably this has to be specified for all external libraries as well.... groan! 8-{
I wonder why we have not had any problems before... am I barking up the wrong tree?
#3
Updated by John Abbott about 4 years ago
- Assignee set to John Abbott
I'm still waiting for feedback from Matteo.
#4
Updated by John Abbott about 4 years ago
- Related to Support #1445: Automatic way to produce statically linked CoCoAInterpreter added
#5
Updated by John Abbott about 4 years ago
It seems that --march=i686 is not correct. It says that it does not support x86_64 instruction set :-(
Investigating.
#6
Updated by John Abbott about 4 years ago
- % Done changed from 20 to 30
There is information on the web page:
https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html
So far compilation is proceeding with --mtune=generic (and no --march option).
I hope Matteo can test it for me...
#7
Updated by John Abbott about 4 years ago
It could also be that the "illegal instruction" does not come from CoCoA at all, but is in one of the already compiled libraries... 8-{
I can recompile some of the libraries, but surely not MSat. Also it could be tedious having to recompile readline...
Note: it seems that CoCoA queries all libraries for their version info as soon as it is started, and without the user calling the VersionInfo function.
#8
Updated by John Abbott about 4 years ago
The illegal instruction seems to be coming from the statically linked GMP library -- that is libgmp.a (and/or libgmpxx.a) from my computer.
I have downloaded the latest GMP, and will try with that.
#9
Updated by John Abbott about 4 years ago
OK, I do not know what is going on. This is really annoying!
I have compiled CoCoA-5 with the generic option (which should guarantee that it works with all x86-64 processors).
I have compiled gmp-6.2.0 with the --enable-fat option which should make it work with all x86-64 processors.
The resulting CoCoAInterpreter starts, but as soon I run VersionInfo() it gives an "illegal instruction".
Conclusion: we cannot have a portable release with statically linked GMP!
What to do??? I'm pretty annoyed -- I'm visiting Dorothee and did not want to waste so much time fruitlessly.
#10
Updated by John Abbott about 4 years ago
- Target version changed from CoCoA-5.3.0 to CoCoA-5.4.0
I have postponed this issue to the next release. This release we used the workaround to compile on a different machine, which seems to produce a trouble-free binary (but how can we guarantee this?)
Is the problem inside libgmp.a? Why did --enable-fat not work as I expected?
Ideally each person should compile on their own machine, but this may not be possible if the user cannot "become root".
#11
Updated by John Abbott over 3 years ago
Siamo ancora in contatto con Matteo?
#12
Updated by John Abbott over 2 years ago
Esiste ancora questo problema? Non ho piu` sentito niente.
Possiamo semplicement chiudere l'issue?
#13
Updated by John Abbott about 2 years ago
- Status changed from In Progress to Closed
- % Done changed from 30 to 100
- Estimated time set to 4.19 h
This issue has been dormant for 2 years. I suppose whatever the problem was has gone away.
Closing!