Solved GNOME - adding a docs option for vte3 - grantpt not found (??)

Before beginning any more coding with the Ruby bindings for GNOME and Glade on a FreeBSD desktop, I've been working on a couple of unofficial updates for ports, to add docs options to some ports used in GNOME.

With the docs options enabled, some ports might then install documentation in a location accessible to GNOME Devhelp. This could then serve as a reference for use directly in C/C++ or with other bindings (Python, Ruby, ...)

I'd like to send the full set of patches to bugzilla if/after I may be able to figure out the docs build for vte3 (x11-toolkits/vte3). The rest of the patching has been pretty straightforward.

For this particular port I was not able to get the docs to build for the VTE 0.68.0 release. It seemed that something was supposed to be generating some *.XML files from *.gir files but I could not figure out where that was supposed to fit into the docs build.

Looking at the upstream repository (gitlab at GNOME) they've published a changeset that changes how the docs are built [changeset] now using gi-docgen there.

(Update: Figured it out, perhaps grantpt is an X/Open function? CFLAGS listed below)

I would like to test out this new build. After updating the Makefile for this new release at GNOME gitlab plus a docs option, the build fails in a way I cannot figure out. With this only slightly newer release, CC under meson now can't find grantpt in the build (??)

An excerpt from meson-log.txt ... in one instance when I'd tried building with GCC 11 instead of clang from base (it failed then, too)

Some of the compiler messages here are due to CFLAGS I've added locally, to silence compiler warnings and ideally to shorten build times for local port builds.

Code:
Code:
 
    #if __has_include(<sys/types.h>)
    #include <sys/types.h>
    #endif
 
    #if __has_include(<unistd.h>)
    #include <unistd.h>
    #endif
 
    int main(void) {
      pid_t (*func)(void) = &fork;
      long long b = (long long)func;
      return (int)b;
    }
 
Compiler stdout:
 
Compiler stderr:
 
Checking if "fork" compiles: YES
Running compile:
Working directory:  /usr/ports/x11-toolkits/vte3/work/vte-b51feeca889d4b597e95b21bc77dc078892af11d/_build/meson-private/tmp9ih32pm5
Command line:  /usr/local/libexec/ccache/g++11 -I/usr/local/include/glib-2.0 /usr/ports/x11-toolkits/vte3/work/vte-b51feeca889d4b597e95b21bc77dc078892af11d/_build/meson-private/tmp9ih32pm5/testfile.cpp -o /usr/ports/x11-toolkits/vte3/work/vte-b51feeca889d4b597e95b21bc77dc078892af11d/_build/meson-private/tmp9ih32pm5/output.obj -c -O2 -pipe -fstack-protector -Wno-everything -Wno-thread-safety -DGDK_DISABLE_DEPRECATION_WARNINGS -DGLIB_DISABLE_DEPRECATION_WARNINGS -fdebug-prefix-map=/usr/ports/x11-toolkits/vte3/work/vte-b51feeca889d4b597e95b21bc77dc078892af11d=/usr/ports/x11-toolkits/vte3/work/vte-b51feeca889d4b597e95b21bc77dc078892af11d -Wno-everything -Wno-thread-safety -fno-strict-aliasing -Wno-deprecated-declarations -Wno-deprecated-declarations -Wno-unused-command-line-argument -D_FILE_OFFSET_BITS=64 -O0 -fpermissive -D_GNU_SOURCE -D_POSIX_C_SOURCE=200809L

Code:
 
    #if __has_include(<stdlib.h>)
    #include <stdlib.h>
    #endif
 
    int main(void) {
      int (*func)(int) = &grantpt;
      long long b = (long long)func;
      return (int)b;
    }
 
Compiler stdout:
 
Compiler stderr:
 /usr/ports/x11-toolkits/vte3/work/vte-b51feeca889d4b597e95b21bc77dc078892af11d/_build/meson-private/tmp9ih32pm5/testfile.cpp: In function 'int main()':
/usr/ports/x11-toolkits/vte3/work/vte-b51feeca889d4b597e95b21bc77dc078892af11d/_build/meson-private/tmp9ih32pm5/testfile.cpp:7:27: error: 'grantpt' was not declared in this scope
    7 |       int (*func)(int) = &grantpt;
      |                           ^~~~~~~
At global scope:
cc1plus: note: unrecognized command-line option '-Wno-unused-command-line-argument' may have been intended to silence earlier diagnostics
cc1plus: note: unrecognized command-line option '-Wno-thread-safety' may have been intended to silence earlier diagnostics
cc1plus: note: unrecognized command-line option '-Wno-everything' may have been intended to silence earlier diagnostics
cc1plus: note: unrecognized command-line option '-Wno-thread-safety' may have been intended to silence earlier diagnostics
cc1plus: note: unrecognized command-line option '-Wno-everything' may have been intended to silence earlier diagnostics

