Armadilloフォーラム

NFCカードライブラリのサンプルコードのインストールについて

haruka0606

2014年3月25日 17時27分

いつもお世話になっております。
中井と申します。

Armadillo-840へのNFCカードリーダ(ACR122U)の接続にあたり、
サンプルプログラムを頂いたのですが、ビルドで下記のエラーが発生しております。

atmark@atde5:~/cardreader_dev/sample/nfcrd$ make
arm-linux-gnu-gcc -I../../include/PCSC -c -o main.o main.c
make: arm-linux-gnu-gcc: コマンドが見つかりませんでした
make: *** [main.o] エラー 127

現在はDebianからATDE5の仮想マシンを立ち上げただけの状態ですが、
ビルドを行うにあたり、何らかの事前準備が必要なのでしょうか。
・頂いたサンプルは、Armadillo-500用との事です。
・手順書には、その辺りの記述は見当たりませんでした。
・atmark-dist、及びlinuxカーネルのインストールは行っておりません。
・apt-getによる、パッケージのupdate/upgradeは行っております。
・各種ライブラリは同胞されているため、新たなインストールは不要との認識です。
・あとは、実体をLinux側に移すためにsambaをインストールしたくらいです。

以上、よろしくお願いいたします。

コメント

at_ohsawa

2014年3月25日 17時35分

ATDE5にはarm-linux-gnu-gccはインストールされていません。

Armadillo-840に対応したクロスコンパイラは
arm-linux-gnueabihf-gccなので、使用している
Makefileを修正してみてください。

製品マニュアルの「第13章 開発の基本的な流れ」でも少し触れています。
http://manual.atmark-techno.com/armadillo-840/armadillo-840_product_man…

haruka0606

2014年3月25日 18時02分

回答ありがとうございました。
コンパイラを差し替えたところ、ビルドは実行されましたがエラーになります。
(例)../../lib/libpcsclite.so: undefined reference to `daemon@GLIBC_2.0'
GLIBC_2.0が無いのかと思いlibc6をインストールしましたが、最新でした。

> ATDE5にはarm-linux-gnu-gccはインストールされていません。
>
> Armadillo-840に対応したクロスコンパイラは
> arm-linux-gnueabihf-gccなので、使用している
> Makefileを修正してみてください。
>
> 製品マニュアルの「第13章 開発の基本的な流れ」でも少し触れています。
> http://manual.atmark-techno.com/armadillo-840/armadillo-840_product_man…
>

haruka0606

2014年3月26日 9時52分

追記です。

readelfコマンドで.soファイルの中を覗いてみましたが、
エラーとなっているモジュールのシンボルは存在していました。
(数が多いので一部しかチェックしていませんが...)

Makefileのパス指定も確認しましたが、正しいフォルダを参照
しているように見えます。

> 回答ありがとうございました。
> コンパイラを差し替えたところ、ビルドは実行されましたがエラーになります。
> (例)../../lib/libpcsclite.so: undefined reference to `daemon@GLIBC_2.0'
> GLIBC_2.0が無いのかと思いlibc6をインストールしましたが、最新でした。
>
> > ATDE5にはarm-linux-gnu-gccはインストールされていません。
> >
> > Armadillo-840に対応したクロスコンパイラは
> > arm-linux-gnueabihf-gccなので、使用している
> > Makefileを修正してみてください。
> >
> > 製品マニュアルの「第13章 開発の基本的な流れ」でも少し触れています。
> > http://manual.atmark-techno.com/armadillo-840/armadillo-840_product_man…
> >

at_ohsawa

2014年3月26日 15時03分

