[Bug 297657] devel/glib20 fails to build in-place when an older GLib version is already installed

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297657

            Bug ID: 297657
           Summary: devel/glib20 fails to build in-place when an older
                    GLib version is already installed
           Product: Ports & Packages
           Version: Latest
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Individual Port(s)
          Assignee: [email protected]
          Reporter: [email protected]
             Flags: maintainer-feedback?([email protected])
          Assignee: [email protected]

devel/glib20 fails to build when upgrading an existing installation in-place if
an older version of GLib is already installed under /usr/local/lib.

The port builds successfully in a clean build environment, but fails on an
existing system where the previous GLib version is still installed.

The failure occurs during the GObject Introspection step when g-ir-scanner
links the temporary Gio-2.0 binary.

The linker reports:

ld: error: undefined symbol: g_ecn_code_point_get_type
>>> referenced by Gio-2.0.c

ld: error: undefined symbol: g_ip_tos_message_get_type
>>> referenced by Gio-2.0.c

ld: error: undefined symbol: g_ipv6_tclass_message_get_type
>>> referenced by Gio-2.0.c

Environment
FreeBSD 15.1-RELEASE-p2
devel/glib20 2.88.3
Python 3.12
GObject Introspection 1.86.0
Existing installed GLib: 2.86.4

The relevant port configuration includes:

USES= compiler:c11 cpe gettext-runtime gnome iconv:wchar_t localbase:ldflags \
      meson perl5 pkgconfig python tar:xz ...

Root cause

The problem appears to be caused by the localbase:ldflags USES component
adding:

-L/usr/local/lib

to LDFLAGS.

During the g-ir-scanner linking step this path appears before the Meson
build-tree library paths. Consequently, the linker resolves:

-lgio-2.0
-lglib-2.0
-lgobject-2.0
-lgmodule-2.0

against the already-installed GLib 2.86.4 libraries in:

/usr/local/lib

instead of the newly built 2.88.3 libraries in the Meson build tree.

Using the linker's --trace option confirmed that the failing build was actually
loading:

/usr/local/lib/libgio-2.0.so
/usr/local/lib/libglib-2.0.so
/usr/local/lib/libgobject-2.0.so
/usr/local/lib/libgmodule-2.0.so

instead of:

_build/gio/libgio-2.0.so
_build/glib/libglib-2.0.so
_build/gobject/libgobject-2.0.so
_build/gmodule/libgmodule-2.0.so

This also explains why only the three symbols above were reported as undefined:
they are present in the newly built GLib but not in the older installed
version.

Workaround

The problem can be worked around by adding the Meson build-tree library
directories before /usr/local/lib in the port's Makefiles LDFLAGS:

LDFLAGS+=       -L${WRKSRC}/_build/gio -L${WRKSRC}/_build/glib \
                -L${WRKSRC}/_build/gobject -L${WRKSRC}/_build/gmodule

With this change, the linker trace shows:

_build/gio/libgio-2.0.so
_build/girepository/libgirepository-2.0.so
_build/glib/libglib-2.0.so
_build/gobject/libgobject-2.0.so
_build/gmodule/libgmodule-2.0.so

and the three undefined-symbol errors disappear. The complete glib20-2.88.3
port then builds and installs successfully without removing the previously
installed GLib first.

Expected behavior

The port should be able to perform an in-place upgrade when an older version of
GLib is already installed. The libraries built as part of the current port
build should take precedence over the previously installed libraries during the
GObject Introspection linking step.

Actual behavior

The build links the temporary introspection executable against the previously
installed GLib libraries from /usr/local/lib, resulting in undefined symbols
introduced by the newer GLib version.

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