I don't think anyone would expect to be able to to move the apl binary to a
system where the correct libraries aren't installed. You can't typically do
that with any programs installed from the package managers. After all,
that's why package dependencies exist.
However, it does raise the question
I am curious about how will react APL compiled with
say the right PCRE and the right FFT library available
when ran on a machine who has neither of thoses lib*.so availble?
will it refuse to start or just "disable" the corrosponding quad-functions ?
Xtian.
Hi,
I wonder if it was stripped out. I also opened a bug with the patch.
I'm trying to re-attach here.
Thanks!
-Santiago.
On Mon, Dec 04, 2017 at 10:33:02PM -0500, Christian Robert wrote:
> I see no patch attached.
>
> Xtian.
>
> On 2017-12-04 17:53, Santiago Torres-Arias wrote:
> > Hi,
> >
I see no patch attached.
Xtian.
On 2017-12-04 17:53, Santiago Torres-Arias wrote:
Hi,
I'm a member of the Arch Linux Security team working on the reproducible
builds initiative. Right now, apl compiles almost reproducibly, with the
only caveat of embedding some time-based information into a he
Hi,
I'm a member of the Arch Linux Security team working on the reproducible
builds initiative. Right now, apl compiles almost reproducibly, with the
only caveat of embedding some time-based information into a header file.
It would be nice if this could be overriden with an environment variable
(o
Hi,
from the GNU APL printout it looks like the file was found, but
something is wrong with the file:
file /Users/alexey/Applications/gnu-apl/lib/apl/libemacs.dylib
( flat namespace
in /Users/alexey/Applications/gnu-apl/lib/apl/libemacs