>(例)../../lib/libpcsclite.so: undefined reference to `daemon@GLIBC_2.0'
ログから解る範囲になりますが、pcsclite.soがGLIBC_2.0のdaemonを要求していることがわかります。

atde5にインストールされている、クロスビルド用のlibcのシンボルを
readelfで確認するとdaemonのバージョンはGLIBC_2.4になっている事が確認できます。

atmark@atde5:~$ arm-linux-gnueabihf-readelf --symbols /usr/arm-linux-gnueabihf/lib/libc.so.6|grep daemon
   443: 000900e1   252 FUNC    GLOBAL DEFAULT   12 daemon@@GLIBC_2.4

このままだと2.0と2.4で互換性が無いので、ビルドする事ができません。

もしlibpcsclite.so自体をビルドしようとしているのであれば、
新しくビルドせずに、debianから配布されている新しいlibpcscliteの
armhf用のバイナリを使うと良いです。

下記のURLからダウンロードしたdebファイルをdpkg -xで展開する事で
libpcsclite.soが手に入ります。
http://ftp.jp.debian.org/debian/pool/main/p/pcsc-lite/libpcsclite1_1.8…

ビルドしたプログラムを実行する際には置き換えたlibpcsclite.soも
Armadilloにコピーする事を忘れないようにしてください。

dpkg-crossでダウンロードしたパッケージをクロスパッケージに変換して、
atde5の環境にインストールしてしまっても良いですね。

haruka0606

2014年3月26日 15時56分

at_ohsawa様
中井です。

回答ありがとうございました。

>もしlibpcsclite.so自体をビルドしようとしているのであれば
現在やりたいこととしては、サンプルプログラムのビルド
のみで、ライブラリに対しては何も行いません。

そこで初歩的な質問かもしれませんが、Makefileの中で
gcc -L(libpath) -l(libname) でサンプルプログラムに含まれる
ライブラリを指定しても、atde5に付属するファイルも参照
しにいくからアンマッチが起こるということでしょうか。

以上、よろしくお願いいたします。

> >(例)../../lib/libpcsclite.so: undefined reference to `daemon@GLIBC_2.0'
> ログから解る範囲になりますが、pcsclite.soがGLIBC_2.0のdaemonを要求していることがわかります。
>
> atde5にインストールされている、クロスビルド用のlibcのシンボルを
> readelfで確認するとdaemonのバージョンはGLIBC_2.4になっている事が確認できます。
>
>

> atmark@atde5:~$ arm-linux-gnueabihf-readelf --symbols /usr/arm-linux-gnueabihf/lib/libc.so.6|grep daemon
>    443: 000900e1   252 FUNC    GLOBAL DEFAULT   12 daemon@@GLIBC_2.4
> 

>
> このままだと2.0と2.4で互換性が無いので、ビルドする事ができません。
>
> もしlibpcsclite.so自体をビルドしようとしているのであれば、
> 新しくビルドせずに、debianから配布されている新しいlibpcscliteの
> armhf用のバイナリを使うと良いです。
>
> 下記のURLからダウンロードしたdebファイルをdpkg -xで展開する事で
> libpcsclite.soが手に入ります。
> http://ftp.jp.debian.org/debian/pool/main/p/pcsc-lite/libpcsclite1_1.8…
>
> ビルドしたプログラムを実行する際には置き換えたlibpcsclite.soも
> Armadilloにコピーする事を忘れないようにしてください。
>
> dpkg-crossでダウンロードしたパッケージをクロスパッケージに変換して、
> atde5の環境にインストールしてしまっても良いですね。

at_yashi

2014年5月13日 19時45分

> そこで初歩的な質問かもしれませんが、Makefileの中で
> gcc -L(libpath) -l(libname) でサンプルプログラムに含まれる
> ライブラリを指定しても、atde5に付属するファイルも参照
> しにいくからアンマッチが起こるということでしょうか。

GNU libc (glibc) の関数(というかシンボル)には、バージョン番号が付いてい
ます。glibc は、互換性を維持するために複数のバージョンを維持するのです
が、永遠に対応できるわけではありません。

今回は、古い glibc にはあったバージョンが、a800の環境では無くなってしまっ
たのが原因のようです。

シンボルバージョンについては↓こちらを参照してください。
https://sourceware.org/glibc/wiki/FAQ#What_is_symbol_versioning_good_fo…