FreeBSD で root は gcc_s を拾え uyota は失敗2017年07月01日 11時35分12秒

一般ユーザで「/usr/bin/ld: cannot find -lgcc_s」のためリンク出来ない問題で悩んでいる。ちょっと横道にそれたが、libgcc について調べた。他の FreeBSD で報告されている問題とは若干違うようだ。

まずは、コンパイルとリンクを切り分ける。現在の環境は、もうすぐリリースされる FreeBSD 11.1-RELEASE相当。PRERELEASE だったり、RC だったするが、大した違いは無い。

% cat a.c 
int main(){ return 0; }
% cc -c a.c 
コンパイル自体に問題は無い。
% cc a.o
/usr/bin/ld: cannot find -lgcc_s
cc: error: linker command failed with exit code 1 (use -v to see invocation)
リンク時に失敗。
% cc -v a.o
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
Target: i386-unknown-freebsd11.1
Thread model: posix
InstalledDir: /usr/bin
 "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags
-m elf_i386_fbsd -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib a.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
/usr/bin/ld: cannot find -lgcc_s
cc: error: linker command failed with exit code 1 (use -v to see invocation)

不思議なことに、root で実行すると全く同じコマンドなのに成功する。

$ cc -v a.o
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
Target: i386-unknown-freebsd11.1
Thread model: posix
InstalledDir: /usr/bin
 "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags
-m elf_i386_fbsd -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib a.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
$  ls -l a.out
-rwxr-xr-x  1 root  uyota  5355 Jun 30 01:24 a.out
二つのアカウントのライブラリ関連の環境変数も調べてみたが、違いは見当たらない。

前回次回

nfs の umount が返らない2017年07月02日 11時33分59秒

FreeBSD で最近よく /usr/src と /usr/obj を nfs でマウントしている。make installworld installkernel の後に、umount /usr/src /usr/obj をやるのだが、umount が返って来ない。ctrl-c をやるとファイルシステムは無くなっている。

どのバージョンから起き始めたのか分からないが、現在のシステムは FreeBSD 11.1-RC1。

libgcc_s が見付けられない理由を truss で追跡2017年07月05日 12時07分56秒

root では見付けられる /lib/libgcc_s.so.1 をなぜ uyota アカウントでは見付けられないのかを更に追跡。truss を使ってシステムコールを探る。
% truss /usr/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both
--enable-new-dtags -m elf_i386_fbsd -o a.out /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/crtbegin.o -L/usr/lib a.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o | & grep gcc_s
open("/usr/lib/libgcc_s.so",O_RDONLY,0666)       ERR#13 'Permission denied'
open("/usr/lib/libgcc_s.a",O_RDONLY,0666)        ERR#2 'No such file or directory'
open("/usr/bin/../libdata/libgcc_s.so",O_RDONLY,0666) ERR#2 'No such file or directory'
open("/usr/bin/../libdata/libgcc_s.a",O_RDONLY,0666) ERR#2 'No such file or directory'
open("//lib/libgcc_s.so",O_RDONLY,0666)          ERR#2 'No such file or directory'
open("//lib/libgcc_s.a",O_RDONLY,0666)           ERR#2 'No such file or directory'
open("//usr/lib/libgcc_s.so",O_RDONLY,0666)      ERR#13 'Permission denied'
open("//usr/lib/libgcc_s.a",O_RDONLY,0666)       ERR#2 'No such file or directory'
-lgcc_swrite(2,"-lgcc_s",7)                              = 7 (0x7)
libgcc_s が読み込みように開けない。

同じコマンドを root で実行。

# truss /usr/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both
--enable-new-dtags -m elf_i386_fbsd -o a.out /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/crtbegin.o -L/usr/lib a.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o | & grep gcc_s
open("/usr/lib/libgcc_s.so",O_RDONLY,0666)       = 9 (0x9)
open("/usr/lib/libgcc_s.so",O_RDONLY,0666)       = 3 (0x3)
こちらでは問題なく開いている。

最初に libgcc_s を調べたときもそうだったが、読み出しの権限は与えられている。

% ls -sld /usr/lib/libgcc_s.so /lib/libgcc_s.so.1
46 -r--r--r--  1 root  wheel  45468 Jun 30 02:51 /lib/libgcc_s.so.1
 0 lrwxr-xr-x  1 root  wheel     23 Jun 30 02:51 /usr/lib/libgcc_s.so -> ../../lib/libgcc_s.so.1
% head /usr/lib/libgcc_s.so
head: /usr/lib/libgcc_s.so: Permission denied
上記は、FreeBSD 11.1-RELEASE と、11.0-RELEASE のシンボリックリンクだった。

気になったので、10.2-RELEASE でも ls。

% ls -sld /usr/lib/libgcc_s.so
 0 lrwxr-xr-x  1 root  wheel     18 Feb 21 2016 /usr/lib/libgcc_s.so -> /lib/libgcc_s.so.1
% head /usr/lib/libgcc_s.so
?ELF...
10.x-RELEASE の時は、絶対パスだったのが、11.x-RELEASE になって、相対パスに変わっている。

前回次回

releng/11.1 に入ってくる変更が限られてきたが2017年07月06日 11時14分35秒

