Re: specialtopics.html: cmake ports and SHARED_LIBS
On Tue, Jan 25, 2022 at 02:53:48PM +, 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.html26 Nov 2021 00:40:15 - 1.86 > +++ specialtopics.html25 Jan 2022 14:49:26 - > @@ -142,6 +142,13 @@ Shared library building is logged in which can be directly included in the port's Makefile. > > > +For CMake, the initial build will often produce libraries without a > +version number (lib/libXXX.so files). > +In that case, add SHARED_LIBS 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. > + > Avoid DT_SONAME hardcoding > > Some ports use the -soname flag of > -- Antoine
Re: specialtopics.html: cmake ports and SHARED_LIBS
On Tue, Jan 25, 2022 at 02:53:48PM +, 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..) > > Index: specialtopics.html > === > RCS file: /cvs/www/faq/ports/specialtopics.html,v > retrieving revision 1.86 > diff -u -p -r1.86 specialtopics.html > --- specialtopics.html26 Nov 2021 00:40:15 - 1.86 > +++ specialtopics.html25 Jan 2022 14:49:26 - > @@ -142,6 +142,13 @@ Shared library building is logged in which can be directly included in the port's Makefile. > > > +For CMake, the initial build will often produce libraries without a > +version number (lib/libXXX.so files). > +In that case, add SHARED_LIBS 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. > + > Avoid DT_SONAME hardcoding > > Some ports use the -soname flag of > > There are a lot of special tricks needed to cope with cmake. I believe this will require its own page eventually :(
Re: specialtopics.html: cmake ports and SHARED_LIBS
On Tue, Jan 25, 2022 at 02:53:48PM +, 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..) This is an excellent addition. ok kmos --Kurt > Index: specialtopics.html > === > RCS file: /cvs/www/faq/ports/specialtopics.html,v > retrieving revision 1.86 > diff -u -p -r1.86 specialtopics.html > --- specialtopics.html26 Nov 2021 00:40:15 - 1.86 > +++ specialtopics.html25 Jan 2022 14:49:26 - > @@ -142,6 +142,13 @@ Shared library building is logged in which can be directly included in the port's Makefile. > > > +For CMake, the initial build will often produce libraries without a > +version number (lib/libXXX.so files). > +In that case, add SHARED_LIBS 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. > + > Avoid DT_SONAME hardcoding > > Some ports use the -soname flag of >
Re: specialtopics.html: cmake ports and SHARED_LIBS
On Tue, Jan 25, 2022 at 02:53:48PM +, 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..) > > Index: specialtopics.html > === > RCS file: /cvs/www/faq/ports/specialtopics.html,v > retrieving revision 1.86 > diff -u -p -r1.86 specialtopics.html > --- specialtopics.html26 Nov 2021 00:40:15 - 1.86 > +++ specialtopics.html25 Jan 2022 14:49:26 - > @@ -142,6 +142,13 @@ Shared library building is logged in which can be directly included in the port's Makefile. > > > +For CMake, the initial build will often produce libraries without a > +version number (lib/libXXX.so files). > +In that case, add SHARED_LIBS 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. > + > Avoid DT_SONAME hardcoding > > Some ports use the -soname flag of > This is a good idea. ok tracey This is one topic that takes a long time to learn and get correct. -- Tracey Emery
specialtopics.html: cmake ports and SHARED_LIBS
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..) 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 - 1.86 +++ specialtopics.html 25 Jan 2022 14:49:26 - @@ -142,6 +142,13 @@ Shared library building is logged in Makefile. +For CMake, the initial build will often produce libraries without a +version number (lib/libXXX.so files). +In that case, add SHARED_LIBS 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. + Avoid DT_SONAME hardcoding Some ports use the -soname flag of
