- 投稿日：2020-03-23T22:13:39+09:00
CentOS Linux 8 + Apache mod_ssl で https サーバへのリバースプロキシを設定する
概要
- CentOS Linux 8 に Apache HTTP Server と mod_ssl をインストールして https サーバへのリバースプロキシを設定する
環境
- CentOS Linux 8
- Apache HTTP Server 2.4.37
$ cat /etc/centos-release CentOS Linux release 8.1.1911 (Core)Apache のインストール
dnf install コマンドで httpd パッケージをインストールする。
$ sudo dnf install httpdインストールされたのを確認する。
$ dnf list --installed httpd インストール済みパッケージ httpd.x86_64 2.4.37-16.module_el8.1.0+256+ae790463 @AppStream $ which httpd /usr/sbin/httpd $ httpd -v Server version: Apache/2.4.37 (centos) Server built: Dec 23 2019 20:45:34 $ httpd -V Server version: Apache/2.4.37 (centos) Server built: Dec 23 2019 20:45:34 Server's Module Magic Number: 20120211:83 Server loaded: APR 1.6.3, APR-UTIL 1.6.1 Compiled using: APR 1.6.3, APR-UTIL 1.6.1 Architecture: 64-bit Server MPM: event threaded: yes (fixed thread count) forked: yes (variable process count) Server compiled with.... -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=256 -D HTTPD_ROOT="/etc/httpd" -D SUEXEC_BIN="/usr/sbin/suexec" -D DEFAULT_PIDLOG="run/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf"systemd の httpd サービスを有効にする。
$ sudo systemctl enable httpd Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.Apache の起動
systemctl start コマンドで Apache を起動する。
$ sudo systemctl start httpdApache の状態を確認する。
$ systemctl status httpd ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2020-03-23 21:55:04 JST; 7min ago Docs: man:httpd.service(8)Apache の設定ファイル
/etc/httpd/ 以下に Apache の設定ファイルがある。
メインの設定ファイルは /etc/httpd/conf/httpd.conf で、このファイルが他の設定ファイルを Include ディレクティブで追加している。$ tree /etc/httpd/ /etc/httpd/ ├── conf │ ├── httpd.conf │ └── magic ├── conf.d │ ├── README │ ├── autoindex.conf │ ├── userdir.conf │ └── welcome.conf ├── conf.modules.d │ ├── 00-base.conf │ ├── 00-dav.conf │ ├── 00-lua.conf │ ├── 00-mpm.conf │ ├── 00-optional.conf │ ├── 00-proxy.conf │ ├── 00-systemd.conf │ ├── 01-cgi.conf │ ├── 10-h2.conf │ ├── 10-proxy_h2.conf │ └── README ├── logs -> ../../var/log/httpd ├── modules -> ../../usr/lib64/httpd/modules ├── run -> /run/httpd └── state -> ../../var/lib/httpd 7 directories, 17 filesmod_ssl のインストール
dnf install コマンドで mod_ssl パッケージをインストールする。
$ sudo dnf install mod_ssl設定ファイル ssl.conf と 00-ssl.conf が増えているので、必要に応じて Include ディレクティブで追加する。
$ find /etc/httpd | grep ssl /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.modules.d/00-ssl.confリバースプロキシの設定
例えば以下のような内容を /etc/httpd/conf/httpd.conf の設定ファイルに記述する。
今回は Include ディレクティブを使わず1つの設定ファイルにまとめた。ServerRoot "/etc/httpd" LoadModule authz_core_module modules/mod_authz_core.so LoadModule mpm_event_module modules/mod_mpm_event.so LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule unixd_module modules/mod_unixd.so LoadModule ssl_module modules/mod_ssl.so LoadModule systemd_module modules/mod_systemd.so Listen 80 User apache Group apache ErrorLog "logs/error_log" ProxyRequests Off SSLProxyEngine On ProxyPass /foobar/ https://hogehoge.example.com/foobar/ ProxyPassReverse /foobar/ https://hogehoge.example.com/foobar/設定ファイルが間違っていないか apachectl configtest コマンドで確認できる。
$ apachectl configtest Syntax OK設定が間違っていなければ Apache を再起動して、設定を反映する。
$ sudo systemctl restart httpdcurl 等でアクセスしてコンテンツ生成元のサーバからレスポンスが返ってきているのを確認する。
$ curl --include --silent http://localhost/foobar/ | head HTTP/1.1 200 OK Date: Mon, 23 Mar 2020 13:05:09 GMT Server: Foobar Frontend Content-Type: text/html;charset=utf-8 Content-Length: 9876 <!DOCTYPE html> <html> <head> <title>Hello, world.</title>参考資料
- 投稿日：2020-03-23T21:29:19+09:00
ローカル環境にファイルサーバを構築してみた
▼下記OSを使用
CentOS Linux release 7.7.1908 (Core)やったこと
- sambaのインストール
- smb.confの編集
- ユーザの作成
- 共有ディレクトリの作成とパーミッションの変更
- samba起動・自動起動設定
- ローカル使用での設定
- クライアントから接続確認
※今回は全てルートユーザで実施しました
sambaのインストール
yum -y install samba samba-commonsmb.confの編集
cd /etc/samba#念のためバックアップ cp -p smb.conf smb.conf.20200323vi smb.confsmb.conf[global] workgroup = SAMBA security = user netbios name = neko #追記 passdb backend = tdbsam #printing = cups #printcap name = cups load printers = no #cups options = raw dos charset = CP932 wins support = yes disable spoolss = yes unix charset = UTF-8 mangled names = no vfs objects = catia catia:mappings = 0x22:0xa8,0x2a:0xa4,0x2f:0xf8,0x3a:0xf7,0x3c:0xab,0x3e:0xbb,0x3f:0xbf,0x5c:0xff,0x7c:0xa6 [neko] comment = Share Folder for All Users path = /var/mnt/ browsable = yes writable = yes read only = no [homes] comment = Home Directories valid users = %S, %D%w%S browseable = No read only = No inherit acls = Yes [printers] comment = All Printers path = /var/tmp printable = Yes create mask = 0600 browseable = No [print$] comment = Printer Drivers path = /var/lib/samba/drivers write list = @printadmin root force group = @printadmin create mask = 0664 directory mask = 0775文字コードはCP932、プリンターを使用しない、シェア名は[neko]、Pathは /var/mnt などを設定しました。
必要なものは追加・変更してください。ユーザの作成
useradd -M share_user#パスワードを設定 passwd share_user# 認証用パスワードを設定（share_userと同じパスワードにする） pdbedit -a -u share_user -f "share user"共有ディレクトリの作成とパーミッションの変更
mkdir /var/mntchmod 777 /var/mntsamba起動・自動起動設定
systemctl start smb nmbsystemctl enable smb nmbsystemctl status smb nmb※sambaの起動と自動起動設定がenableになっていることを確認する
ローカル使用での設定
▼SELinuxの無効化
#次回以降起動時にSELinuxをOFFにする設定 setenforce 0vi /etc/selinux/config→ SELINUX=disabled に設定
▼firewallの停止
systemctl stop firewalldsystemctl disable firewalldクライアントから接続確認
▽Windows
エクスプローラを開いて以下にアクセス\\[サーバ名またはサーバIP]\neko # 今回の場合▽Mac
Finder上でCmd+Ksmb://[サーバ名またはサーバIP]/おしまい
今回はファイルサーバを構築してみました。
もちろんスマホからのアクセスも可能です。
不要なPCなど転がっていたら有効活用してみてはいかがでしょうか？(^^)
- 投稿日：2020-03-23T20:33:34+09:00
新人エンジニアが知っておきたいサーバ負荷の考え方
10年ほど前、エンジニア駆け出しの頃のブログを再認識兼ねてリバイバルします。
最近はサーバにsshで繋いで確認すると言う機会も減りましたが、覚えておいて損はないです。
https://itinao.hatenadiary.org/ある日の出来事
エンジニア成り立ての僕。
出勤して早々、キラキラな営業さんや企画の方からこんなこと言われます。営業「ちょっとなんかサーバが重いんだけど」
企画「なんとかして！仕事にならないよ」僕「やべ、調査の仕方わからへん。」
僕「すみません。先輩にすぐ連絡します。」プログラマーの僕はインフラ側の知識、知見が足りてません。
なんとかしたいけど、どうすることもできず。。自社サービス運用していると良くある光景ですね。
やっぱりなんとかしたい！
報連相は大切だけどやっぱりエンジニア。
自分でなんとか出来るようになりたいと思いますよね。
そんな方へ。まずはボトルネックの考え方を学びましょう。ボトルネックの考え方は大きく2つ
1. CPU負荷 2. I/O負荷1. CPU負荷ってなんぞ？
プロセスがCPUを占有している(CPUが計算している)状態
あるプロセス(プログラム)がCPUを使い使用率100%の状態が長く続いてしまった場合、他のプロセスの実行を妨害してしまいます。
一つ語弊があると困りますが、CPU使用率100％自体は悪ではなく、ディスクやメモリ容量などの他にボトルネックがなければ理想的な状態です。
CPU100%が急に続くようであれば
プログラムが暴走（無限ループ等）していないか確認する。 直近のリリースバージョン内の処理を見直す。2. じゃCPU負荷とI/O負荷の違いは？
I/Oとは入出力(Input/Output)の意味です。
頻繁にデータを出し入れすることにより、ハードウェアやネットワークに負荷がかかることで、CPU負荷とI/O負荷は別物です。CPU負荷が高いからと言って必ずしもI/Oが遅くなるわけではなく、あくまでもディスクへ大量の読み書きが発生している状態です。I/O負荷が続くようであれば
ファイルに入出力ようなプログラムが多くないか？ メモリ不足でスワップが発生してディスクアクセスが発生していないか？メモリが足らないとシステムはスワップを使います。
逆に言うとスワップに対してのアクセスが多い場合はメモリ不足の可能性があります。ボトルネック調査手順
ここまでCPU負荷とI/O負荷の概念を見てきました。
次に早速、CPU負荷とI/O負荷についてのボトルネックの調査方法に入っていきます。1. まずは心を落ち着かせます。これ大事。 2. topでロードアベレージを確認します。 3. sarでCPUとI/O負荷どちらが高いか確認します。 4. psで各プロセスの情報を見ます。 5. 実行プログラムの見直しやバージョンを戻すなどの対応をします 6. 途中でとめて問題ない場合は悪さをしているプロセスをkillしたり再起動します。1. まずは心を落ちつかせる
これはどんな時も大切です。
周りに早くなんとかしろと言う視線が痛いですが、パニックになってはいけません。太々しいほど落ちき対応をしましょう。
2. すぐにTOPコマンド
とにかくまずはTOPコマンドでロードアベレージを見ましょう。
ロードアベレージとは
1CPUにおける単位時間あたりの実行待ちとディスクI/O待ちのプロセスの数。
単位時間当たりにどの程度のタスクが待ち状態にあったかを報告する数値です。
これが高いとシステムへの負荷が高いということです。ロードアベレージが高いとは
コア数よりロードアベレージが高ければ負荷の原因になる可能性があります。
$top top - 00:41:49 up 6 days, 2:24, 1 user, load average: 2.15, 3.02, 3.20 Tasks: 93 total, 1 running, 45 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.2 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 3977928 total, 3324844 free, 121568 used, 531516 buff/cache KiB Swap: 0 total, 0 free, 0 used. 3630656 avail Memload average: 2.15, 3.02, 3.20という表示がロードアベレージです。
左から直近1分, 5分, 15分間の値です。見るべきものは以下２つ
load averageの状態がコア数を超えてないか。 Swapは発生していないか。次にコアごとの負荷状況を見て行きましょう。
2. sarコマンドでCPU使用率とI/O待ち率を見る
マルチコアの場合ロードアベレージだけでは判断がつかないことがあります。
そんなときは合わせてsar -P ALLで各CPUの状態を個別に把握しましょう。
マルチCPUが搭載されていてもディスクは１つしかない場合、CPU負荷は他のCPUに分散できてもI/Oは分散できないため負荷原因となります。$ sar -P ALL Linux 3.10.0-862.2.3.el7.x86_64 (118-27-1-88) 10/01/2018 _x86_64_ (2 CPU) 01:17:35 AM CPU %user %nice %system %iowait %steal %idle 01:17:36 AM all 0.00 0.00 0.00 0.00 0.00 100.00 01:17:36 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 01:17:36 AM 1 0.00 0.00 0.00 0.00 0.00 100.00それぞれの意味はこちらになります。
表示 説明 %user CPUがユーザモードにあった時間の割合 %system CPUがカーネルモードにあった時間の割合 %iowait CPUがIO待ちをしていた時間の割合 %idle CPUがアイドル状態にあった時間の割合 見るべきものは以下
%idleが小さいとCPUの使用率が高いのでCPUがボトルネックになっている可能性があります。CPUに割り当てられるプロセスの状態遷移をpsコマンドで確認
CPUが負荷の原因とわかった場合は
次ににどのプロセスが悪さをしているのかを把握しましょう。$ ps auwx | head USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 19232 1516 ? Ss Feb09 0:00 /sbin/init root 2 0.0 0.0 0 0 ? S Feb09 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S Feb09 0:00 [migration/0] root 4 0.0 0.0 0 0 ? S Feb09 0:00 [ksoftirqd/0] root 5 0.0 0.0 0 0 ? S Feb09 0:00 [stopper/0] root 6 0.0 0.0 0 0 ? S Feb09 0:06 [watchdog/0] root 7 0.0 0.0 0 0 ? S Feb09 0:00 [migration/1] root 8 0.0 0.0 0 0 ? S Feb09 0:00 [stopper/1] root 9 0.0 0.0 0 0 ? S Feb09 0:00 [ksoftirqd/1]それぞれの意味は下記を参照ください。
表示 説明 %CPU プロセスのCPU使用率 %MEM プロセスの物理メモリ VSZ(RSS) プロセスが確保している仮想(物理)メモリ領域 STAT プロセスの状態 TIME プロセスがCPUを占有した時間 STAT(プロセスステータス)について
CPU上で実行可能なプロセスはTASK_RUNNING状態になっています。
複数あるTASK_RUNNING状態のプロセスのうち最も高いプライオリティを持つタスクにCPUが与えられます。
表記 状態 説明 R TASK_RUNNING 実行可能状態 S TASK_INTERRUPTIBLE 待ち状態。シグナル受信可能 D TASK_UNINTERRUPTIBLE 待ち状態。シグナル受信不可 Z TASK_ZOMBIE ゾンビ状態。exit後の状態 T TASK_STOPPED サスペンド状態 見るべきものは以下２つ
RSSのサイズを見て極端に大きなプロセスがないか確認する。 TIMEの状態をみます。無限ループ(TASK_RUNNING)の場合、TIMEが増加し続けます。スワップが発生している場合
TOPコマンドでスワップが発生している場合には物理メモリ不足が原因となる可能性があります。
sarコマンドでさらに細かくみていきます。$ sar -S 00時00分01秒 kbswpfree kbswpused %swpused kbswpcad %swpcad 00時10分01秒 2097148 0 0.00 0 0.00 00時20分01秒 2097148 0 0.00 0 0.00 00時30分01秒 2097148 0 0.00 0 0.00 00時40分01秒 2097148 0 0.00 0 0.00
状態 説明 kbswpfree スワップ領域の空き容量 kbswpused スワップ領域の使用容量 %swpused スワップ領域の使用量割合 kbswpcad スワップ領域のキャッシュ容量 こちらでどの程度Swapが発生しているのか確認した上、
vmstatでvmstat 1 100 のようにインターバルを指定して見るとわかりやすい$ vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 244208 10312 1552 62636 4 23 98 249 44 304 28 3 68 1 0 0 2 244920 6852 1844 67284 0 544 5248 544 236 1655 4 6 0 90 0 1 2 256556 7468 1892 69356 0 3404 6048 3448 290 2604 5 12 0 83 0 0 2 263832 8416 1952 71028 0 3788 2792 3788 140 2926 12 14 0 74 0 0 3 274492 7704 1964 73064 0 4444 2812 5840 295 4201 8 22 0 69 0
表示 説明 r 実行待ちプロセス数 b スリープ（割り込み可能）のプロセス数、実行できてないプロセス数 swpd スワップサイズ（KB） free 空きメモリ（KB） buff バッファメモリサイズ（KB） cache キャッシュメモリサイズ（KB） si ディスクからスワップインされているメモリサイズ（KB/秒） so ディスクへスワップアウトされているメモリサイズ（KB/秒） bi ブロックデバイスから受け取ったブロック数（ブロック/秒） bo ブロックデバイスに送られたブロック数（ブロック/秒） in 割り込み回数/秒 cs コンテキストスイッチ回数/秒 us ユーザプロセスのCPU使用時間割合 sy カーネルコードの実行に使用した時間 id CPUがアイドル状態の時間割合 wa CPUがI/O待ち st ゲストOSがCPUを割り当てられなかった時間の割合 r、bは通常は0~2程度。 この数値が大きい場合サーバ重いと感じる可能性があります。 si、soは常時ゼロが基本。 ここに常時数値が現れることはメモリ不足か、メモリを食ってしまうプログラムがあるのどちらかです。負荷対策まとめ
まずはCPUかI/Oかを以下のコマンドで判断する
top sar ps vmstat対処法としては
CPU負荷が高い場合
サーバ増設やプログラムのロジック、アルゴリズムの改善I/O負荷が高い場合
メモリ増設でキャッシュ領域を拡大する メモリ増設不可なら、データの分散やキャッシュサーバの導入を検討 プログラムの改善でI/O頻度を軽減するふう、まとめるの疲れました。
これで負荷の原因を説明できるようになったら良いな。
- 投稿日：2020-03-23T14:46:05+09:00
Ultra96/Ultra96-V2 向け Debian GNU/Linux で XRT(Xilinx Runtime) を動かす(ビルド編)【未完】
はじめに
XRT(Xilinx Runtime) は Xilinx社が提供する開発環境(Vitis)で開発したプログラムをプラットフォームで動かすための環境です。XRT はユーザー空間とカーネルドライバのコンポーネントの組み合わせとして実装されています。XRT は github で ソースコードが公開されています。
下図に XRT のソフトウェアスタックを示します(上のgithub リポジトリ より引用)。
Fig.1 XRT Software Stack
筆者はgithub に UltraZed/Ultra96/Ultra96-V2 のプラットフォームとして Debian GNU/Linux をビルドして提供しています。
XRT は Xilinx 社が提供する Petalinux を前提にしているのですが、ZynqMP-FPGA-Linux で提供している Debian GNU/Linux でも動かしてみたいと思います。
この記事では、XRT をソースコードからビルドして Debian パッケージを作るまでを説明します。
なお、ビルド済みの Debian Package は github で公開しています。ビルドする環境を構築するのも大変だしビルドする時間も１〜２時間かかるので、面倒な人はこちらからダウンロードしてください。
https://github.com/ikwzm/ZynqMP-FPGA-XRT
- xrt_202010.2.6.0_Ubuntu_18.04-arm64-xrt.deb
- zocl-dkms_2.6.0_arm64.deb
また、インストールには次の記事を参照してください。
注意
現時点(2020年3月23日)では、一応インストールは出来るものの、まだ動作していません。この記事はあくまでもトライアルの防備録です。
XRT のビルド
ビルド環境
XRT を UltraZed/Ultra96/Ultra96-V2 向けにビルドするのは少し面倒です。XRT のビルドには Ubuntu や CentOS などの Linux ディストリビューションが必要です。ビルドには色々な開発ツールがインストールされていなければなりません。さらに Debian Package を作るためか、PC をホストにして ARM64 用にクロスコンパイルするのがとても面倒です。
そこで、 Ultra96-V2 に Ubuntu 18.04 を動かして、その上でセルフビルドします。
Ultra96-V2 用の Ubuntu 18.04 は以下の URL で公開しています。
XRT のダウンロード
以下の URL より XRT のソースコードをダウンロードします。
fpga@ubuntu-fpga:~$ cd work fpga@ubuntu-fpga:~/work$ git clone https://github.com/Xilinx/XRT Cloning into 'XRT'... remote: Enumerating objects: 30, done. remote: Counting objects: 100% (30/30), done. remote: Compressing objects: 100% (30/30), done. remote: Total 43591 (delta 13), reused 7 (delta 0), pack-reused 43561 Receiving objects: 100% (43591/43591), 58.10 MiB | 2.57 MiB/s, done. Resolving deltas: 100% (33849/33849), done. Checking out files: 100% (1682/1682), done. fpga@ubuntu-fpga:~/work$ cd XRT fpga@ubuntu-fpga:~/work/XRT$XRT を Ultra96/Ultra96-V2 用にビルドするためにはいくつかファイルを修正します。ですので、https://github.com/Xilinx/XRT を直接 clone するよりも、fork したほうが良いでしょう。
XRT の変更
XRT のビルド用ファイルにいくつかの修正をしますので、ブランチを作成します。
fpga@ubuntu-fpga:~/work/XRT$ git checkout -b 2019.2_Ultra96 Switched to a new branch '2019.2_Ultra96'パッケージファイル名を変更
オリジナルの XRT では、ビルドした Debian Package の名前は xrt_202010.2.6.0_18.04-arm64-xrt.deb になりますが、Ubuntu 用のパッケージであることを明示するためにxrt_202010.2.6.0_Ubuntu_18.04-arm64-xrt.deb にします。
fpga@ubuntu-fpga:~/work/XRT$ git diff src/CMake/cpackLin.cmake diff --git a/src/CMake/cpackLin.cmake b/src/CMake/cpackLin.cmake index 4f45f97a..9f6eebe4 100644 --- a/src/CMake/cpackLin.cmake +++ b/src/CMake/cpackLin.cmake @@ -79,7 +79,7 @@ else () SET (CPACK_GENERATOR "TGZ") endif() -SET(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}_${XRT_VERSION_RELEASE}.${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}_${CPACK_REL_VER}-${CPACK_ARCH}") +SET(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}_${XRT_VERSION_RELEASE}.${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}_${LINUX_FLAVOR}_${CPACK_REL_VER}-${CPACK_ARCH}") message("-- ${CMAKE_BUILD_TYPE} ${PACKAGE_KIND} package") fpga@ubuntu-fpga:~/work/XRT$ git add src/CMake/cpackLin.cmake fpga@ubuntu-fpga:~/work/XRT$ git commit -m "[add] linux flavor name to built debian package name" [2019.2_Ultra96 f6d3236b] [add] linux flavor name to built debian package name 1 file changed, 1 insertion(+), 1 deletion(-)依存する Debian Package のバージョンの上限を撤廃
オリジナルでは、ビルドした Debian Package が依存する Packageは src/CMake/cpackLin.cmake で次のように設定されています。
src/CMake/cpackLin.cmakeSET(CPACK_DEBIAN_XRT_PACKAGE_DEPENDS "ocl-icd-opencl-dev (>= 2.2.0), libboost-dev (>= ${Boost_VER_STR}), libboost-dev (<< ${Boost_VER_STR_ONEGREATER}), libboost-filesystem-dev (>=${Boost_VER_STR}), libboost-filesystem-dev (<<${Boost_VER_STR_ONEGREATER}), uuid-dev (>= 2.27.1), dkms (>= 2.2.0), libprotoc-dev (>=2.6.1), libssl-dev (>=1.0.2), protobuf-compiler (>=2.6.1), libncurses5-dev (>=6.0), lsb-release, libxml2-dev (>=2.9.1), libyaml-dev (>= 0.1.6), libc6 (>= ${GLIBC_VERSION}), libc6 (<< ${GLIBC_VERSION_ONEGREATER}), python (>= 2.7), python-pip, libudev-dev ")ビルドした Debian Package が依存する Package のうち、libboost-dev、libboost-filesystem-dev、libc6 のバージョンに上限が設定されています。これだと、インストールするディストリビューションの制約が強すぎてインストールに失敗することがあります。例えば、この Debian Package を Debian10 にインストールを試みると失敗します。
そこで、後で問題になるかもしれませんが、次のように cpackLin.cmake を修正してバージョンの上限を撤廃します。
fpga@ubuntu-fpga:~/work/XRT$ git diff src/CMake/cpackLin.cmake --- a/src/CMake/cpackLin.cmake +++ b/src/CMake/cpackLin.cmake @@ -49,7 +49,7 @@ if (${LINUX_FLAVOR} MATCHES "^(Ubuntu|Debian)") SET(CPACK_DEBIAN_PACKAGE_SHLIBDEPS "OFF") SET(CPACK_DEBIAN_AWS_PACKAGE_DEPENDS "xrt (>= ${XRT_VERSION_MAJOR}.${XRT_VERSION_MINOR}.${XRT_VERSION_PATCH})") SET(CPACK_DEBIAN_XBTEST_PACKAGE_DEPENDS "xrt (>= ${XRT_VERSION_MAJOR}.${XRT_VERSION_MINOR}.${XRT_VERSION_PATCH}), libjson-glib-dev") - SET(CPACK_DEBIAN_XRT_PACKAGE_DEPENDS "ocl-icd-opencl-dev (>= 2.2.0), libboost-dev (>= ${Boost_VER_STR}), libboost-dev (<< ${Boost_VER_STR_ONEGREATER}), libboost-filesystem-dev (>=${Boost_VER_STR}), libboost-filesystem-dev (<<${Boost_VER_STR_ONEGREATER}), uuid-dev (>= 2.27.1), dkms (>= 2.2.0), libprotoc-dev (>=2.6.1), libssl-dev (>=1.0.2), protobuf-compiler (>=2.6.1), libncurses5-dev (>=6.0), lsb-release, libxml2-dev (>=2.9.1), libyaml-dev (>= 0.1.6), libc6 (>= ${GLIBC_VERSION}), libc6 (<< ${GLIBC_VERSION_ONEGREATER}), python (>= 2.7), python-pip, libudev-dev ") + SET(CPACK_DEBIAN_XRT_PACKAGE_DEPENDS "ocl-icd-opencl-dev (>= 2.2.0), libboost-dev (>= ${Boost_VER_STR}), libboost-filesystem-dev (>=${Boost_VER_STR}), uuid-dev (>= 2.27.1), dkms (>= 2.2.0), libprotoc-dev (>=2.6.1), libssl-dev (>=1.0.2), protobuf-compiler (>=2.6.1), libncurses5-dev (>=6.0), lsb-release, libxml2-dev (>=2.9.1), libyaml-dev (>= 0.1.6), libc6 (>= ${GLIBC_VERSION}), python (>= 2.7), python-pip, libudev-dev ") elseif (${LINUX_FLAVOR} MATCHES "^(RedHat|CentOS|Amazon)") execute_process( fpga@ubuntu-fpga:~/work/XRT$ git add src/CMake/cpackLin.cmake fpga@ubuntu-fpga:~/work/XRT$ git commit -m "[remove] upper limit of version of depend packages" [2019.2_Ultra96 b69d97cd] [remove] upper limit of version of depend packages 1 file changed, 1 insertion(+), 1 deletion(-)ビルドに必要な Debian Package をインストール
ビルドに必要なパッケージをインストールします。幸い XRT には、ビルドに必要なパッケージをインストールするスクリプトが用意されています。
./src/runtime_src/tools/scripts/xrtdeps.sh を super user 権限で実行すると、apt プログラムにより足りない Debian Package がインストールされます。
fpga@ubuntu-fpga:~/work/XRT$ sudo ./src/runtime_src/tools/scripts/xrtdeps.sh Installing packages... Reading package lists... Done Building dependency tree Reading state information... Done : (中略) : The following packages were automatically installed and are no longer required: libgl2ps1.4 libibverbs1 liblept5 libnetcdf-c++4 libnl-route-3-200 libopencv-flann-dev libopencv-flann3.2 libopencv-ml-dev libopencv-ml3.2 libopencv-photo-dev libopencv-photo3.2 libopencv-shape-dev libopencv-shape3.2 libopencv-ts-dev libopencv-video-dev libopencv-video3.2 libtcl8.6 libtesseract4 libtk8.6 libxss1 Use 'sudo apt autoremove' to remove them. 0 upgraded, 0 newly installed, 0 to remove and 26 not upgraded.ビルド
build ディレクトリに移動して、そこにある build.sh を実行することで、ビルドが開始されます。Ultra96/Ultra96-V2 だとけっこう時間がかかります。私の環境では１〜２時間ほどかかりました。
fpga@ubuntu-fpga:~/work/XRT$ cd build/ fpga@ubuntu-fpga:~/work/XRT/build$ ./build.sh cmake -DRDI_CCACHE=0 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_TOOLCHAIN_FILE= ../../src -- The C compiler identification is GNU 8.3.0 -- The CXX compiler identification is GNU 8.3.0 -- Check for working C compiler: /usr/bin/gcc-8 -- Check for working C compiler: /usr/bin/gcc-8 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/g++-8 -- Check for working CXX compiler: /usr/bin/g++-8 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Host system processor is aarch64 -- Target system processor is aarch64 : (後略) : fpga@ubuntu-fpga:~/work/XRT/build$ビルドが終了すると、build/Release ディレクトリの下に Debian Package が出来ています。
fpga@ubuntu-fpga:~/work/XRT$ cd build/ fpga@ubuntu-fpga:~/work/XRT/build$ ls -1 Release/xrt_* Release/xrt_202010.2.6.0_Ubuntu_18.04-arm64-aws.deb Release/xrt_202010.2.6.0_Ubuntu_18.04-arm64-aws.tar.gz Release/xrt_202010.2.6.0_Ubuntu_18.04-arm64-azure.deb Release/xrt_202010.2.6.0_Ubuntu_18.04-arm64-azure.tar.gz Release/xrt_202010.2.6.0_Ubuntu_18.04-arm64-container.deb Release/xrt_202010.2.6.0_Ubuntu_18.04-arm64-container.tar.gz Release/xrt_202010.2.6.0_Ubuntu_18.04-arm64-xbtest.deb Release/xrt_202010.2.6.0_Ubuntu_18.04-arm64-xbtest.tar.gz Release/xrt_202010.2.6.0_Ubuntu_18.04-arm64-xrt.deb Release/xrt_202010.2.6.0_Ubuntu_18.04-arm64-xrt.tar.gzこのうち Ultra96/Ultra96-V2 に必要な Debian Package は、Release/xrt_202010.2.6.0_Ubuntu_18.04-arm64-xrt.deb です。
zocl のビルド
前章でビルドした xrt_202010.2.6.0_Ubuntu_18.04-arm64-xrt.deb には zocl が含まれていません(zocl は Fig.1 XRT Software Stack を参照)。zocl は Ultra96/Ultra96-V2 などの Edge Device 用の Linux カーネルモジュールです。
そこでこの章では zocl の Debian Package をビルドする方法を説明します。ここでは dkms を使ってビルドします。
ソースディレクトリの生成
まず、/usr/src/ の下に zocl-2.6.0 というディレクトリを作ります。zocl はカーネルモジュールの名前、2.6.0 は XRT のバージョン番号です。
fpga@ubuntu-fpga:~/work/XRT$ sudo mkdir /usr/src/zocl-2.6.0 fpga@ubuntu-fpga:~/work/XRT$ sudo chmod o+w /usr/src/zocl-2.6.0ソースファイルの準備
zocl のソースコードは XRT の src/runtime_src/core/edge/drm/zocl にあります。さらに他のディレクトリにあるいくつかのヘッダファイルも必要です。これらのファイルを前節で用意したディレクトリにコピーします。
fpga@ubuntu-fpga:~/work/XRT$ mkdir /usr/src/zocl-2.6.0/src fpga@ubuntu-fpga:~/work/XRT$ mkdir /usr/src/zocl-2.6.0/src/edge fpga@ubuntu-fpga:~/work/XRT$ mkdir /usr/src/zocl-2.6.0/src/edge/drm fpga@ubuntu-fpga:~/work/XRT$ cp -r src/runtime_src/core/edge/drm/zocl /usr/src/zocl-2.6.0/src/edge/drm fpga@ubuntu-fpga:~/work/XRT$ cp -r src/runtime_src/core/include/ /usr/src/zocl-2.6.0/src fpga@ubuntu-fpga:~/work/XRT$ cp -r src/runtime_src/core/edge/include /usr/src/zocl-2.6.0/src/edge/ fpga@ubuntu-fpga:~/work/XRT$ cp src/runtime_src/core/common/drv/xrt_drv.h /usr/src/zocl-2.6.0/src/edge/drm/zocl fpga@ubuntu-fpga:~/work/XRT$ cp LICENSE /usr/src/zocl-2.6.0/ビルド用ツールのインストール
ビルドするためには次のツールがインストールされていなければなりません。
- dkms
- debhelper
- fakeroot
dkms.conf の作成
次のような /usr/src/zocl-2.6.0/dkms.conf を作成します。
/usr/src/zocl-2.6.0/dkms.confPACKAGE_NAME="zocl-dkms" PACKAGE_VERSION="2.6.0" MAKE="make -C src/edge/drm/zocl/ KERNELDIR=/lib/modules/${kernelver}/build" CLEAN="make -C src/edge/drm/zocl/ clean" BUILT_MODULE_NAME="zocl" BUILT_MODULE_LOCATION="src/edge/drm/zocl/" DEST_MODULE_LOCATION="/updates"dkms に追加
dkms に zocl-2.6.0 を追加します。
fpga@ubuntu-fpga:/usr/src/zocl-2.6.0$ sudo dkms add -m zocl -v 2.6.0 Creating symlink /var/lib/dkms/zocl/2.6.0/source -> /usr/src/zocl-2.6.0 DKMS: add completed.カーネルモジュールのビルド
試しに dkms を使ってカーネルモジュールをビルドしてみて、成功することを確認します。
fpga@ubuntu-fpga:/usr/src/zocl-2.6.0$ sudo dkms build -m zocl -v 2.6.0 Kernel preparation unnecessary for this kernel. Skipping... Building module: cleaning build area... make -j4 KERNELRELEASE=4.19.0-xlnx-v2019.2-zynqmp-fpga -C src/edge/drm/zocl/ KERNELDIR=/lib/modules/4.19.0-xlnx-v2019.2-zynqmp-fpga/build....... cleaning build area... DKMS: build completed.Debian src package のビルド
fpga@ubuntu-fpga:/usr/src/zocl-2.6.0$ sudo dkms mkdsc -m zocl -v 2.6.0 --source-only Using /etc/dkms/template-dkms-mkdsc copying template... modifying debian/changelog... modifying debian/compat... modifying debian/control... modifying debian/copyright... modifying debian/dirs... modifying debian/postinst... modifying debian/prerm... modifying debian/README.Debian... modifying debian/rules... copying legacy postinstall template... Copying source tree... Building source package... dpkg-source --before-build zocl-dkms-2.6.0 debian/rules clean dh_clean: Compatibility levels before 9 are deprecated (level 7 in use) dpkg-source -b zocl-dkms-2.6.0 dpkg-source: warning: no source format specified in debian/source/format, see dpkg-source(1) dpkg-genbuildinfo --build=source dpkg-genchanges --build=source >../zocl-dkms_2.6.0_source.changes dpkg-genchanges: info: including full source code in upload dpkg-source --after-build zocl-dkms-2.6.0 DKMS: mkdsc completed. Moving built files to /var/lib/dkms/zocl/2.6.0/dsc... Cleaning up temporary files...ここでビルドした Debian Package は /var/lib/dkms/zocl/2.6.0/dsc にあります。
- /var/lib/dkms/zocl/2.6.0/dsc/zocl-dkms_2.6.0.dsc
- /var/lib/dkms/zocl/2.6.0/dsc/zocl-dkms_2.6.0_source.changes
- /var/lib/dkms/zocl/2.6.0/dsc/zocl-dkms_2.6.0_tar.gz
Debian binary package のビルド
fpga@ubuntu-fpga:/usr/src/zocl-2.6.0$ sudo dkms mkdeb -m zocl -v 2.6.0 --source-only Using /etc/dkms/template-dkms-mkdeb copying template... modifying debian/changelog... modifying debian/compat... modifying debian/control... modifying debian/copyright... modifying debian/dirs... modifying debian/postinst... modifying debian/prerm... modifying debian/README.Debian... modifying debian/rules... copying legacy postinstall template... Copying source tree... Building binary package...dpkg-buildpackage: warning: using a gain-root-command while being root dpkg-source --before-build zocl-dkms-2.6.0 fakeroot debian/rules clean dh_clean: Compatibility levels before 9 are deprecated (level 7 in use) debian/rules build fakeroot debian/rules binary dh_installdirs: Compatibility levels before 9 are deprecated (level 7 in use) dh_strip: Compatibility levels before 9 are deprecated (level 7 in use) dh_compress: Compatibility levels before 9 are deprecated (level 7 in use) dh_installdeb: Compatibility levels before 9 are deprecated (level 7 in use) dh_shlibdeps: Compatibility levels before 9 are deprecated (level 7 in use) dpkg-genbuildinfo --build=binary dpkg-genchanges --build=binary >../zocl-dkms_2.6.0_arm64.changes dpkg-genchanges: info: binary-only upload (no source code included) dpkg-source --after-build zocl-dkms-2.6.0 DKMS: mkdeb completed. Moving built files to /var/lib/dkms/zocl/2.6.0/deb... Cleaning up temporary files...ここでビルドした Debian Package は /var/lib/dkms/zocl/2.6.0/deb にあります。
- /var/lib/dkms/zocl/2.6.0/deb/zocl-dkms_2.6.0_arm64.deb
Debian Package のコピー
前節でビルドした Debian Package をコピーします。
fpga@ubuntu-fpga:/usr/src/zocl-2.6.0$ cd ~/work/XRT/build fpga@ubuntu-fpga:~/work/XRT/build$ cp /var/lib/dkms/zocl/2.6.0/deb/* . fpga@ubuntu-fpga:~/work/XRT/build$ cp /var/lib/dkms/zocl/2.6.0/dsc/* .後始末
ビルドした Debian Package をインストールするためには、一度、dkms から zocl を削除して、Debian Package と競合しないようにする必要があります。
fpga@ubuntu-fpga:~/work/XRT/build$ sudo rm -r /var/lib/dkms/zocl/参考
- 投稿日：2020-03-23T14:42:11+09:00
Ultra96/Ultra96-V2 向け Debian GNU/Linux で XRT(Xilinx Runtime) を動かす(インストール編)【未完】
はじめに
次の記事で、Ultra96/Ultra96-V2 向け Debian GNU/Linux で XRT(Xilinx Runtime) を動かすための Debian Package をビルドする方法について説明しました。
この記事は、上の記事の続編で、実際に Ultra96/Ultra96-V2 向け Debian GNU/Linux にインストールする方法について説明します。
注意
現時点(2020年3月23日)では、一応インストールは出来るものの、まだ動作していません。この記事はあくまでもトライアルの防備録です。
対応するプラットフォーム
現時点でインストール出来ることを確認しているのは(注:クドいようですが現時点ではあくまでもインストールのみ)、次のプラットフォームのみです。
- ボード: Ultra96-V2
- Linux カーネル: Linux 4.19.0 (linux-xlnx 4.19.0 v2019.2)
- ディストリビューション: Ubuntu 18.04 or Debian10
Linux Kernel は以下の URL にあります。
ディストリビューションは以下の URL にあります。
- Debian10: https://github.com/ikwzm/ZynqMP-FPGA-Linux
- Ubuntu18.04: https://github.com/ikwzm/ZynqMP-FPGA-Ubuntu18.04-Ultra96
それぞれの URL を参照して Ultra96 にインストールしてください。また、以下の記事も参考にしてください。
Debian Packagesの入手
『Ultra96/Ultra96-V2 向け Debian GNU/Linux で XRT(Xilinx Runtime) を動かす(ビルド編)【未完】』@Qiitaで説明した方法で XRT の Debian Packageをビルドするか、次の URL にある Debian Package をダウンロードしてください。
https://github.com/ikwzm/ZynqMP-FPGA-XRT
- xrt_202010.2.6.0_Ubuntu_18.04-arm64-xrt.deb
- zocl-dkms_2.6.0_arm64.deb
インストールする前に
インストールする前に以下のパッケージをインストールしておいてください。
- ocl-icd-opencl-dev (>= 2.2.0)
- libboost-filesystem-dev (>=1.65)
- uuid-dev (>= 2.27.1)
- dkms (>= 2.2.0)
- libprotoc-dev (>=2.61)
- libssl-dev (>=1.0.2)
- protobuf-compiler (>=2.6.1)
- libncurses5-dev (>=6.0)
- lsb-release
- libxml2-dev (>=2.9.1)
- libyaml-dev (>= 0.1.6)
- libc6 (>= 2.27)
- python (>= 2.7)
- python-pip
- libudev-dev
上で紹介したパッケージは、xrt_202010.2.6.0_Ubuntu_18.04-arm64-xrt.deb をビルドした際に明示的に依存関係にあることを宣言したものです。
また、上記以外にも、以下のパッケージをインストールしておいてください。
- python-pyopencl
このパッケージがインストールされていないと、xrt_202010.2.6.0_Ubuntu_18.04-arm64-xrt.deb のインストールの際に pyopencl を pip でインストールしようとします。pip で pyopencl をインストールする場合は C で書かれたプログラムをコンパイルする必要があり、いろいろとトラブルが発生して結局インストールに失敗しました。最初から Debian/Ubuntu 用にビルド済みの pyopencl をインストールしておいたほうがトラブルが発生しなくて済みます。
XRT(Xilinx Runtime) Package のインストール
dpkg コマンドでxrt_202010.2.6.0_Ubuntu_18.04-arm64-xrt.deb をインストールします。なお、このパッケージをインストールする時、その工程の途中で、dkms の仕組みを使って xocl および xlmgmt カーネルモジュールをビルドします。そのためインストールに時間がかかります。
fpga@ubuntu-fpga:~$ cd work/ZynqMP-FPGA-XRT fpga@ubuntu-fpga:~/work/ZynqMP-FPGA-XRT$ sudo dpkg -i xrt_202010.2.6.0_Ubuntu_18.04-arm64-xrt.deb Selecting previously unselected package xrt. (Reading database ... 114575 files and directories currently installed.) Preparing to unpack xrt_202010.2.6.0_Ubuntu_18.04-arm64-xrt.deb ... Unpacking xrt (2.6.0) ... Setting up xrt (2.6.0) ... Unloading old XRT Linux kernel modules rmmod: ERROR: Module xocl is not currently loaded rmmod: ERROR: Module xclmgmt is not currently loaded Invoking DKMS common.postinst for xrt debconf: unable to initialize frontend: Dialog debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.) debconf: falling back to frontend: Readline Loading new xrt-2.6.0 DKMS files... Building for 4.19.0-xlnx-v2019.2-zynqmp-fpga Building initial module for 4.19.0-xlnx-v2019.2-zynqmp-fpgaカーネルモジュールのビルド中に、うかつに Ctrl-C 等で中断しないで、終わるまで待ってあげてください。
Done. xocl: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/4.19.0-xlnx-v2019.2-zynqmp-fpga/updates/dkms/ xclmgmt.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/4.19.0-xlnx-v2019.2-zynqmp-fpga/updates/dkms/ depmod... DKMS: install completed. Finished DKMS common.postinst Loading new XRT Linux kernel modules Installing MSD / MPD daemons Skipping pyopencl installation...zocl のインストール
dpkg コマンドで zocl-dkms_2.6.0_arm64.deb をインストールします。
fpga@ubuntu-fpga:~/work/ZynqMP-FPGA-XRT$ sudo dpkg -i zocl-dkms_2.6.0_arm64.deb Selecting previously unselected package zocl-dkms. (Reading database ... 114905 files and directories currently installed.) Preparing to unpack zocl-dkms_2.6.0_arm64.deb ... Unpacking zocl-dkms (2.6.0) ... Setting up zocl-dkms (2.6.0) ... debconf: unable to initialize frontend: Dialog debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.) debconf: falling back to frontend: Readline Loading new zocl-2.6.0 DKMS files... Building for 4.19.0-xlnx-v2019.2-zynqmp-fpga Building for architecture arm64 Building initial module for 4.19.0-xlnx-v2019.2-zynqmp-fpga Done. zocl: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/4.19.0-xlnx-v2019.2-zynqmp-fpga/updates/dkms/ depmod... DKMS: install completed.zocl はカーネルモジュールですが、insmod で Linux に組み込んだだけではダメで、デバイスツリーが必要です。ZynqMP-FPGA-Linux では Device Tree Overlay をサポートしてるので、次のようなデバイスツリーをオーバーレイすることによって zocl をアクティブにします。
zocl.dts/dts-v1/; /plugin/; / { fragment@1 { target-path = "/amba_pl@0"; __overlay__ { #address-cells = <2>; #size-cells = <1>; zyxclmm_drm { compatible = "xlnx,zocl"; status = "okay"; reg = <0x0 0xA0000000 0x10000>; }; }; }; };fpga@ubuntu-fpga:~/work/streaming_lap_filter5$ sudo ./dtbocfg.rb -i zocl --dts zocl.dts <stdin>:8.16-12.6: Warning (unit_address_vs_reg): /fragment@1/__overlay__/zyxclmm_drm: node has a reg or ranges property, but no unit name fpga@ubuntu-fpga:~/work/streaming_lap_filter5$ dmesg | tail -4 [ 8401.997049] [drm] Probing for xlnx,zocl [ 8401.997156] [drm] FPGA programming device pcap founded. [ 8401.997161] [drm] PR Isolation addr 0x0 [ 8401.997750] [drm] Initialized zocl 2018.2.1 20180313 for a0000000.zyxclmm_drm on minor 1現状
とりあえずXRT(Xilinx Runtime) のビルドとインストールは出来ました。ただし、XRT はまだ動いていません。FPGA の部屋の @marsee101 さんに Vitis で作ったサンプルを提供していただいて実行してみたところ、次のような結果になりました。
fpga@ubuntu-fpga:~/work/streaming_lap_filter5$ source /opt/xilinx/xrt/setup.sh XILINX_XRT : /opt/xilinx/xrt PATH : /opt/xilinx/xrt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:\\ /usr/bin:/sbin:/bin:/usr/games:/usr/local/games LD_LIBRARY_PATH : /opt/xilinx/xrt/lib: PYTHONPATH : /opt/xilinx/xrt/python: fpga@ubuntu-fpga:~/work/streaming_lap_filter5$ ./streaming_lap_filter5.exe streaming_lap_filter5.xclbin Using FPGA binary file specfied through the command line: streaming_lap_filter5.xclbin XRT build version: 2.6.0 Build hash: b69d97cd7827bda97b194006be3b46809fc1b843 Build date: 2020-03-23 06:41:22 Git branch: 2019.2_Ultra96 PID: 16657 UID: 1000 [Mon Mar 23 14:21:54 2020] HOST: ubuntu-fpga EXE: /home/fpga/work/streaming_lap_filter5/streaming_lap_filter5.exe [XRT] ERROR: No devices found ../src/krnl_streaming_lap_host3.cpp:71 Error calling err = cl::Platform::get(&platforms), error code is: -1どうやら OpenCL のデバイスが見つからないと言っているようです。まだ何か設定が必要なのかもしれません。
今後も引き続きデバッグしていくつもりです。
参考
- 投稿日：2020-03-23T14:13:20+09:00
C言語で静的・動的ライブラリを作成・使用する方法
目的
Linuxで.a（静的）と.so（動的）の２種類ライブラリを作成できるが、コンパイルする時に同じような方法で使用される。
即ち、異なるライブラリのlibA.aとlibA.soが存在しても、コンパイルのコマンドではライブラリの拡張子が省略され、gcc xxx -lAのようになるため、どっちが使用されるかは曖昧になる。libA.aとlibA.soが共存する場合の動作確認をしたく、メモする。
先に結論
gcc -o main main.c -L. -lA
のように、ライブラリlibA（-lAで指定）が指定されている場合、libA.so（動的）はlibA.a（静的）より優先的にリンクされる。追記
gcc -o main main.c -L. -static -lA
のように、「-static」を指定すれば、libA.a（静的）はリンクされる。追記2
gcc -o main main.c -L. -static-libgcc -Wl,-Bdynamic,-lc,-Bstatic,-lA
のように、gccの「-Wl」オプションで「-Bdynamic」（動的）や「-Bstatic」（静的）を指定すれば、ライブラリを選択することは可能。
（@yumetodoさん本当にありがとうございました！）サンプルコード
下記記事のコードを使用する。
また、静的ライブラリでnumを5にして、動的ライブラリでnumを10にして、コンパイルの時に使用されたのはどっちかを判明できる。動的ライブラリの作成及び動作確認
A.c#include<stdio.h> #include"A.h" void A(){ num = 10; //動的ライブラリでnumを10にする printf("inside A, num = %d\n", num); }#Aの共有（動的）ライブラリを作成 [pirlo@centos8 02]$ gcc -shared -o libA.so -c A.c ・・・ #メイン処理をコンパイルして実行ファイルを作成 [pirlo@centos8 02]$ gcc -o main main.c -L. -lA -lB #ファイル一覧 [pirlo@centos8 02]$ ls A.c A.h B.c B.h libA.so libB.so main main.c実行結果[pirlo@centos8 02]$ ./main inside A, num = 10 inside B, num = 10静的ライブラリの作成及び動作確認
A.c#include<stdio.h> #include"A.h" void A(){ num = 5; //静的ライブラリのここだけは違う printf("inside A, num = %d\n", num); }#Aの静的ライブラリを作成 [pirlo@centos8 02]$ gcc -c A.c B.c #オブジェクト「.o」ファイルが作成される [pirlo@centos8 02]$ ls A.c A.h A.o B.c B.h B.o main.c [pirlo@centos8 02]$ ar rcs libA.a A.o #オブジェクトファイルから静的ライブラリを作成 [pirlo@centos8 02]$ ls A.c A.h A.o B.c B.h B.o libA.a main.c ・・・Bの関連処理を略・・・ #メイン処理をコンパイルして実行ファイルを作成（コマンドは動的の時と完全一致） [pirlo@centos8 02]$ gcc -o main main.c -L. -lA -lB #ファイル一覧 [pirlo@centos8 02]$ ls A.c A.h A.o B.c B.h B.o libA.a libB.a main main.c実行結果[pirlo@centos8 02]$ ./main inside A, num = 5 inside B, num = 5動的・静的ライブラリが共存する場合で再度確認
#ファイル一覧 [pirlo@centos8 02]$ ls A.c A.h A.o B.c B.h B.o libA.a libA.so libB.a libB.so main.c #同じコンパイルコマンドで実行ファイルを再作成 [pirlo@centos8 02]$ gcc -o main main.c -L. -lA -lB実行結果[pirlo@centos8 02]$ ./main inside A, num = 10 inside B, num = 10まとめ
動的・静的ライブラリが共存する場合、動的ライブラリが優先的に参照される。
追記
「-static」オプションを追加すれば、静的ライブラリは参照される。実行結果[pirlo@centos8 02]$ ls A.c A.h A.o B.c B.h B.o libA.a libA.so libB.a libB.so main.c #「-static」オプション無し [pirlo@centos8 02]$ gcc -o main main.c -L. -lA -lB [pirlo@centos8 02]$ ./main inside A, num = 10 inside B, num = 10 #「-static」オプション有り [pirlo@centos8 02]$ gcc -o main main.c -L. -static -lA -lB [pirlo@centos8 02]$ ./main inside A, num = 5 inside B, num = 5追記2
gccの「-Wl」オプションで「-Bdynamic」（動的）や「-Bstatic」（静的）を指定すれば、ライブラリを選択することは可能。実行結果#AとBの静的ライブラリを使用 [pirlo@centos8 02]$ gcc -o main main.c -L. -static-libgcc -Wl,-Bdynamic,-lc,-Bstatic,-lA -lB [pirlo@centos8 02]$ ./main inside A, num = 5 inside B, num = 5 #すべての動的ライブラリを使用 [pirlo@centos8 02]$ gcc -o main main.c -L. -static-libgcc -Wl,-Bdynamic,-lc,-lA -lB [pirlo@centos8 02]$ ./main inside A, num = 10 inside B, num = 10各参照先
動的ライブラリの作成を下記内容を参考
静的ライブラリの作成を下記内容を参考
- 投稿日：2020-03-23T10:44:35+09:00
C言語グローバル変数の宣言
目的
グローバル変数の使用方法及びその確認
ファイル
main.c：グローバル変数numの宣言および順番でAとBを処理
A.h：グローバル変数numを使用することを宣言
A.c：numを変更して出力（グローバル変数numが変更される）
B.h：グローバル変数numを使用することを宣言
B.c：numを変更せず出力（Aで変更されたグローバル変数numを出力）上記のファイルで、mainで宣言されているnumは、AとBからも使用でき（グローバル変数になるため）、numがAで変更されても、Bからもその変更を確認できることを証明
ファイルの中身
main.c#include"A.h" #include"B.h" int num; //グローバル変数を宣言 int main(int argc, char *argv[]){ A(); //numを他のファイルで変更させる B(); //他のファイルで変更されたnumを確認 return 0; }A.hextern int num; //他のファイル（ここはmain.c）で宣言されているnumをAで使用することを宣言 void A();A.c#include<stdio.h> #include"A.h" void A(){ num = 10; //グローバル変数を変更 printf("inside A, num = %d\n", num); //グローバル変数を出力 }B.hextern int num; //他のファイル（ここはmain.c）で宣言されているnumをBで使用することを宣言 void B();B.c#include<stdio.h> #include"B.h" void B(){ printf("inside B, num = %d\n", num); //グローバル変数を変更せず出力 }#Aの共有ライブラリを作成 [pirlo@centos8 02]$ gcc -shared -o libA.so -c A.c #Bの共有ライブラリを作成 [pirlo@centos8 02]$ gcc -shared -o libB.so -c B.c #メイン処理をコンパイルして実行ファイルを作成 [pirlo@centos8 02]$ gcc -o main main.c -L. -lA -lB #ファイル一覧 [pirlo@centos8 02]$ ls A.c A.h B.c B.h libA.so libB.so main main.c実行結果[pirlo@centos8 02]$ ./main inside A, num = 10 #Aでグローバル変数を変更 inside B, num = 10 #BからAで変更されたグローバル変数を確認