ToDo:
昔見つけたGNU Fortranのバグが最近のGCCだと治ってるので、Bugレポートを掘り出して確認してみた
PR fortran/66377が該当で、trunk rev.224159 及び gcc-5-branch rev.224171 にて修正が適用されており、GCC 5.2.0以降で治っている
バグ報告が、2015/06/02なので5年も前に見つけているので、バグレポートしてればもっと早く治ったのかなぁ…
packages build cluster上でもビルドできない模様だが、手元の環境だと
で、直接の原因は/usr/include/sys/systm.h(/usr/src/sys/sys/systm.h)の変更で pauseマクロだったものを関数ポインタを拾えるようにstatic inline関数に置き換えた結果、/usr/include/unistd.hの int pause(void) APIと定義衝突している
aq_hw.c @ L35の#include<unistd.h>を外せば、コンパイル自体は出来るが、生成されたコードは未検証
あとで、コンパイル可能な環境で、アセンブラ出力が変わるか調べてみるか？cc -sで吐き出すaq_hw.cのアセンブラコードは、unistd.hインクルードの有無で変わらない模様
unistd.hのインクルードを外す修正で問題なく動作することを確認した
当方では、net/aquantia-atlantic-kmod/Makefile.localに以下のコードを置いて対処した
post-patch:
@${REINPLACE_CMD} -e 's|^\(#include <unistd.h>.*\)|//\1|' ${WRKSRC}/aq_hw.c
13.1-STABLEでの注意点は、1301508から1301509の間にABI変更があり、1301508環境でビルドしたモジュールを1301509なカーネルに読み込むと、aq0を認識する所までは問題ない進むが、通信を開始するとpanicする
この状態になってしまうと、コンソールでloader menuにアクセスする必要があるので、リモート運用だと注意が必要
更新手順としては次のようなパターンが考えられる。
特に後者の手順(別途、ビルド環境が必要だが)だとリモート更新できるが、失敗するとコンソールに走るハメになる
遠隔地の場合はZFS-BEを活用してpanicからの再起動時に旧環境から起動するように仕込むなどの準備が必要
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記
_ Y氏 [じゃぁ、スイスにいったらチーズフォンデューに挑戦してください (^^]