clang-format -style=file -i <file>2017年12月09日 14時16分49秒

clang でコーディング規約は、.clang-format ファイルを作る。
% clang-format -style=file -i <ファイル名>
でファイルを更新。

規定のスタイルには、LLVM、Google、Chromium、Mozilla、WebKit が準備されている。

前回

clang でコーディング規約を調べられるようだ2017年12月04日 14時00分11秒

ClangFormatにてコーディング規約を調べられるようだ。
ClangFormat describes a set of tools that are built on top of LibFormat. It can support your workflow in a variety of ways including a standalone tool and editor integrations.

clang-format is located in clang/tools/clang-format and can be used to format C/C++/Java/JavaScript/Objective-C/Protobuf code.

取り敢えず、メモ。

前回次回

C99 の bool 真偽型2017年10月02日 12時24分21秒

C99 から bool 型が導入され、true と false がその値になっている。
#include 

bool val1 = false;
bool val2 = true;

BOOL、boolean、boolean_t 等と良く使われて、似て否なる物も多いので、どれがシステム規定のだかこんがらがりやすい。

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 のエラーは出なくなった。

前回次回

/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

前回次回

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 になって、相対パスに変わっている。

前回次回

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
二つのアカウントのライブラリ関連の環境変数も調べてみたが、違いは見当たらない。

前回次回

FreeBSD での -lgcc_s の続きを調べる2017年06月13日 12時43分49秒

一般ユーザでリンク出来ない問題で悩んでいる。検索を続けると、lgcc_s は結構見付かる。大まかに分けると、Linux 関連の物、FreeBSD 関連だが gcc と clang が共存するもの。FreeBSD 関連だが、amd64 環境で、i386 版の作成に失敗する物、FreeBSD 関連で、base では問題無いようだが、ports でうまくいっていないもの等がある。

現状では 11.0-RELEASE から起きていた事。また、root ユーザでは問題ないこと。root ユーザと非 root ユーザの ld コマンドが同一な事。base でも ports からも gcc は一つも入っていない事は確認した。

libgcc は GCC の名がついているが、The GCC low-level runtime library によると、GCC が提供している低レベルライブラリみたいだ。GCC の実行環境を提供しているわけではない。

前回次回

FreeBSD で /usr/bin/ld: cannot find -lgcc_s2017年06月01日 12時42分58秒

cc がなぜだか動かなくなっている。11.0-RELEASE に更新した後からこうなっていた様だが、ながいこと気がつかなかった。
% cat a.c 
int main(){ return 0; }
% cc a.c 
/usr/bin/ld: cannot find -lgcc_s
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gcc_s のライブラリ自体は見付けられる。
% ls -L /usr/lib/libgcc*so
/usr/lib/libgcc_s.so
% ls -l /usr/lib/libgcc*so
lrwxr-xr-x  1 root  wheel  23 May 23 02:51 /usr/lib/libgcc_s.so -> ../../lib/libgcc_s.so.1
なおも奇妙なことに、root だと、問題なくリンクできる。-v の表示を比べてみたが、root も自分も同じ出力。

次回

indent(1) が FreeBSD の style(9) に一番近いようだ2017年03月15日 06時52分38秒

FreeBSD で man style をやると、長々とコーディングスタイルが出てくる。何度か読もうとしたが、長すぎて覚えられず、どれが当てはまるか簡単には分からない。

少し調べてみたところ、Who use indent(1), how to config .indent.pro to achieve style(9)? の質問が見付かった。

/usr/share/examples/indent/indent.pro から、ルールを持ってくると使えるようだ。幾つかのカーネルコードを試してみたが、結構間違いが指摘されて出てくる。

次回