【初心者】Ubuntu Linux 126【本スレ】

■ Ubuntu 公式サイト
https://www.ubuntu.com/
■ Ubuntu Japanese Team
https://www.ubuntulinux.jp/

ここは【初心者】Ubuntu Linux 【本スレ】で間違いありません

前スレ
【初心者】Ubuntu Linux 120【本スレ】
https://mao.5ch.io/test/read.cgi/linux/1542152495/
【初心者】Ubuntu Linux 122【本スレ】
https://mao.5ch.io/test/read.cgi/linux/1729990423/
【初心者】Ubuntu Linux 123【本スレ】
https://mao.5ch.io/test/read.cgi/linux/1743554642/
【初心者】Ubuntu Linux 124【本スレ】
https://mao.5ch.io/test/read.cgi/linux/1762285893/
【初心者】Ubuntu Linux 125【本スレ】
https://mao.5ch.io/test/read.cgi/linux/1769315012/
.

mpvのsudo ./installは動かないだろ
その辺のtipsを教えてくれると有益

変なライブラリを　/usr/local/hoge に投入して
gcc -L/usr/local/hoge -R/usr/local/hoge
とかwwww

↑だめなんだってｗｗｗｗｗ



GNUリンカ（ld）の -R との混同

かつて（あるいは一部の商用UNIX系リンカなどでは）、GNUリンカ（ld）の -R オプション（大文字）にディレクトリを渡すと、
互換性のために -rpath とみなす挙動が存在しました。
しかし、これに関しても rpath-link ではなく rpath（実行時パスの埋め込み）の挙動です。

2. 現在の正しい書き方
rpath-link は「リンク時のみ、間接依存している共有ライブラリ（.so）を検索するパス」を指定するオプションです。
GCC経由でこれをリンカ（ld）に正しく伝えるには、
-Wl, オプションを使用して以下のように記述する必要があります。

bash
gcc main.c -Wl,-rpath-link,/usr/local/somewhere

すると　rpath-link　というのは
単純に　-L/usr/local/somewhere
のことではないか？

ごめんね
逃走しますｗｗｗｗｗ

gccでプログラムをコンパイルするときに、昔は、追加の動的ライブラリをコンパイル時に検索する場合
-L/usr/local/somewhere のように書きましたが、今では違う書式なのですか？



結論から申し上げますと、今でも変わらず -L/usr/local/somewhere という書式が正しく、現在もそのまま使われています。
GCCのこの基本オプションの仕様は、昔から変更されていません。

ただし、「現代の開発環境における実務上の書き方」という意味では、いくつか変化や注意点があります。

1. 実行時エラーを防ぐための現代的な書き方

現代のLinux等では、セキュリティや依存関係管理の観点から、
コンパイルが通っても「実行時」に動的ライブラリを見つけられずエラーになるケースが増えています。
そのため、現在は -L だけでなく、実行時の検索パス（rpath）をバイナリに埋め込む -Wl,-rpath をセットで書くのが一般的です。

bash# 現代の推奨される書き方（実行時パスも同時に指定）
gcc main.c -L/usr/local/somewhere -lfoo -Wl,-rpath,/usr/local/somewhere

rpath の正しい書式はわかりました。　昔に -R と書いたのは、どういう環境に由来していますか？


昔 -R と書かれていた書式は、主に System V（システム・ファイブ）系 UNIX、その中でも特に Solaris（SunOS） というオペレーティングシステム（OS）の環境に強く由来しています。


Linuxが普及する以前のUNIX全盛期において、この仕様がどのように生まれ、なぜ現代のGNU環境（Linuxなど）に引き継がれたのか、その歴史的背景を紐解くと以下のような流れになります。


1. 由来となった主な環境

① SunOS 5.x / Solaris（サン・マイクロシステムズ社）
-R の最も代表的なルーツは Solaris です。
Solarisの標準リンカ（ld）は、実行時ライブラリ検索パスを指定するオプションとして -R パス を採用していました。
当時、商用UNIX市場で圧倒的なシェアを誇っていたSolarisのこの仕様は、多くの開発者にとっての「標準」となりました。

