Klemens Nanni <k...@openbsd.org> writes:
> On Mon, Dec 20, 2021 at 01:41:15PM +0100, Omar Polo wrote:
>> Stuart Henderson <s...@spacehopper.org> writes:
>>
>> > On 2021/12/20 00:13, Klemens Nanni wrote:
>> >> On Mon, Dec 20, 2021 at 12:05:11AM +0100, Omar Polo wrote:
>> >> > > # C++ devel/gtest
>> >> > > COMPILER = base-clang ports-gcc
>> >> >
>> >> > I'm not sure what that means. At glance I can't really tell the minimum
>> >> > C++ version this needs, but since you've tested on sparc64 (which is
>> >> > a gcc arch IIRC) I assume it doesn't build with base gcc and thus it's
>> >> > at least C++11.
>> >>
>> >> `make build' works on sparc64 with gcc 4.2.1 but `make test' builds
>> >> against the gtest c++ headers and fails, hence the need for a newer
>> >> compiler, but only due to tests.
>> >
>> > Generally all C++ ports have to prefer ports-gcc over base-gcc to avoid
>> > mixing incompatible C++ standard libraries on gcc archs. I don't think
>> > you need to add an extra comment for that, other pprts do not do this
>> > (only when setting COMPILER for non-C++ reasons).
>>
>> I've dropped the comment before COMPILER then
>
> openh264 itself builds with old base-gcc and only the tests need newer
> stuff due to gtest, I figured that's worth a comment.
>
> Not going to bikeshed this, though -- I'll leave it out on import if you
> still think it's just noise.
don't want to bikeshed either, your version is good
>> >> > pkg/PLIST:
>> >> > > @so lib/libopenh264.so
>> >> > > lib/libopenh264.so.0
>> >> > > @lib lib/libopenh264.so.${LIBopenh264_VERSION}
>> >> >
>> >> > that doesn't look right, it should install only the last file. I
>> >> > haven't found an obvious way to avoid that other than patching out a
>> >> > couple of lines from the makefile.
>> >
>> > Oh yes, good catch
>> >
>> >> Yes, most ports ship a single file but we do have ports that contain
>> >> symlinks, so I did not outright reject it.
>> >
>> > The only one I can think of is librubyXX.so and that causes problems.
>> > If there are others they are probably wrong too.
>>
>> thanks for clarifying that
>
> So all the symlinks I see in my /usr/local/lib are actually useful and
> intented, i.e. they point at port specific folders or provide versioned
> names:
>
> ./libQt5Core.so.3.0 -> qt5/libQt5Core.so.3.0
> ./libwmflite.so.7.1 -> libwmflite-0.2.so.7.1
>
> I looked too fast while porting and thought they were like openh264.
>
>> I'm attaching Klemens' tarball with the comment dropped and a
>> patch-Makefile that fixes the plist. I think we addressed all the
>> points now :)
>
> I've just @comment'ed the symlinks in PLIST.
even better
> MASTER_SITES0 is a hardcoded URL now.
>
> Builds and tests on arm64 (raspi 4b) just like on amd64.
> Telegram on arm64 also works in every aspect using this port.
>
>
> Feedback? OK?
OK op@,
Thanks,
Omar Polo