Checking if "grantpt" compiles: NO

meson.build:397:4: ERROR: Assert failed: grantpt not found

It was failing similarly with clang++

How can it not have found grantpt?

... or is this anything to do with the fact that the meson build is calling a C++ compiler there, while the code looks more like plain C?

If I can figure out how to fix what's failing in the build here, hopefully the newer distsrc might build OK for docs.

With a design for an IDE using the Ruby GNOME bindings that needs VTE bindings, I'd like to be able to get these docs to build on FreeBSD LOL

Ideally, I'd like to consider adding a @gtk4 flavor to the VTE port, but there's this docs things first.

Here's my work-in-progress makefile under x11-toolkits/vte3.

Code:
# Created by: Joe Marcus Clarke <marcus@FreeBSD.org>

PORTNAME=    vte
PORTVERSION=    0.68.0
PORTREVISION=    1
CATEGORIES=    x11-toolkits gnome
MASTER_SITES=    GL
PKGNAMESUFFIX=    3
DIST_SUBDIR=    gnome

MAINTAINER=    gnome@FreeBSD.org
COMMENT=    Terminal widget with improved accessibility and I18N support

LICENSE=    LGPL21

BUILD_DEPENDS=    vapigen:lang/vala \
        bash:shells/bash
LIB_DEPENDS=    libgnutls.so:security/gnutls \
        libfribidi.so:converters/fribidi \
        libpcre2-8.so:devel/pcre2 \
        libicuuc.so:devel/icu

PORTSCOUT=    limitw:1,even

USES=        compiler:c++11-lang gettext gnome localbase meson \
        pkgconfig python:3.6+ tar:xz
USE_LDCONFIG=    yes
USE_GNOME=    cairo gdkpixbuf2 gtk30 introspection:build

USE_GITLAB=    yes
GL_SITE=    https://gitlab.gnome.org
GL_ACCOUNT=    GNOME
GL_PROJECT=    vte
GL_COMMIT=    b51feeca889d4b597e95b21bc77dc078892af11d

MESON_ARGS=    -Da11y=true \
        -Dgir=true \
        -Dfribidi=true \
        -Dgtk3=true \
        -Dgtk4=false \
        -Dicu=true \
        -D_systemd=false \
        -Dvapi=true

PLIST_SUB=    VERSION=2.91

BINARY_ALIAS=    python3=${PYTHON_CMD}

OPTIONS_DEFINE=        DOCS
DOCS_MESON_TRUE=    docs
DOCS_BUILD_DEPENDS=    gtkdoc-mkhtml:textproc/gtk-doc gmake:devel/gmake glib>=2:devel/glib20
#DOCS_VARS=        MAKE_CMD=gmake # for sub-make under docs build (TBD)
DOCS_VARS=        CPPFLAGS+=-I${LOCALBASE}/include/glib-2.0 \
            USE_GNOME+=glib20

.include <bsd.port.pre.mk>

.if ${CHOSEN_COMPILER_TYPE} == clang && ${OPSYS} == FreeBSD && ${OSVERSION} < 1300109
CPP=        ${LOCALBASE}/bin/clang-cpp${_LLVM_VERSION}
CC=        ${LOCALBASE}/bin/clang${_LLVM_VERSION}
CXX=        ${LOCALBASE}/bin/clang++${_LLVM_VERSION}
BUILD_DEPENDS+=    llvm${_LLVM_VERSION}>=0:devel/llvm${_LLVM_VERSION}
.if (${LLVM_DEFAULT} == 90 || ${LLVM_DEFAULT} == 10)
_LLVM_VERSION=    11
.else
_LLVM_VERSION=    ${LLVM_DEFAULT}
.endif
.endif

## needed for part of the docs build on 0.68.0. File does not exist in newer src
# post-patch-DOCS-on:
# .if ${CHOSEN_COMPILER_TYPE} == clang
#     ${REINPLACE_CMD} 's@-fpreprocessed@@' ${WRKSRC}/doc/reference/Makefile.docs
# .endif


.include <bsd.port.post.mk>

Much of the options hacking was from when I was trying to build the docs for the 0.68.0 release. With the newer release from GitHub, not even the main src will build right now. I'm certain there must be something really trivial I'm missing, in it.

