Re: Error on us-east.manta.joyent.com in install stage of uCON64.

[Daniël Hörchner <dbjh%gmx.net@localhost>]

Hi,
 
I have solved the issue by applying the work-around with help from Nia Alarie.
 
I tried to understand what the actual problem was and my conclusion is that it is a combination of a bug and at least an unnecessary restriction imposed by pkgsrc, which would encourage authors to jump through hoops just to pass the test. Let me explain.
 
The first error message appears to originate from line 98 of the script check-shlibs-macho.awk (http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/mk/check/check-shlibs-macho.awk?annotate=1.9). So, the first element of "needed" did not start with a slash.
 
Contrary to some people's claims, the shared library identification name of a dynamic shared library is not the absolute path of the library, is not required by the system to be the absolute path and can be any string accepted by "install_name_tool -id". In the case of libdiscmage it comes from a typical Makefile rule to produce the binary:

 
$(FULLLIBNAME): $(OBJECTS)
    $(CC) $^ $(LDFLAGS) -o $@
 
In other words, whatever is specified by -o. Note that if $(FULLLIBNAME) does not include an absolute path -o also does not specify one, although it could. More importantly, during typical development it is undesirable or even problematic to specify the final absolute path. One way to address this is to run "install_name_tool -id" afterwards and just fill out whatever pkgsrc demands, say "/discmage.dylib" (to satisfy just the requirement of the first character being a slash, but pkgsrc has more requirements, see below).
 
The second error message appears to originate from line 118 of check-shlibs-macho.awk and assuming my reasoning is correct, is just wrong, for 2 reasons:
1. The first line output by otool -L (objdump -macho -dylibs-used) *in case of a shared library input* is *not* a dependent shared library, but the shared library identification name. The comment starting on line 100 appears to confirm this oversight. So, check-shlibs-macho.awk should at least skip the first element *for shared libraries* (only).
2. The first time a library is about to be installed it cannot be found at its future location.
 
Addressing the second reason could require quite some work (which will involve modifying binaries with "install_name_tool -change") if pkgsrc is to keep this behavior.
 
I hope someone will find this information useful.
 
Kind regards,
Daniël

 

Gesendet: Freitag, 07. Mai 2021 um 02:29 Uhr
Von: "Daniël Hörchner" <dbjh%gmx.net@localhost>
An: pkgsrc-users%NetBSD.org@localhost
Betreff: Error on us-east.manta.joyent.com in install stage of uCON64.

Hi,
 

I am the maintainer of uCON64. I noticed there is a new issue with the Darwin builds of ucon64-2.2.1nb2 at the install step on us-east.manta.joyent.com. For example, in the log of Darwin 20.3.0/x86_64, https://us-east.manta.joyent.com/pkgsrc/public/reports/Darwin/11.0/trunk/x86_64/20210309.1046//ucon64-2.2.1nb2/install.log:
ERROR: lib/discmage.dylib: relative library path: discmage.dylib
ERROR: lib/discmage.dylib: missing library: discmage.dylib
 
The error messages are too cryptic to me (discmage.dylib is created successfully during the build step in the subdirectory libdiscmage). Could someone have a look, please? Or perhaps explain what I can do myself to solve this? The code builds fine on a MacBook running macOS Big Sur (outside the pkgsrc environment).
 
My workaround would be to *not* specify the configure option --with-libdiscmage, in order to avoid building discmage.dylib entirely, but that would require some additional changes in the build configuration of ucon64-2.2.1nb2. In other words, outside my control.
 
Thanks in advance.
 

Kind regards,
Daniël