② System V Release 4 (SVR4) 系のUNIX
Solarisのベースとなった AT&Tの System V というOSの規格（特にSVR4）を採用している
他の商用UNIX（OSF/1、IRIX、HP-UXなど）でも、同様に -R が使われていました。
これらは現代のLinuxでも使われている ELF（Executable and Linkable Format） というバイナリ形式の先駆者であり、
ELFの構造として rpath（当時は DT_RPATH）を埋め込むために -R オプションが定義されました。


2. なぜアルファベットの「R」だったのか？
非常にシンプルで、Run-time library search path（実行時ライブラリ検索パス） の頭文字である R から取られました。

AI大先生に感謝しよう
ありがたや


さようならｗｗｗｗ

>>323
それです！まさに。まとめ乙です

>>329
本当にそれです、結構大変だった
そして今はAIに相談しながら進められる
過去トラブって必死に情報収集、時に英語の掲示板や開発者のメーリングリストなんかにたどり着き翻訳してとか...
時代が変わったと思った

>>330
前はsudo ./installで直インストやってたけど今は./update終わったらdpkg-buildpackage -uc -us -b -d -j8(8は自分のCPUコアやスレッド数)
でやってDEBパッケージ作ってるよ
mpv_2026.05.22.9e06c3248a_amd64.deb　こんなパッケージが出来上がるよ

IDでNGしたいが頭がおかしいだけで悪い人じゃ無さそうだから悩ましい

長文連投は5ちゃんでは荒らしと見做される

コレだけ覚えて帰ってな

Ubuntu 26.10（stonking）の開発 / “Redhound”の導入とCIX P1への対応、Ubuntu Core 26のリリース | gihyo.jp
https://gihyo.jp/admin/clip/01/ubuntu-topics/202605/22

gcc でプログラムをコンパイルする場合、ソースやヘッダで関数が複数回定義されることがあります。
昔は -z muldefs というオプションをつけると、一応はコンパイルが通りました。これは現在でも有効な手法でしょうか？


結論から申し上げますと、-z muldefs （または --allow-multiple-definition）は、現在でも GCC（正確にはGNUリンカ ld）のオプションとして有効であり、機能します。
しかし、現代のソフトウェア開発においては、これを常用することは「非常に非推奨な、避けるべき禁じ手（最終手段）」とされています。
その理由と、現在推奨されている正しい対処法を解説します。


1. 現在でも有効だが「非推奨」とされる理由
このオプションは、重複した定義のうち「最初に見つかったもの」を優先し、残りを無視して無理やりリンクを通すものです。
これが危険とされるのには、現代のコンパイラ最適化の進化が絡んでいます。



未定義動作（Undefined Behavior）の誘発
C/C++の標準規格（One Definition Rule / 単一定義規則）では、外部結合を持つ関数や変数の重複定義は認められていません。
これに違反すると「未定義動作」となり、プログラムがクラッシュしたり、予期せぬ計算結果を出力したりする原因になります。



コンパイラ最適化（LTOなど）との相性が最悪
現代の GCC で -Flto（リンク時最適化）などを有効にしている場合、リンカが「どの関数をインライン展開すべきか」を判断できなくなり、
コンパイルエラーになるか、あるいはバイナリが完全に破壊されるリスクがあります。



グローバル変数に対する挙動の変化（GCC 10以降）
C言語でヘッダに変数の実体を書いてしまう「暫定定義（Tentative Definition）」の重複は、昔の GCC ではデフォルトで許容されていました（-fcommon）。
しかし、GCC 10以降は安全性のためにデフォルトが -fno-common となり、厳格にエラーを出すようになっています。
これに引きずられて関数の重複もより厳しくチェックされるようになっています

26.04にアップグレードしたらWinhqやら特定のdotnetのバージョンやらpythonのvenvのpipやらが無効にされてて草ｗｗ

resoluteからpython3.14じゃなかった

OSアップグレードは昔から鬼門だからね。下手にあれこれ手を加えるくらいなら新規インストールした方がよい

実験的にアップグレードかましたこともあるけど
使うのはずっと新規インストールだな
GWあたりからじっくり整える作業するのがむしろ毎回楽しい

>>343
phyだけに3.14

>>330
すごく古いOSに入れるという話じゃなければ
./rebuild -j4
sudo ./install
で普通に入るでしょ？

エラーが出たらAIに放りこめばパッケージを追加とかaptコマンド付きで丁寧に教えてくれる
数十行でキレる人間と違って何百行でも入れて聞けばいい
ダウンロードとか日本語名のフォルダでbuildするとエラーが出るけどAIは馬鹿にせず指摘してくれる

画像、音声出力先がないのにbuildが通ってしまうことがあるけど、それも訊けば追加パッケージを教えてくれる

やはりそれだと、scripts/mpv-install: 5: meson: not found　で止まる
pipでmesonは入ってる状態

スクリプト
メソンをフルパスで指定したらいいんじゃね？

そもそもmpvをビルドからしなきゃならん理由がよく分からんけどね。aptじゃ駄目なの？

ビルドは必要に迫られてだよ
割と頻繁に更新するyt-dlp, ffmpeg, mpv関連はaptから排除して使いたい

> pipでmeson

$ sudo apt install meson
でどう？

>>348
sudo apt install mesonで入れたからか普通にbuild出来たよ
PATHを通せないならPIP版は消してaptで入れ直してみては

>>350
結構時間がかかかるし依存ライブラリも多いのでそのほうが楽だろうね
何を変えたいんだろう？

すまん
もたもた書いてたら両方被った

>>351
yt-dpl以外は最新である必要ある？

今どきビルドしなきゃならんrustのクレートくらいやろ
archでゆうignorepkgみたいな更新のときにパッケージを除外してくれるやつあるやろ

apt-mark hold

aptでmesonとninja-build入れたら普通にビルドできました
pip installが原因だと判明したのは収穫でした
apt-mark holdはsnap完全除去で駄目押し的に使ってる
meson --version; ninja --version
1.10.1
1.13.2

ninjaはビルド高速化ツールだから、多分無くてもできるかと。まあ、早いに越したことはないね。pythonのバージョンは3.14でやるとトラブル少ない。既存のmakeはそのあたりをターゲットに構築されている場合が多いから。とはいえそれも今だけの話だけど

てかpip遅いしだるいから今時はuv

ubuntu 26.04ではpythonのデフォが3.17だから、このあたりの差分が顕著に表面化する時期なんじゃないかな

uvの話出たのでついでに検証してみた
curl -LsSf https://astral.sh/uv/install.sh | sh
uv venv
source .venv/bin/activate
uv pip install meson
ninjaは別途次のように入れた
sudo wget -qO /usr/local/bin/ninja.gz https://github.com/ninja-build/ninja/releases/latest/download/ninja-linux.zip
sudo gunzip /usr/local/bin/ninja.gz
で肝心の./rebuild -j4; sudo ./installはなんと普通にビルド通った
pipだけがもしかしておかしいのか？
eson --version; ninja --version
1.11.1
1.13.2

AIに頼るとあれ入れてこれ入れてループに陥りがちだけど、素直に王道でやるのが一番早いというか、エラー吐いても対処しやすいというか。あれこれ入れるほど自力解決は困難になるんだな

>>362
あえてAIに聞いてパッケージを足していったけどうまくいったよ
コツは全部入れずに必要なパッケージを一つずつ入れていくことかな
人間に聞くとキレられるだろうけどAIは何度エラーを出して聞き直しても教えてくれる

いや、それで上手く行くことが多いのは知っている。過去解決したルートに誘導しているって事だろうし。でもよく分からない、ほんらなら必要ないものをガシガシ入れる羽目になる事に、生理的嫌悪感があるだけで

>>364
だからパッケージがなくてエラーが出るものだけ入れていくと言ってるやん

なるほど、うまい使い方だと思うよ

もっとエラーメッセージをよく見ないと

>>348 だと、meson がどこにあるんだかわからん　って言ってるんだから

which meson とか whereis meson とかして

その　mpv-install とかいうスクリプトをviで開いて
５行目の　meson をたとえば
　/usr/local/bin/meson　とかに書き換えたら済む話だと思うね