After taking a look at this again, I'm going to try patching the check_functions Meson call in the newer distsrc, to use the C compiler instead of the C++ compiler for that part, maybe it's a workaround.

... it's not though. That patch was simple. It fails similarly with clang, clang++, or g++11 for that compiler test. It can't find grantpt?

In some efforts to diagnose the build failure here with the updated src and under the main 0.68.0 vte release:

I've already tried adding -I/usr/include to CFLAGS and alternately -I/usr/include/c++/v1 in CXXFLAGS, as it seems it needs an stdlib.h there. The build still failed, of course.

After checking to see that the VTE docs are available in Devhelp in my local openSUSE installation with -dev packages installed (openSUSE running with EFI on Bhyve) I've looked at the RPM spec file for the VTE build in openSUSE [OBS]. They're using a straightforward build there. Similar to the FreeBSD port build, the openSUSE vte build is also using Meson, with the compiler toolchain under the openSUSE Linux environment.

I'm stumped as to how this port build can be failing on FreeBSD now, with the updated code from the upstream project.

Maybe if I run the compiler test under truss, it would show what files it's trying to access.

The build is being tested on:
Code:
FreeBSD sol.cloud.thinkum.space 13.1-STABLE FreeBSD 13.1-STABLE #0 build/stable/13-2430388070f: Thu May 19 03:49:21 PDT 2022     gimbal@riparian.cloud.thinkum.space:/usr/obj/riparian_FreeBSD-13.1-STABLE_amd64/usr/src/amd64.amd64/sys/RIPARIAN amd64

The build/stable/13 branch there is a local git branch deriving from stable/13. The head changeset has an abbreviated sha1 hash 2430388070f.

After grepping under /usr/include for where grantpt is defined here, I'm seeing the following in /usr/include/stdlib.h

Code:
#if __XSI_VISIBLE
int      grantpt(int);
int      posix_openpt(int);
char    *ptsname(int);
int      unlockpt(int);
#endif /* __XSI_VISIBLE */
#if __BSD_VISIBLE
/* ptsname_r will be included in POSIX issue 8 */
int      ptsname_r(int, char *, size_t);
#endif

This __XSI_VISIBLE preprocessor symbol, it's probably related to some other feature set?

There's the following in /usr/include/sys/cdefs.h

Code:
/* Deal with various X/Open Portability Guides and Single UNIX Spec. */
#ifdef _XOPEN_SOURCE
#if _XOPEN_SOURCE - 0 >= 700
#define __XSI_VISIBLE           700
#undef _POSIX_C_SOURCE
#define _POSIX_C_SOURCE         200809
#elif _XOPEN_SOURCE - 0 >= 600
#define __XSI_VISIBLE           600
#undef _POSIX_C_SOURCE
#define _POSIX_C_SOURCE         200112
#elif _XOPEN_SOURCE - 0 >= 500
#define __XSI_VISIBLE           500
#undef _POSIX_C_SOURCE
#define _POSIX_C_SOURCE         199506
#endif
#endif

After modifying the CFLAGS for the build, it at least completes the configure stage for the build, with the updated upstream src.

Code:
CFLAGS+=        -D_XOPEN_SOURCE=700

The build then fails in some new interesting part of the src, but this seems to be possibly unrelated to the concern of the portability of openpt:

