Re: git: 72ad532057c9 - main - archivers/zstd: Add CMake config files and adjust Makefile

On 2023-04-06 23:36, Dima Panov wrote:
> Moin-moin!
> 
> On 06.04.2023 16:32, Alexey Dokuchaev wrote:
>> On Thu, Apr 06, 2023 at 03:19:55PM +0200, Guido Falsi wrote:
>>> On 06/04/23 15:17, Alexey Dokuchaev wrote:
>>>> On Wed, Apr 05, 2023 at 02:20:21PM +0200, Guido Falsi wrote:
>>>>> On 05/04/23 08:15, Daniel Engberg wrote:
>>>>>> commit 72ad532057c9f9fb6fa370c80f663c005e9dd021
>>>>>> 
>>>>>>        archivers/zstd: Add CMake config files and adjust Makefile
>>>>>>               - Use upstream's short test for "make test"
>>>>>>        - Use verbose output by default during build
>>>>>>        * Tweak Makefile to follow Porters Handbook more closely
>>>>>>        * Install CMake files (taken from CMake build framework)
>>>>>>               PR:             267652
>>>>>>        Reported by:    fluffy
>>>>>>        Approved by:    portmgr (maintainer timeout, 1+ month)
>>>>> 
>>>>> Looks like this, un[luckily], causes a failure with devel/qt6-base
>>>>> (abridged error, full log if needed):
>>>>> 
>>>>> ld: error: relocation R_X86_64_32 cannot be used against local 
>>>>> symbol;
>>>>> recompile with -fPIC
>>>>>    >>> defined in /usr/local/lib/libzstd.a(zstd_common.o)
>>>>>    >>> referenced by zstd_common.c
>>>>>    >>>               zstd_common.o:(ZSTD_versionString) in archive
>>>> 
>>>> Yeah, I'm seeing this as well.  Admittedly, the whole commit looks
>>>> dubious to me, with all these out-of-blue new files and gratuitous
>>>> changes.  I guess sunpoet@ should revert it and merge only needed
>>>> parts thereof properly.
> 
> Nope.
> This commit unmasked the real problem of using autocrap tools to build
> zstd -- a broken static library.
> Issue was not raised before 'cause cmake configs was absent and qt6
> (and may be other consumers) hooks up only shared lib.
> 
> Just to be clear -- I have a version of port converted to pure cmake 
> build and
> it produce a valid static library which correctly liked by any 
> consumer.
> 
> Anyway, number of consumers which require cmake'd zstd will grow in 
> near future.
> openimageio/opencolorio/opnehadinglanguage are already require it to 
> push
> new versions to the ports tree.
> 
>>> 
>>> I have only reported the issue as an early warning, as I said.
>>> 
>>> Regarding qt6-base a fix has already been proposed here by diizzy:
>>> 
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270664
>> 
>> Ah, good to know it's being taken care of, thanks for sharing!
> 
> Nope. This patch not fixes anything but masking the real issue with 
> broken
> libzstd.a by prefer dynamic library over static to link.

These are all generated by the CMake build. I'd a bit hesitant moving to 
CMake as that seems to be the one being least "community" maintained 
upstream compared to the other options but that's only my personal 
peception looking at this specific repo. Fwiw Alpine uses Meson (like we 
previously did) and the same approach as we do now but that can be 
expanded to Meson only (https://mesonbuild.com/CMake-module.html). 
Makefile is the "officially" supported way of building libzstd for now 
at least.

Best regards,
Daniel