Re: pkg/54500: devel/lua-Bitop broken on macOS patch

[clément bouvier <clement.bouvier.europe%gmail.com@localhost>]

The following reply was made to PR pkg/54500; it has been noted by GNATS.

From: =?utf-8?Q?cl=C3=A9ment_bouvier?= <clement.bouvier.europe%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/54500: devel/lua-Bitop broken on macOS patch
Date: Fri, 30 Aug 2019 20:45:43 +0400

 Hi Alexander,
 
 > clement.bouvier.europe%gmail.com@localhost wrote:
 >> -${LUA_CDIR}/bit.so
 >> +${LUA_CDIR}/bit.la
 >=20
 > We only want bit.so installed because it isn't a library but a Lua
 > module.
 
 I think I don't understand your comment ; maybe something would escape =
 me...
 
 Yes and libtool directive inside the rule to build the module  is =
 building a Lua module (Intrinsically lua use dlopen, dlsym to load a C =
 module, doesn't it?) and not a library.
 
 (-shared -module -void-version -export-dynamic libtool flags)
 ${LIBTOOL} --tag=3DCC --mode=3Dlink $(CC) $(SOLDFLAGS) -o ${@:.so=3D.la} =
 ${<:.o=3D.lo} -rpath ${PREFIX}/${LUA_CDIR} -shared -module =
 -avoid-version -export-dynamic
 
 The binary object is BUNDLE type meaning in apple language (Mach-O =
 specification) a plugin loading at runtime (Sorry for the macos example =
 but I have only that under my hand currently ; but I can check with the =
 ELF format).
 If it was a library shared, the filetype would be DYLIB.
 
 $otool -hv ~/pkg/lib/lua/5.2/bit.so
 Mach header
       magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      =
 flags
 MH_MAGIC_64  X86_64        ALL  0x00      BUNDLE    12       1408   =
 NOUNDEFS DYLDLINK TWOLEVEL
 
 vs (with neettle library)
 
 $otool -hv ~/pkg/lib/libnettle.dylib
 Mach header
       magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      =
 flags
 MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    13       1400   =
 NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS
 
 The pkgsrc developper guide recommends to use *.la in the PLIST if you =
 migrate the package to libtool.
 https://www.netbsd.org/docs/pkgsrc/fixes.html#fixes.configure
 In 21.3.1. Shared libraries - libtool:
 
 4:  When linking shared object (.so) files, i.e. files that are loaded =
 via dlopen(3), NOT shared libraries, use =E2=80=9C-module =
 -avoid-version=E2=80=9D to prevent them getting version tacked on.
      The PLIST file gets the foo.so entry.
 7:  In your PLIST, include only the .la file (this is a change from =
 previous behaviour).
 
 The documentation could be ambiguous ("the PLIST file gets the foo.so =
 entry" and the rule 7).
 Moreover if only *.so is added, then you obtain an error at install:
 
 =3D> Checking file-check results for lua52-BitOp-1.0.2nb1
 ERROR: ************************************************************
 ERROR: The following files are in =
 /Users/cbouvier/prj/pkgsrc/devel/lua-BitOp/work/.destdir/Users/cbouvier/pk=
 g but not in the PLIST:
 ERROR:         =
 /Users/cbouvier/prj/pkgsrc/devel/lua-BitOp/work/.destdir/Users/cbouvier/pk=
 g/lib/lua/5.2/bit.la
 
 Yes pkgsrc is installing a text libtool archive (.la) with the module =
 (plugin) .so but not any static or dynamic library.
 You may know something that I don't know about pkgsrc ; Any pointer if =
 it is the case?
 
 Clement.