Code:
/usr/local/libexec/ccache/clang++ -Isrc/libvte-2.91.so.0.6900.0.p -Isrc -I../src -I. -I.. -Isrc/vte -I../src/vte -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/i\
nclude -I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/freetype2 -I/usr/local/include/fribidi -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr\
/local/include/libpng16 -I/usr/local/include/p11-kit-1 -I/usr/local/include/gtk-3.0 -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/gio-unix-2.0 -I/usr/local/include/libepoll-shim -I\
/usr/local/include/atk-1.0 -I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include -I/usr/local/include/at-spi-2.0 -fno-color-diagnostics -D_FILE_\
OFFSET_BITS=64 -O3 -std=gnu++20 -Wall -Wextra -Wcast-align -Wcast-function-type -Wempty-body -Wendif-labels -Werror=init-self -Werror=missing-include-dirs -Werror=pointer-arith -Wfloat-equal \
-Wignored-qualifiers -Winvalid-pch -Wmisleading-indentation -Wmissing-declarations -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-include-dirs -Wmissing-noreturn -Wno-addre\
ss-of-packed-member -Wno-c99-designator -Wno-missing-field-initializers -Wno-packed -Wno-switch-enum -Wno-unused-parameter -Wshadow -Wshift-negative-value -Wsign-compare -Wstrict-aliasing=2 -\
Wtype-limits -Wundef -Wuninitialized -Wuninitialized -Wunused -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function -Wunused-label -Wunused-local-typedefs -Wunused-value -Wun\
used-variable -Wvla -Wwrite-strings -fdiagnostics-show-option -fno-common -fno-semantic-interposition -fno-strict-aliasing -Wnon-virtual-dtor -Wno-unknown-attributes -fvisibility-inlines-hidd\
en -fvisibility=hidden -Werror=format=2 -Werror=format-nonliteral -Werror=format-security -O2 -pipe -D_XOPEN_SOURCE=700 -fstack-protector -Wno-everything -Wno-thread-safety -DGDK_DISABLE_DEPR\
ECATION_WARNINGS -DGLIB_DISABLE_DEPRECATION_WARNINGS -fdebug-prefix-map=/usr/ports/x11-toolkits/vte3/work/vte-b51feeca889d4b597e95b21bc77dc078892af11d=/usr/ports/x11-toolkits/vte3/work/vte-b5\
1feeca889d4b597e95b21bc77dc078892af11d -Wno-everything -Wno-thread-safety -isystem /usr/local/include -fno-strict-aliasing -Wno-deprecated-declarations -Wno-mismatched-tags -Wno-deprecated-de\
clarations -Wno-mismatched-tags -isystem /usr/local/include -Wno-unused-command-line-argument -isystem /usr/local/include -fPIC -pthread -D_THREAD_SAFE '-DG_LOG_DOMAIN="VTE"' '-DLOCALEDIR="/u\
sr/local/share/locale"' -DVTE_COMPILATION -UPARSER_INCLUDE_NOP '-DGDK_VERSION_MIN_REQUIRED=(G_ENCODE_VERSION(3,18))' '-DGDK_VERSION_MAX_ALLOWED=(G_ENCODE_VERSION(3,20))' -DVTE_GTK=3 -MD -MQ s\
rc/libvte-2.91.so.0.6900.0.p/glib-glue.cc.o -MF src/libvte-2.91.so.0.6900.0.p/glib-glue.cc.o.d -o src/libvte-2.91.so.0.6900.0.p/glib-glue.cc.o -c ../src/glib-glue.cc                   
../src/glib-glue.cc:43:29: error: no matching literal operator for call to 'operator""sv' with arguments of types 'const char *' and 'unsigned long', and no matching literal operator template
                what += ": "sv;                                                                                                                                                         
;                            ^                                                                                                                                                          
../src/glib-glue.cc:44:14: error: no viable overloaded '+='                                                                                                                             
        what += e.what();                                                                                                                                                               
        ~~~~ ^  ~~~~~~~~                                                                                                                                                                
../src/glib-glue.cc:44:14: note: type 'std::string' (aka 'basic_string<char, char_traits<char>, allocator<char>>') is incomplete                                                        
        what += e.what();                                                                                                                                                               
        ~~~~ ^  ~~~~~~~~                                                                                                                                                                
../src/glib-glue.cc:49:57: error: implicit instantiation of undefined template 'std::basic_string<char>'                                                                                
                g_error("Allocation failure: %s\n", what.c_str());                                                                                                                      
                                                        ^                                                                                                                               
/usr/include/c++/v1/iosfwd:242:32: note: template is declared here                                                                                                                      
    class _LIBCPP_TEMPLATE_VIS basic_string;

../src/glib-glue.cc:141:43: error: no matching literal operator for call to 'operator""sv' with arguments of types 'const char *' and 'unsigned long', and no matching literal operator templat\
e                                                                                                                                                                                       
                what = "Unknown exception"sv;                                                                                                                                           
                                          ^                                                                                                                                             
6 errors generated.                                                                                                                                                                     
ninja: build stopped: subcommand failed.                                                                                                                                                
*** Error code 1                                                                                                                                                                        
                                                                                                                                                                                        
Stop.                                                                                                                                                                                   
make[2]: stopped in /usr/ports/x11-toolkits/vte3                                                                                                                                        
*** Error code 1

There's nothing in the upstream src/glib-glue.cc that explains where sv is assumed to have been defined.

The 'sv' string shows up in src/systemd.cc ... under g_variant_builder_open. Maybe it's not been defined, as the build here is certainly under `-D_systemd=false`

Of course, the topic is solved now, insofar as for the configure stage of the build. The rest, it seems, would be in patching, or if the patch is too non-trivial, perhaps simply waiting out the next official release of the VTE codebase for that part, and using openSUSE for the Devhelp docs on vte3.

Maybe there's some other terminal widget available in GNOME.
 
Back
Top