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.
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.
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:
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
This
There's the following in
After modifying the CFLAGS for the build, it at least completes the configure stage for the build, with the updated upstream src.
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:
There's nothing in the upstream src/glib-glue.cc that explains where
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.
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) = ⋔
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 foundIt 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 amd64The 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);
#endifThis
__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
#endifAfter 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=700The 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 1There'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.