Bug 271758 - devel/gobject-introspection: meson.build:2049:2: ERROR: Dependency "iconv" not found
Summary: devel/gobject-introspection: meson.build:2049:2: ERROR: Dependency "iconv" no...
Status: Closed Not A Bug
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-desktop (Team)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-05-31 20:04 UTC by henri62
Modified: 2023-06-02 16:06 UTC (History)
2 users (show)

See Also:
vishwin: maintainer-feedback+


Attachments
Meson log of the failure. (395.78 KB, text/plain)
2023-05-31 20:04 UTC, henri62
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description henri62 2023-05-31 20:04:20 UTC
Created attachment 242526 [details]
Meson log of  the failure.

When building devel/gobject-introspection I get the next error:

glib| Run-time dependency iconv found: NO (tried builtin and system)

subprojects/glib/meson.build:2049:2: ERROR: Dependency "iconv" not found, tried builtin and system


OS version:
FreeBSD xxxxx 12.4-RELEASE-p1 FreeBSD 12.4-RELEASE-p1 GENERIC  amd64

Trying to hack the meson.build failed. I have no experience with this build system so I have no clue how to solve this in a way it should be fixed.
But when I modified the meson.build to get around 'iconv' I ran into this problem:

ERROR: Problem encountered: No getxattr implementation found in C library or libxattr

And xattr seems to be very 'linux' and not BSD friendly.

Also the python version detected or used was 3 and I had to make a symlink python3 to python3.9 in /usr/local/bin to get any further (or hack the meson_options.txt and replace python3 with python3.9 ?).

I need this package as a dependency somewhere down the tree to build dns/bind918.
Comment 1 Charlie Li freebsd_committer freebsd_triage 2023-06-01 19:21:29 UTC
If you built the the base system yourself, what are your src.conf options? iconv is part of libc by default.
Comment 2 henri62 2023-06-01 19:25:27 UTC
Its is a plain installation, upgraded from 12.2 -> 12.3 -> 12.4 and I did not build it myself.
Comment 3 henri62 2023-06-01 19:36:04 UTC
I have two files iconv.h :

-r--r--r--  1 root  wheel  8484 May 21 13:49 /usr/include/sys/iconv.h
-r--r--r--  1 root  wheel  4397 May 21 13:49 /usr/include/iconv.h

So fairly different, could it be that the build takes the wrong one?
Comment 4 henri62 2023-06-01 20:22:29 UTC
Removing libiconv (make deinstall in the port converters/libiconv) results in iconv found but a new build error:

glib| Checking for function "getxattr" : NO
glib| Header "attr/xattr.h" has symbol "getxattr" : NO

subprojects/glib/meson.build:2185:4: ERROR: Problem encountered: No getxattr implementation found in C library or libxattr
Comment 5 Charlie Li freebsd_committer freebsd_triage 2023-06-02 00:48:57 UTC
The converters/libiconv port is required for glib.

The package builders don't run into this at all; you may want to check your build environment for anything extra or missing.
Comment 6 henri62 2023-06-02 10:35:51 UTC
Well I found the problem: After reinstalling glib (via the port in devel/glib20) and so upgrading it from glib-2.74.3_1,2 to glib-2.76.3,2 the build passes now.

I did not change any configuration option.

Maybe a minimum version dependency incorrect in this gobject-introspection?
Comment 7 Charlie Li freebsd_committer freebsd_triage 2023-06-02 12:44:05 UTC
No, you just failed to keep your entire ports tree and resulting packages updated. Partial updates are not supported and never will.
Comment 8 henri62 2023-06-02 16:06:13 UTC
I did an update of the ports tree before I had build everything. In normal cases upgrading any package (due to security updates for example) causes a lot of other packages to be updated too due to version bumps.
A lot of time I need to update a serious amount of depending packages so that it sometimes is frustrating. But I understand that it is difficult to maintain consistency in such a big tree of packages.

So I think something changed in the iconv package between 2.74 and 2.76 that was never noticed to be a dependency in the package(s) that use it.

Anyhow the problem is solved and if somebody runs into the same problem a remedy could be to update libiconv.

So this ticket can be closed, I agree.