Re: [Bug-apl] libapl load - a makefile question.

[Juergen Sauermann]

Hi Peter,

I suppose the line

libapl_la_LDFLAGS += -avoid-version

in src/Makefile.am prevents the creation of libapl.0.dylib. I suppose if
you remove that line then libapl.0.dylib will show up.
 
Please note that libapl.0.dylib is simply a symbolic link to libapl.dylib
so one can also easily create it manually if needed.

The reason why I am using -avoid-version is that I would like to avoid
the incorrect impression that I will take care of properly maintaining the library version
numbers of libapl.

There is a difference between people maintaining a particular library (and often shipping
that library in binary form) and libapl which is always built from source and whose version
number comes from svn rather than being stepped up separately. In principle every bugfix in GNU APL
that is committed to svn would then create a new libapl version (-number). Having different libapl
versions on your machine makes little sense, though (unless you need some errors to persist which
I would call bad pactice).

  In other words, I believe that the usual rules for shared library are not applicable to libapl and following
them would create some extra burden on my part which I believe is quite an overkill given the small
number of people using libapl and given that GNU APL as a whole is updated far more often than its
 libapl part.

Regarding Makefile vs. Makefile.in vs. Makefile.am, you should always update Makefile.am because
Makefile.in is automatically created from  Makefile.am (by autoreconf)  and Makefile is automatically
created from  Makefile.in (by configure).

Best regards,
/// Jürgen

On 07/11/2018 11:27 PM, Peter Teeson wrote:

Hi Jürgen: 

Following up an this subject I noticed this:

libapl.a                    libemacs.a
libapl.dylib              libemacs.dylib
                               libemacs.0.dylib
 libapl.la                  libemacs.la

Actually what Elias did for the emacs lib does follow the Apple documentation.
Apple provides a way for dynamic libraries to be improved as well as new capabilities added.
And for the host app to determine to what extent the newer lib will still be usable without problems.

In essence at build time you provide args for the dynamic linker as follows:
-macosx_version_min  version, compatibility_version number, current_version number.

libemacs.0.dylib is an example of embedding the version number in the library name;
In this case the default is 0 (when none is provided).

So where would I look in the emacs makefiles to see where this/these args are provided?
Would I examine makefile.in? or makefile.ac? or what?

I would like to experiment with this a bit.

thanks and respect….

Peter
P.S. libapl API is stable so in a sense it’s academic. But one likes to design for the future….

signature.asc
Description: OpenPGP digital signature