Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

libdir inexplicitly overriden when installing a shared library from a subproject

オープン
#817 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
38/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
python
領域
build-system

調査の方向性

示されている meson.build ファイルを使い、python -m build -w を実行してインストールを再現し、その後 unzip -l で生成された wheel を調べます。subproject custom_target または shared_library の install_dir がどのように処理されるかを、py.get_install_dir() と .foo.mesonpy.libs の出力を含めて追跡します。共有ライブラリが foo/libfoo.so としてインストールされ、wrapper とパッケージファイルが引き続き使用可能であれば完了です。

索引モデルが issue の本文から書いたものです。

説明

I'm building a ctypes-based Python wrapper for a library provided as a subproject.

I would expect such a project to have a simple layout of foo/__init__.py, foo/wrapper.py and foo/libfoo.so, like in https://github.com/joerick/python-ctypes-package-sample or even https://github.com/peppedilillo/meson-ctypes-test.

The compiled library does the following in subprojects/foo/meson.build:

foo_tgt = custom_target(
  'foo',
  output: 'libfoo.so',
  command: [...],
  install: true,
  install_dir: get_option('libdir'),
)

It's a custom_target, because it's actually another wrapper, but the same issue persists with shared_library.

My meson.build looks like this:

project('foo-python')

py = import('python').find_installation(pure: false)
py.install_sources(
  'foo/__init__.py',
  'foo/wrapper.py',
  preserve_path: true,
)

subproject(
  'foo',
  default_options: {
    'libdir': py.get_install_dir() / 'foo',
  },
)

foo/wrapper.py attempts to load the shared library with a simple ctypes.cdll.LoadLibrary(str(Path(__file__).with_name("libfoo.so"))).

And even though I explicitly specify the libdir, the built wheel contains the .so file in a completely arbitrary location:

$ python -m build -w
...
Successfully built foo-0.1.0-cp313-cp313-linux_x86_64.whl
$ unzip -l dist/foo-0.1.0-cp313-cp313-linux_x86_64.whl
Archive:  dist/foo-0.1.0-cp313-cp313-linux_x86_64.whl
  Length      Date    Time    Name
---------  ---------- -----   ----
      149  2025-11-01 14:50   foo-0.1.0.dist-info/METADATA
       88  2025-11-01 14:50   foo-0.1.0.dist-info/WHEEL
  1360680  2025-11-01 14:49   .foo.mesonpy.libs/libfoo.so
      532  2025-11-01 14:17   foo/__init__.py
    22526  2025-11-01 14:18   foo/wrapper.py
      507  2025-11-01 14:50   foo-0.1.0.dist-info/RECORD
---------                     -------
  1389847                     7 files

In this case I would expect libfoo.so to be placed in foo/libfoo.so.

This issue only persists when using subprojects. Without them, it's possible to simply do custom_target(..., install: true, install_dir: py.get_install_dir() / 'foo') (or the same with shared_library), as evidenced in https://github.com/peppedilillo/meson-ctypes-test (also related - https://github.com/mesonbuild/meson-python/discussions/573).

Seems to also be related to https://github.com/mesonbuild/meson-python/discussions/770.

主要言語
Python
スター
180
フォーク
93
平均マージ
18時間 29分
マージ済み PR(30日)
14

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

mesonbuild/meson-python のほかの issue

mesonbuild/meson-python の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。