Re: [Bug-apl] Cannot find libemacs on older mac

[Juergen Sauermann]

  
  
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.dylib
  )
  
  So GNU APL was able to open the file (using dlopen()) but
  then gets the "flat namespace" error at some point.
  
  The second link below says:


   
  amandogra  commented on Oct 2, 2016 


  

  

  It got solved by OS upgrade.
For someone who comes to this...
I was on Mac OSX El Capitan, but I upgraded to macOS
Sierra.
Then, I executed the following command
  brew unlink libevent && brew link libevent

  This fixed my issue.

  

  


  The posting was related to a different library but the (rest of
  the) error message looks very similar (considering
  that GNU APL cuts off the start the error message text until the
  last : in it). The full error message was most likely:
Expected in: flat namespace
Maybe "nm -D" on
  the dylib file reveals some more information.
  
  Best Regards,
  /// Jürgen
  
  
  
On 12/04/2017 04:06 AM, Elias Mårtenson
  wrote:


  Perhaps adding the path to the dylib file in
DYLIB_LIBRARY_PATH will help? Don't forget to exprt the variable
before starting apl.


Regards,
Elias
  
  
On 4 December 2017 at 01:56, Juergen
  Sauermann 
  wrote:
  
 Hi,

I haven't changed anything in that area. One poster in
one of the links below mentioned that an OS-X upgrade
had fixed a similar problem that the poster had, so my
impression is that this is a problem than cannot be
fixed
inside GNU APL.
  
  Best Regards,
  /// Jürgen
  

  
  
  On
12/03/2017 12:02 PM, Elias Mårtenson wrote:
  
  
10.6.8 is indeed very old. I thought
  my Macbook was old and it's running 10.10.
  
  
  I have to admit that I haven't tried the
Emacs mode on OSX in a while since I don't use
Macs anymore. That said, last time I did try, it
worked fine.
  
  
  Jürgen, could there be an issue with the way
the libraries are built? Did anything change in
the last couple of years?
  
  
  Regards,
  Elias


  On 3 December 2017 at
18:58, Juergen Sauermann 
wrote:

   Hi
  Alexey,
  
  I am not really familiar with emacs or OS
  X, so Elias is probably better informed
  than me.
  
  Unfotunately shared libraries are rather
  platform dependent and so are the error
  messages that
  they produce. From the output below it
  seems that the file libemacs.dylib
  exists and was found,
  but could not be opened with dlopen().
  It might be that your platform needs
  additional linker flags
  for dynamic libraries to work, but I have
  no idea which ones.

See
also:

  https://github.com/tmux/tmux/issues/547
  or
  
  https://developer.apple.com/library/content/documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html
  
  Best Regards,
  /// Jürgen
  
 

[Bug-apl] [Reproducible builds] add support for SOURCE_DATE_EPOCH

[Santiago Torres-Arias]

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
(or stripped out whatsoever).

I'm attaching a patch on how I believe this could be achieved.

Thanks!
-Santiago.


signature.asc
Description: PGP signature

Re: [Bug-apl] [Reproducible builds] add support for SOURCE_DATE_EPOCH

[Christian Robert]

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 header file.
It would be nice if this could be overriden with an environment variable
(or stripped out whatsoever).

I'm attaching a patch on how I believe this could be achieved.

Thanks!
-Santiago.

Re: [Bug-apl] [Reproducible builds] add support for SOURCE_DATE_EPOCH

[Santiago Torres-Arias]

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'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
> > (or stripped out whatsoever).
> > 
> > I'm attaching a patch on how I believe this could be achieved.
> > 
> > Thanks!
> > -Santiago.
> > 
--- apl-1.7/src/buildtag2017-03-17 10:46:53.0 -0400
+++ apl-1.7.new/src/buildtag2017-11-30 11:53:00.173223737 -0500
@@ -15,8 +15,15 @@ if [ -x ./config.status ]
 then
 CONFIGURE_OPTS=`../config.status -V | grep "with options" | sed 
's/[^"]*//'`
 fi
-BUILD_DATE=`date -u "+%F %R:%S %Z"`
-BUILD_OS=`uname -s -r -m`
+
+if [ -n "$SOURCE_DATE_EPOCH" ]
+then
+BUILD_DATE=`date -u "%F %R:%S %Z" --date=@$SOURDCE_DATE_EPOCH`
+BUILD_OS=""
+else
+BUILD_DATE=`date -u "+%F %R:%S %Z"`
+BUILD_OS=`uname -s -r -m`
+fi
 BUILD_TAG="\" / $SVNINFO\", \"$BUILD_DATE\", \"$BUILD_OS\", 
\"$CONFIGURE_OPTS\""
 
 # write buildtag.hh


signature.asc
Description: PGP signature

[Bug-apl] I'm curious about how will react APL compiled with ...

[Christian Robert]

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.

Re: [Bug-apl] I'm curious about how will react APL compiled with ...

[Elias Mårtenson]

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 as to what dependencies the Arch (and
other distributions) versions GNU APL use? It's possible that if I install
it from the repository I don't get Postgres support for example.

Regards,
Elias

On 5 December 2017 at 13:44, Christian Robert 
wrote:

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