[Bug 269048] textproc/libucl: build fails if devel/uthash is installed (also textproc/py-ucl)

From: <bugzilla-noreply_at_freebsd.org>
Date: Thu, 19 Jan 2023 09:15:41 UTC

            Bug ID: 269048
           Summary: textproc/libucl: build fails if devel/uthash is
                    installed (also textproc/py-ucl)
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Individual Port(s)
          Assignee: ports-bugs@FreeBSD.org
          Reporter: jcfyecrayz@liamekaens.com
                CC: bofh@freebsd.org, zi@FreeBSD.org
                CC: bofh@freebsd.org, zi@FreeBSD.org

Created attachment 239584
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239584&action=edit
[patch] fix build if devel/uthash installed; unbreak SIGNATURES; use libfetch
instead of libcurl, etc.

textproc/libucl has a compile error if devel/uthash is installed:

libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -I../uthash
-I../src -I../include -I../uthash -I../klib -Wall -W -Wno-unused-parameter
-Wno-pointer-sign -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -MT
libucl_la-ucl_emitter_utils.lo -MD -MP -MF
.deps/libucl_la-ucl_emitter_utils.Tpo -c ucl_emitter_utils.c  -fPIC -DPIC -o
ucl_emitter_utils.c:222:3: warning: implicit declaration of function
'utstring_append_c' is invalid in C99 [-Wimplicit-function-declaration]
                utstring_append_c (buf, c);
ucl_emitter_utils.c:239:2: warning: implicit declaration of function
'utstring_append_len' is invalid in C99 [-Wimplicit-function-declaration]
        utstring_append_len (buf, str, len);
ucl_emitter_utils.c:419:6: error: no member named 'pd' in 'UT_string'
                s->pd = pmem;
                ~  ^

This is because devel/uthash is 2.3.0 and the uthash that is bundled with
libucl is 1.9.8. There is an API difference between and libucl source code is
written for the latter version.

Also, textproc/py-ucl fails as well if devel/uthash is installed - in a
different spot:

cc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -O2 -pipe
-fstack-protector-strong -fno-strict-aliasing -O2 -pipe -I/usr/local/include
-fstack-protector-strong -fno-strict-aliasing -fPIC -DCURL_FOUND=1 -Iinclude
-Isrc -Iuthash -Iklib -c src/ucl_schema.c -o
src/ucl_schema.c:387:46: error: expected ')'
                                                "string is too big: %u, maximum
is: %" PRId64,
src/ucl_schema.c:398:48: error: expected ')'
                                                "string is too short: %u,
minimum is: %" PRId64,

See also the upstream bug https://github.com/vstakhov/libucl/issues/266 (now

A difference between 2.3.0 and 1.9.8 contributes to that problem as well
(described in the upstream bug).

Attached is a patch that ensures that the bundled uthash header-only source
code - against which the current libucl was written - is used instead of uthash
that may be installed to ${LOCALBASE}.

While here:

 - textproc/py-ucl: fix "second build" failure (see upstream

 - Remove version restriction for USES=python in py-ucl - this python module
works with any version of python.

 - Replace curl dependency in py-ucl with libfetch. Not only does this reduce
dependencies, but it also matches how libucl.so is built.

 - SIGNATURES option has not been broken for a long time now. Fixed upstream in
2020. Included in 0.8.2 release. Builds fine in poudriere or out.

 - Minor rearrangement of some sections based on portclippy suggested ordering.

 - poudriere testport (ok: libucl with default options and with LUA,
SIGNATURES, URLS on; ok: py-ucl)
 - portlint & portclippy (ok - fewer "problems" reported)

PORTREVISION bump is not necessary since this is a build fix for environments
that may not be building.  If the SIGNATURES option is changed to be on by
default (maybe a good idea now that it is no longer broken, but not included in
the attached patch), that would require a PORTREVISION bump.

You are receiving this mail because:
You are the assignee for the bug.