Project

General

Profile

Bug #1226

ExternalLibs return empty list

Added by John Abbott over 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Anna Maria Bigatti
Category:
External Libs
Target version:
CoCoA-5.3.0
Start date:
09 Sep 2018
Due date:
% Done:

100%

Estimated time:
Spent time:
1.40 h

Description

In my personal working version of CoCoA-5.2.5 the command ExternalLibs() returns an empty list even though VersionInfo reports that GMP and Frobby are present. Moreover configure --again reports that GSL and READLINE were also present.

History

#1 Updated by Anna Maria Bigatti over 5 years ago

fixed
(using new output of VersionInfo)

#2 Updated by John Abbott about 5 years ago

  • Status changed from New to Feedback
  • Assignee set to Anna Maria Bigatti
  • % Done changed from 0 to 90

Can we make the function return also the versions of the external libraries as in VersionInfo?
Is it worth doing this?

#3 Updated by John Abbott about 5 years ago

  • Description updated (diff)

#4 Updated by Anna Maria Bigatti about 5 years ago

Currently it is implemented as

define ExternalLibs()
  return [ L.name | L in VersionInfo().ExternalLibs];
enddefine

we could change it into
  return VersionInfo().ExternalLibs;

but then the output is unreadable.
So (obviously I had thought about this, even if I can't remember!) I had written this in the manual. Maybe I should explain better?

#5 Updated by John Abbott about 5 years ago

I am now inclined to change my mind about my comment 2 above. As Anna says, the info is directly available from VersionInfo(), and even the manual page shows this clearly.

On my computer READLINE does not appear even though CoCoAInterpreter has been compiled with READLINE; this is probably because READLINE is handled in a different way? I suppose we should fix this... :-/ (And then close?)

Also GSL is not reported as being present...

#6 Updated by Anna Maria Bigatti about 5 years ago

John Abbott wrote:

On my computer READLINE does not appear even though CoCoAInterpreter has been compiled with READLINE; this is probably because READLINE is handled in a different way? I suppose we should fix this... :-/ (And then close?)

are you sure you have READLINE?
It is no longer in the default compilation.

#7 Updated by John Abbott about 5 years ago

Yes, I definitely have READLINE -- it works!

It is true that READLINE is included in the interpreter, and not in CoCoALib; so it is probably OK to omit it from ExternalLibs.

However, as I added in my previous comment, GSL is present in my CoCoALib (and in autoconf.mk), but is not listed by ExternalLibs.

#8 Updated by John Abbott over 4 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 90 to 100

This has been in feedback for at least 7 months. I cannot quickly and easily check whether the GSL problem still persists. Closing.

Also available in: Atom PDF