releng.11.1 に移って 11.1-REELASE を追いかけている。releng が作られてから、変更の数は減ったが、システムの低レベルへの変更があれこれ入ってきている。

ここ、二、三日で入ってきた変更は、rpc、vm、geom、cam、cacm/scsi、kern、vm、fuse、などの細かな変更。

/usr/lib/libgcc_s.so へのアクセス2017年07月07日 11時55分49秒

libgcc_s.so が見付けられないのは /usr/lib からのシンボリックリンクが変わったからの様に見られる。
% ls -sld /usr/lib/libgcc_s.so /lib/libgcc_s.so.1
46 -r--r--r--  1 root  wheel  45468 Jul  3 20:51 /lib/libgcc_s.so.1
 0 lrwxr-xr-x  1 root  wheel     23 Jul  3 20:51 /usr/lib/libgcc_s.so -> ../../lib/libgcc_s.so.1

head でどうしたらファイルが読めるか実験をする。

% head -c5 /usr/lib/libgcc_s.so
head: /usr/lib/libgcc_s.so: Permission denied
% head -c5 `realpath /usr/lib/libgcc_s.so`
ELF%
head -c5 `ls -l /usr/lib/libgcc_s.so| nawk '{print $NF}'`
head: ../../lib/libgcc_s.so.1: No such file or directory
realpath で展開した後ならファイルを読めるが、シンボリックリンクを辿ると、駄目な様だ。realpath は realpath ライブラリ関数を呼ぶだけのコマンド。シンボリックリンクを展開し、実ファイルに展開できる。

まあ、最後のコマンドではリンクを手元で展開しては正しいファイルのパスでは無くなるが…。

stat と lstat はシステム関数で、こちらもそれに対応する stat コマンドが存在する。-L をつけると lstat の動作になり、シンボリックリンクを表示する。

% stat -L /usr/lib/libgcc_s.so
stat: /usr/lib/libgcc_s.so: stat: Permission denied

前回次回

--allow-unrelated-histories が必要な git merge2017年07月08日 12時53分44秒

二つの git レポジトリを統合するのは git merge で行う。--allow-unrelated-histories は二つの独立したレポジトリを統合するときに必要になる。

同じように、repo1 に repo2 を取り込む例。

% cd path/to/repo1
% git remote add repo2 path/to/repo2
% git fetch repo2
% git merge repo2/master
fatal: refusing to merge unrelated histories
% git merge --allow-unrelated-histories repo2/master
元が一つだった場合は、ただ単に枝分かれを統合しただけだとも思う…。

前回次回

FreeBSD の libgcc_s シンボリックリンクを作り直す2017年07月09日 13時30分59秒

/usr/lib からのシンボリックリンクが変わった為に、一般ユーザからファイルが読めなくなっている。そこで、リンクを針直してみた。

ここは root で作業。 まずは、print で実行コマンドの点検。

$ cd /usr/lib
$ ls -l *.so | nawk '$NF ~ /..\/..\/lib/{cmd="ln -sf " substr($NF, 6) " " $(NF-2);print cmd}
ln -sf /lib/lib80211.so.1 lib80211.so
ln -sf /lib/libalias.so.7 libalias.so
ln -sf /lib/libavl.so.2 libavl.so
ln -sf /lib/libbegemot.so.4 libbegemot.so
ln -sf /lib/libbsdxml.so.4 libbsdxml.so
ln -sf /lib/libcam.so.7 libcam.so
print を system コマンドに変えて、再度実行。
$ ls -l *.so | nawk '$NF ~ /..\/..\/lib/{cmd="ln -sf " substr($NF, 6) " " $(NF-2);system(cmd)}'
$
この後、/usr/bin/ld: cannot find -gcc_s のエラーは出なくなった。

前回次回

FreeBSD の /usr/bin/ld: cannot find -lgcc_s の修正の仕方2017年07月11日 13時21分27秒

FreeBSD で /usr/bin/ld: cannot find -lgcc_s がでて困っていた時のまとめ。

/usr/lib 以下のシンボリックリンクの貼り方が変わったのが原因のようだ。そこで、修正するには以前の様なシンボリックリンクに変えれば良い。

$ cd /usr/lib
$ ls -l *.so | nawk '$NF ~ /..\/..\/lib/{cmd="ln -sf " substr($NF, 6) " " $(NF-2);system(cmd)}'
なお、このコマンドは、root で作業。

前回

FreeBSD 11.1-RELEASE が若干遅れているらしい2017年07月14日 11時52分55秒

一週間ぐらい前に、FreeBSD 11.1-RELEASE が若干遅れているとのメールが流れていた。

昨日は、デバイスと VM 関連の修正が入っていた。今日は文書や設定の変更の五つを含めて、計九つの修正が releng/11.1 に入ってきた。

FreeBSD 11.1-RELEASE 向けの pkg が作成された2017年07月15日 12時19分41秒

FreeBSD 11.1-RELEASE 向けの pkg が公開された。

個人的には、11.1-RC3 の時点でも特に問題は出ていない。pkg も実験用に試してみたが特に大きな違いは見られない。すぐにでも、主機でも更新しようと思っている。