On Sun, Sep 03 2023, Jonathan Schleifer <js-openbsd-po...@nil.im> wrote:
> This would be small enough if the package still built. Moving
>> SHARED_LIBS to 0.0 I get:
>>
>> Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfw.so.0.0 does
>> not exist
>> Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfwrt.so.0.0
>> does not exist
>> Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfwtls.so.0.0
>> does not exist
>
> Ah, so the problem here was different definitions of soname. For me, the
> .0.0 is part of the soname, so it is indeed part of the soname after all
> (if going by my definition).
Not sure we have the same definition indeed. objfw indeed seems to
use -Wl,-soname but not on OpenBSD (which is fine), so the resulting
library doesn't have a DT_SONAME dynamic tag and the versioning
information available to ld.so(8) only comes from the major.minor
version encoded in the library file name.
>> at make package time. This is what Stuart meant when he said that the
>> port should be in control: SHARED_LIBS should decide the version used to
>> build and install the shared libraries.
>
> So in plain English: OpenBSD wants to ignore upstream library version /
> soname versions and always use its own. Got it.
Basically, yes.
>> For automake or cmake ports this
>> is usually handled transparently by the ports infrastructure, which sets
>> various values in the build environment. Here you don't seem to use
>> automake so you're probably going to need patches + ${SUBST_CMD} to inject
>> LIBobjfw_VERSION etc at the right spot.
>
> Ah, perfect, this can just be overridden using MAKE_FLAGS. Done.
Thanks. See the attached port for a more
>> Regarding the port, I see two nits:
>> - Portable -> portable in COMMENT
> Done
>> - maybe include your full name in MAINTAINER
> Done
>> - .SILENT doesn't help understanding what is going on
> The non-.SILENT output isn't too useful either, as that's just a bunch
> of shellscript then that loops over things.
I don't know which of .SILENT or make -s or the escape characters hide
the compiler command lines used to build the object files, but let's
find a way to disable this behaviour at least in the port. We need to
see the programs and flags involved, if only to verify that said flags
are sane in the context of the ports tree.
>> and I wonder about two things:
>> - COMPILER + COMPILER_LANGS: is COMPILER_LANGS actually useful here?
> You mean because Clang is guaranteed to support ObjC?
Yup. Also the ports infrastructure doesn't seem to do much with
COMPILER_LANGS=objc.
>> - is this framework already used by other applications in the wild?
> I'm at least fairly certain not by anything else in OpenBSD ports ;).
>> Could it be used as a building block for other ports?
> Define building blocks.
Like being used as an alternative for other objc frameworks and as
a runtime for objc applications. Admittedly that's not an ecosystem
I know much about.
> Like a Makefile template for other ports?
> I don't think so, it's just a regular library, users of the library can
> use whatever build system they want.
>> Do we have to
>> care about some existing ports automatically picking it up?
> I don't think so, no.
>> That's a lot of questions, sorry :)
>
> No worries, I hope I addressed everything with the new tarball I attached.
Thanks. Updated tarball attached which simplifies SHARED_LIBS handling
and zaps COMPILER_LANGS=objc. Could you please tweak/patch the port so
that compiler/linker commands are printed?
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
