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
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
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 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 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.
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
