Skip to content

Fix linking libmef for input method plugins - #181

Merged
arakiken merged 1 commit into
arakiken:masterfrom
shitamo:fix/link-libmef-im-plugins
Oct 10, 2026
Merged

arakiken merged 1 commit into
arakiken:masterfrom
shitamo:fix/link-libmef-im-plugins

Conversation

@shitamo

@shitamo shitamo commented Oct 8, 2026

Copy link
Copy Markdown
Contributor

Description

Link input method plugins (uim, ibus, fcitx, m17nlib, scim, and canna) with libmef.

Reason for Change

The uim, ibus, fcitx, m17nlib, scim, and canna plugins use ef_* functions from libmef (e.g. via im_convert_encoding() in inputmethod/im_common.h) but do not link against it, unlike kbd/skk/wnn/iiimf which have @LMEF@.

Inside mlterm this goes unnoticed because libmef is already loaded. However, mlconfig calls dlopen() on the plugins to query im_*_get_info() without libmef. When built with BIND_NOW (hardening=+all), the dlopen fails due to the unresolved symbol (ef_bytes_to_int), causing the plugins to silently disappear from mlconfig's input method list.

Impact

This change ensures that all input method plugins properly link against libmef, allowing mlconfig to load them correctly even under strict hardening flags (BIND_NOW).

Screenshot

Before / After

mlterm_setting mlterm_setting_after

@arakiken
arakiken merged commit e6edac8 into arakiken:master Oct 10, 2026
@arakiken

Copy link
Copy Markdown
Owner

Thanks you.

@shitamo
shitamo deleted the fix/link-libmef-im-plugins branch October 10, 2026 06:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants