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