Bug #755
Find out how to compile statically on linux
Description
many libraries are compiled dynamically. Not good for a released binary..
Related issues
History
#1 Updated by Anna Maria Bigatti about 8 years ago
- Target version changed from CoCoA-5.1.3/4 Jan 2016 to CoCoA-5.2.0 spring 2017
#2 Updated by John Abbott almost 8 years ago
Until we resolve this issue I would suggest making publicly available a minimal version of CoCoA-5 which does not depend on any external dynamic libraries. Last week I was embarassed to find out that the compiled CoCoA-5 we distribute did not work on my linux box here in Kassel (because libblas
was missing, and I could not find out quickly how to install it).
I do realise that this will make it a bit more confusing for Linux users who want to install CoCoA-5: they have to decide between two versions (probably without really understanding what the difference is).
In fact, I would be tempted to make the version which needs libblas
less immediately obvious; amongst other things it contains extensions which do not interest me (at the moment, anyway).
#3 Updated by Anna Maria Bigatti almost 8 years ago
John Abbott wrote:
In fact, I would be tempted to make the version which needs
libblas
less immediately obvious; amongst other things it contains extensions which do not interest me (at the moment, anyway).
On this I totally agree: the CoCoA functions using libblas
are not even documented!
I had not realized that libblas
was not in linux by default.
I'll try and make a 5.1.4 without libblas
.
#4 Updated by John Abbott over 7 years ago
I record that on 2016-05-20 Logar sent the following email (in italian) which says that the critical linux package to install (for having libblas
) is called libopenblas-base
.
> Cara Anna, > dopo qualche tentativo, ho visto in rete sul sito: > http://packages.ubuntu.com/precise/libblas.so.3gf > che il pacchetto si trova in 3 pacchetti diversi. Ho provato ad installare > il terzo, cioe' libopenblas-base (i due precedenti diceva che non li trovava) > e ora cocoa funziona!!
In any case, as already hinted above, it seems best to make the distributed executable without libblas
(possibly adding a note that we can make a version with libblas
for those who really need it???)
#5 Updated by John Abbott over 7 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
Since the fns which depend on libblas
are not documented, perhaps all public versions should be without them (not just the Linux executable). I would prefer that all the different executables be as similar as possible (in terms of functions available).
#6 Updated by John Abbott over 7 years ago
A recent email from Michael Wheat reports that installing libopenblas
is not sufficient (at least not for him).
With luck Anna will make a blas-free Linux executable on Monday (hint, hint!)
#7 Updated by John Abbott over 7 years ago
Michael Wheat reports that Anna's compilation (without libblas) works fine for him.
Does that mean we can make progress with this issue?
#8 Updated by John Abbott over 7 years ago
Has the blas-free version been put on the website?
#9 Updated by John Abbott over 7 years ago
I have built what seems to be a portable 32-bit executable of CoCoAInterpreter
on the Linux VM (on my old MacBook). The only thing missing is readline
.. apparently it is not on the VM.
#10 Updated by Anna Maria Bigatti almost 7 years ago
- Target version changed from CoCoA-5.2.0 spring 2017 to CoCoA-5.2.2
#11 Updated by Anna Maria Bigatti over 6 years ago
for Anna: remember readline.a!!!!!
#12 Updated by John Abbott about 6 years ago
- Related to Design #1146: Use Flatpak and/or Snap on Linux? added
#13 Updated by Anna Maria Bigatti about 6 years ago
- % Done changed from 10 to 20
Readline done, but still this contains some other dynamic library.
Final (sad) decision: no readline in the linux binary release.
#14 Updated by Anna Maria Bigatti about 6 years ago
- Target version changed from CoCoA-5.2.2 to CoCoA-5.2.4
#15 Updated by John Abbott about 6 years ago
- Target version changed from CoCoA-5.2.4 to CoCoA-5.2.2
- % Done changed from 20 to 70
Another external library which causes trouble is libreadline
.
On my current linux box the system installed readline library was a shared one, but I could install a static one too.
The CoCoAInterpreter executable using the static libreadline.a
did not work on another linux box because of a version incompatibility in libtinfo.so
.
Our solution is to release CoCoAInterpreter
without readline. We may make an alternative version with readline which the "adventurous" can try.
Another possibility would be to make a linux distribution with both executables. The script could then try first to run CoCoAInterpreter-readline
, and if that fails then to run CoCoAInterpreter-no-readline
. This would make the distribution file rather large (but would anyone care?)
#16 Updated by John Abbott about 6 years ago
- Target version changed from CoCoA-5.2.2 to CoCoA-5.2.4
#17 Updated by John Abbott over 5 years ago
- Target version changed from CoCoA-5.2.4 to CoCoA-5.3.0
#18 Updated by John Abbott about 4 years ago
- Assignee set to John Abbott
- % Done changed from 70 to 90
- make Linux binaries without libblas
- make two binaries: the default one with
readline
, and another one without (in case the user has trouble with incompatible readline)
We should try to make sure that we use a fairly recent version of readline
.
#19 Updated by John Abbott about 4 years ago
Now I wonder if it may not be better to have the version without readline
being the default: it is less likely to complain about a missing library, and anyone who uses CoCoA-5 inside Emacs (or some other GUI) does not need readline
.
Undecided... :-/
#20 Updated by John Abbott about 4 years ago
- default Linux version should be without
readline
- ideally we also make available a version with
readline
(but this is perhaps less urgent/important)
If CoCoA-5 is to be used inside any "fancy interface" (e.g. emacs, vim, GUI) then the readline
capability is not needed; and I suspect most people will want to use CoCoA-5 inside such an interface. The readline
version is useful only for those who wish to use CoCoA-5 directly from a terminal.
#21 Updated by John Abbott about 4 years ago
Sometimes I engage brain before writing, sometimes I don't... (sigh)
When I build CoCoA-5 on my current Linux box, I explicitly link with a static version of libreadline.a
; there can still be further problems with (dynamic) libraries that libreadine
itself depends on... maybe I can link explicitly with static versions of those?
I was surprised to see that a minimal CoCoA-5 executable is already about 32Mbytes; with all external libraries linked in, that becomes more than 80Mbytes! Wow! 8-O
Perhaps the easy solution is to make a release with both, and decide at launch-time which to use: i.e. try with libreadline
first, if that fails, use the version without. That will make quite a large distribution file (since each executable is over 80Mbytes).
#22 Updated by John Abbott about 4 years ago
libreadline
on my Ubuntu machine depends on the tinfo
library; I have a static version at /usr/lib/x86_64-linux-gnu/libtinfo.a
Florian reported that the pre-released version of 5.3.0 did not work directly on his computer, and that he had to install an old version of the dynamic library for tinfo
. Using the static version should avoid that problem, but another may pop up in its place...
#23 Updated by John Abbott about 4 years ago
- Related to Bug #1442: CoCoAInterpreter: executable size added
#24 Updated by John Abbott about 4 years ago
libtermcap
and libtinfo
statically (and in that order!). On my Ubuntu box they are in:
/usr/lib/x86_64-linux-gnu/libtermcap.a
/usr/lib/x86_64-linux-gnu/libtinfo.a
NOTE external library dependencies can be seen by running readelf -d ./CoCoAInterpreter | fgrep NEEDED
#25 Updated by John Abbott about 4 years ago
I have just found on StackOverflow that one can use gcc
to find where libraries are:
$ gcc -print-file-name=libtinfo.a /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libtinfo.a
This gives me some hope that we could create an automatic scheme which links (most) libraries statically; this is probably useful only for public releases...
REFERENCE https://stackoverflow.com/questions/4156055/static-linking-only-some-libraries
#26 Updated by John Abbott about 4 years ago
- Related to Support #1445: Automatic way to produce statically linked CoCoAInterpreter added
#27 Updated by John Abbott about 4 years ago
- Status changed from In Progress to Closed
- % Done changed from 90 to 100
- Estimated time set to 11.66 h