Project

General

Profile

Bug #755

Find out how to compile statically on linux

Added by Anna Maria Bigatti over 8 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Release
Target version:
Start date:
31 Jul 2015
Due date:
% Done:

100%

Estimated time:
11.66 h
Spent time:

Description

many libraries are compiled dynamically. Not good for a released binary..


Related issues

Related to CoCoA-5 - Design #1146: Use Flatpak and/or Snap on Linux?New2018-01-08

Related to CoCoA-5 - Bug #1442: CoCoAInterpreter: executable sizeClosed2020-03-10

Related to CoCoA-5 - Support #1445: Automatic way to produce statically linked CoCoAInterpreterNew2020-03-12

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
I propose:
  • 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

I am now fairly convinced that:
  • 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

It seems that I must specify both 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

I think this issue has run its course, so I'm closing it.

The important points are:
  • comment 24 (all of it)
  • comment 25 (esp. the StackOverflow reference)
  • the "illegal instruction" bug in issue #1443
  • any future work about this should be in issue #1445

Also available in: Atom PDF