On Tue, Jan 25, 2022 at 02:53:48PM +0000, Stuart Henderson wrote: > Ports using cmake.port.mk usually need some help to get shared libraries > built correctly with the version suffix, if a build is run without any > SHARED_LIBS entries for a library (as is the case for a new port, or an > existing port which adds a new library) the file is usually named > libXXX.so rather than libXXX.so.0.0. > > I've seen a few submissions where the porter tried to patch cmake files > for this which isn't usually the right approach, in most cases adding > to SHARED_LIBS is enough. So I'd like to mention it in the > specialtopics.html section (unless someone has an idea of how to fix > this in the module; it did used to work as expected..)
I think you can extend this to meson as well. If you don't set SHARED_LIBS, meson will create so.X.Y.X libs (set by upstream; linux like sonaming). And as with cmake you will need to set SHARED_LIBS and build the port again to get proper libfoo.so.X.Y naming. > Index: specialtopics.html > =================================================================== > RCS file: /cvs/www/faq/ports/specialtopics.html,v > retrieving revision 1.86 > diff -u -p -r1.86 specialtopics.html > --- specialtopics.html 26 Nov 2021 00:40:15 -0000 1.86 > +++ specialtopics.html 25 Jan 2022 14:49:26 -0000 > @@ -142,6 +142,13 @@ Shared library building is logged in <co > which can be directly included in the port's <code>Makefile</code>. > </ul> > > +For CMake, the initial build will often produce libraries without a > +version number (<code>lib/libXXX.so</code> files). > +In that case, add <code>SHARED_LIBS</code> lines to the Makefile for > +those libraries set to version 0.0, clean and rebuild the port, > +and when you regenerate the PLIST you should see that it starts to > +use the version numbers. > + > <h3>Avoid DT_SONAME hardcoding</h3> > > Some ports use the <code>-soname</code> flag of > -- Antoine