>>367
PIPで入れてローカルに置かれてしまってるんだろうね
古いOSでPython周りだけ新しいとかじゃなければaptで入れとけばトラブルが少ないんじゃないかな

ｍesonがそういうninjaみたいな置くだけのバイナリだったらあまり悩まなくて済んだかも
mesonの実態はmeson.pyみたいなやつだよ
>361のuvは気のせいだったmeson not foundだったやはり
こういう事象はmpvビルドに特有なんだよ

>>369
mpvはスクリプトでビルドしてるし、それをAIに入れたら解決策を出してくれると思うよ

そんじゃ、スクリプトに

python meson.py

って書けばいいじゃないか

mpv doesn't need to be installed. The binary ./mpv/build/mpv can be used as-is.
You can copy it to /usr/local/bin manually.
レドメにこうあるから作者もインストールにはこだわりないみたいだし作りが甘いと見た

どこに置いてあっても

./mpv

と打てばよい

>>372
installスクリプトはコピーしてるだけだしビルドとは別の問題でしょ

uv何ていうのがあるのか、知らんかった
ていうかpip install するとちゃんと
WARNING: The script meson is installed in '~/.local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
って出るのね

自分で~/.local/binにPATH通さないとダメなのね
なにそれw

通すか通さないかはあなたの自由

uvは便利なようで便利じゃなかったりする

25.10から26.04にしたらどんな再生音も途切れるようになってしまったんですが、音管理してるのってpipewireですよね？
ネット上で散見されるquantumの値弄る対処法が通じないんですが、他に何か音途切れで思い当たることありますでしょうか
出力デバイスのせいかなと思いましたがUSBスピーカーとUSB-DAC共に音途切れ出ます

音切れというか、音が出なくて散々悩んで、結局コネクタの接触不良だったという事がある。爪楊枝とアルコールでクリーニングしたら復活した

それ以外だと、pulseaudio-utilsを入れて
pactl load-module module-raop-discoverで解決したこともあるな

25.10で良好ならハードではないんだろう
バックグラウンドで何か勝手に動いてる感じだよな、今resolute使ってるので少し分かる
ファイルの開閉も少し引っ掛かりがある

>>378ですがどんな再生音と言うのは間違いのようでした
aplay試してなかったです。取り敢えず10分聴いて音切れ無かったです
やっぱpipewireかな…
pulseの代わりで来たハズが共存してるみたいでなんか気持ち悪いんですよねこいつら

はやく26.04(.1)こないかな

26.04にアップデートしたけどいい感じだね

>>381
こちらは音途切れとついでに時時チャタリングもしますね
要再起動

>>383
win10で使ってるのubuntuにしようかと考えてるけど26.04がいいかな？24.04とどっちなのか分らん

>>385
新しい方でいいんじゃない？
古い機種ならUbuntuよりもLinux Mint Xfce Editionがいいかもしれないが

24.04の方が枯れてるから不具合も無いし大抵の野良ソフトやドライバーが使える
最初に使ってみるなら24.04だと思う

AMDの公式プロプライエタリドライバーが25.10用がなくて泣いた思い出…

ドライバーの問題なら
提供してるのはカーネルなので
ダメもとで、古めのカーネルにしてみたらどうかな？

apt-cache search
とかしたら何個か候補があると思うけど？

>>387
プロプライエタリはLTSのみ対応がほとんどの印象

地味にいまさらで24.04LTSとKDE-Plasma5を使うというのもマイペースで良い
DTMや２Dグラフィック系　Office系主体なら最新のほうが使いづらい場合もある

古いの使い続けても問題ないというのがオープンソースの良いところ DE とかいらない派

５年以上前のハードに３年前のLTSを使うのはセキュリティがちゃんとしていれば理にかなっているんだよ
SandayならDebian12でも不都合は無いはずだ

さらに言えばMint Zorin Popが26.04LTSにしないのは自分たちのユーザー層のハードと用途をちゃんと理解してるからだ
理解してないのはカノニカルだけなんだよ

linuxで動くwifi子機なんだけど、mediatek系がいいの？
realtek系だと不安定とか聞いた
ただ、規格が新しい

「Ubuntu の長期サポート（LTS）リリースは通常 5 年間サポートされますが、Extended Security Maintenance（ESM）オプションを利用すれば、合計で 10 年間サポートを受けられます。さらに、Canonical は最近、特定の LTS バージョン向けにサポート期間を最大 15 年まで延長できる Legacy アドオンを発表しました。」

ドライバがどうかはLiveUSBで試せばいい

定番みたいなやつはないの？

何処かのスレで似たようなこと訊き回ってた奴がいたな

>>394
チップセットの対応は以下のページにあるけど製品との対応が分からん
Raspberry Piで色々と調べてる人がいるので参考になる
BuffaloのWLI-UC-GNMが定番だけど、もう売ってない

https://github.com/morrownr/USB-WiFi/blob/main/home/USB_WiFi_Chipsets.md

ありがとう
自分もそこ見てる

どこのメーカーがいいとかあるんですかね？
realtekは評判が悪いけど、mediatekはカードが多くて、usbはすくないので、realtekから選んでもいいのかな

>>400
挿したら動くかどうかはベンダーID:プロダクトIDがドライバに登録されていることも必要
調べたらBuffaloのWI-U2-433DM（Realtek RTL8821AU系）も挿したら動いた
buffaloのWLI-UC-GNM（Ralink RT8070）も挿したら動く定番として知られる
公式か非公式か分からんけど創業の精神を忘れずマイナーなコミュニティに貢献してるね
ELECOMのUSB WIFIは動いたことないや

>>401
realtekかmediatekかは余り気にしなくていいのかな？
realtekはどこでもやめとけ言われてるけど、新しいusbドングルはrealtekばかり

>>401にしときなさい

>>403
ちとフルすぎて、、、
wifi6世代でおすすめないすかね

Archer TX20U Nano MT7921で検索

MediaTEK MT7921
WiFI6 MIMO 2x2 5GHz/80MHz 1200Mbps /2.4GHz 574Mbps
※USB2.0接続なので5GHzの実効速度は最高下り300Mbps /上り200Mbps 程度

同じスペックでUSB3.0接続の Archer TX20U は5GHzの実効速度は最高下り800-700Mbps
サイズは大きく発熱も多いが最新世代なのでサイズ以外に問題はないと思われ

残念ながら、国内メーカーはRealtek一辺倒なのでMediaTekはTP-Linkしか選択肢がない
技適警察には追求されないけれど国士さまたちからの風当たりは強い

ありがとう
https://wikidevi.wi-cat.ru/TP-LINK_Archer_T_series
ここだとarcher TX20U realtekになってるんだが、中身は一律同じではないのかな

>>402
Realtekは100M有線LANの時代に安くてやや負荷の大きいチップを作ってたので蟹と馬鹿にするのが流行った
Wifiのチップの場合はチップ自体とドライバの種類が多すぎ、チップ名が似ていて違うことがあってややこしいとかの事情が嫌がられているのでは
実際はRealtekでもデフォルトで挿したら動くものもある

>>405
Archer TX20U NanoもRealtekやで
デフォルトでは動かないっぽいし

Debian Stableで動くものが汎用性の高いWifiだ

失礼、 >>405 はわたしの完全な間違いなので参考にしないで！

TP-Linkでも Archer TXE50UH というモデルは MT7921AUN みたいだけれど
日本国内の正式な流通に乗っていないみたいだから技適はとれておらず技適警察の標的ということに

まーUSB2.0のMT7610UとUSB3.0のMT7612Uは国内メーカーもかつて販売していたので
それらを探すしかないよね

採用リストは↓（433/450表記がMT7610Uで866/900表記がMT7612Uの可能性が高い）
https://pastebin.com/raw/wJMfSMhb

>>407
デフォルトで動くというのは、カーネルドライバが入ってるってことよね？
メーカードライバはあてにならないし

>>409
ややこしいよね☺(´・ω・`)

>>410
挿したら動くのは、ドライバが入っていてかつ製品のベンダーID:プロダクトIDが登録されていることが必要
登録から調べたら分かるんだろうけど誰もやらないし面倒くさそう

>>409
MT7610Uというのは相当古いけど、定番化するようなものはやっぱ古いのかな

RTL8812BU
Archer T3U
https://www.tp-link.com/jp/home-networking/adapter/archer-t3u/

>>411
idというのは　つまりlinuxがusb機器として認識しないことがあるってことかね？
調べたら、ストレージとして認識する場合があるとかかんとか。

ええと
lsusbしてベンダとプロダクトIDを調べてudevをごにょごにょして/etc/networkでwpasupplicantの設定とか
そんな記憶があるなｗｗｗ

ただただ面倒くさくて手順忘れるよな

Archer T3U Plusは24.04と26.04の両方で挿すだけで普通に使えた
T2U Plusは24.04で有志のドライバ入れないとダメだったが
T2U Plusは26.04では試してないからわからんｗ

>>404
ない
ドライバのソース持ってきてビルドすれば安定して動かせるかどうか自分で判断できる人間はこんな所で聞いたりしない
カーネルのソースにマージされてないドライバは
モデルごとにフォークしたりして追うのも結構大変
特にArcherは買ってきて動かせたらラッキーくらいに考えておいた方が良い

>>416
T3U安くていいよな

22.04以前はPanda 300Mbps Wireless-N USB Adapter が定番だったが今はもう売ってないのな

1000Mbps有線USB 3.0 Type C USB - RJ45 LANイーサネットアダプター RTL8153 ネットワークカード
初回割引　295円
https://ja.aliexpress.com/item/1005009156762280.html

罠　ギガビットのは８００円
ほんとにrtl8153かワカランｗｗｗ

まぁubuntu使う目的も人それぞれやなぁ

>>417
チップがここで対応していても、プラグアンドプレイで動くとは限らないのかね？
https://github.com/morrownr/USB-WiFi/blob/main/home/USB_WiFi_Chipsets.md

>>423
チップに対応するドライバがあっても動くとは限らない
ベンダID・プロダクトIDが登録されていないと認識しない
Windowsだと無理矢理ドライバを割り当てることがGUIでできるけどLinuxでは無理

コマンドラインからベンダID・プロダクトIDを登録して認識させるしかない
ただ今時はAIに聞けば教えてくれるよ

プラグアンドプレイで動くまでに必要な項目

1. カーネルがusbとしてデバイスを自動認識する（普通はここはクリアする、カーネルが古かったり、いかれたデバイスだと失敗することもある
2. ドライバーモジュールがインストールされている
3. ドライバーモジュールがオートロードされる設定になっている（中にはロード時のオプション指定が必要なものもある
4. ファームがインストールされている（最近の一部デバイスではドライバーだけでは動かなくてチップごとのファームが必要なものがある intel とか
5. ドライバーにバグがない（マイナーチップだとここが鬼門、同じチップ名なのに中身とか世代によって動かない変なやつもある
6. udev rule 等で適切なデバイス名や設定が付与されるようになっている（最近のディストロは普通はなってるけどマイナーだと罠があるかも、自分でルール書けばOK
7. wifi とかだとアクセスポイントだのssidだの暗号化だの使用するバンドだの設定がしてあって、それを反映させる用のデーモンがインストール/起動している（設定忘れるやつはおらんと思うけど
8. DHCP等で適切なネットワーク設定が降ってきて付与される（チップ関係ないけど一応

チップ一緒で同じドライバで動くデバイスでもプロダクトIDは違ってたりする
商品型番は一緒でも
商品型番一緒でもチップはマイナーチェンジしてるケースがある

>>426
安中華だとプロダクトIDすら変わってないのにチップの実装方式違ってたりするぞ
初期ハードだと実装間違っててまとに動かない製品とか（でその間違ったやつがジャンク市場に大量にあふれてたり
あと偽物だのクローンだのも横行してるので見かけもIDも完全に同じでも動かないとか

チップさえ合えばいいってもんじゃないのね、、、

>>425
自分には現状では難しそう
linux対応を謳ってるのはugreenくらいだから、それにするか