v12.13.0

$ uname -a
 Linux ＊＊＊＊＊＊ 4.4.184.alpine.1 #1 SMP Thu Sep 5 02:32:14 UTC 2019 armv7l GNU/Linux

armv71．CPUの分類が判ったので、
公式サイトからArmV71用をダウンロード。

インストール方法を見ながら、やってみたものの。結果は

# node -bash: /usr/local/lib/nodejs/node-v12.13.0-linux-armv7l/bin/node: No such file or directory

Ubuntu（for Armv7l）のリポジトリィを漁ってみると

# apt-get update
# apt-get install nodejs npm
# nodejs -v
v0.10.29

さすがにコレは古いが、開発キットをインストしてみると、

# apt-get install build-essential
# gcc --version
gcc (Debian 4.9.2-10+deb8u2) 4.9.2
# g++ --version
g++ (Debian 4.9.2-10+deb8u2) 4.9.2
# make --version
GNU Make 4.0
# apt-get install openjdk*
# java -version
java version "1.7.0_231"
# python --version　※これは管理画面からインスト
Python 2.7.9

32ビットCPUなんで全てが古いらしい。
Node.jsのソースからビルドする際に要求に
gcc and g++ >= 6.3 or newer, or
があるので致命的。
しかも、ie同様にarrow関数が使えないから全部function()で書かないといけないのは辛いので「パッケージマネージャを利用した Node.js のインストール」から「 Node.js 公式のバイナリディストリビューション」の「Manual installation」を読んでみたが失敗。

armel　で、引っかかってしまう。
Available architectures: を見ると未サポートで、
ラズパイの様にarmhf(ハードウェアＦＰＵ付)だったら良かったらしい。

キモは、
export でCCFLAGSとCXXFLAGSを指定することだった。
Rasbery-Pi/Zeroなら

# export CCFLAGS='-march=armv6'
# export CXXFLAGS='-march=armv6'

とするらしい。
gccが9.2.0でもコレは同じ。
しかし、ReadyNAS212のＣＰＵは ARM Cortex A15。
Wikiによれば、
　ファミリー： Cortex-A
　アーキテクチャ： v7-A
　コア： Cortex A15
と云うことで、
こんぱいらのターゲットアーキテクチャの指定　から
CCFLAGSは、 ‘-march=armv7-a’　なのだそうだ。
Node.jsのコミュニティを眺めてたら、
ん～な古いCPUの需要あるの？あるならやるかも。と、書いてあったので、
新しいVerで試してみた。
※wgetしたので、git-coreは要らない。
なお、コンパイルに要した時間は３時間を超えており、make install もログが長い。

最終的にはこれでOK。

$ sudo apt-get install git-core build-essential libssl-dev
$ # sudo wget https://nodejs.org/dist/v12.13.1/node-v12.13.1.tar.gz
$ # sudo tar xvzf node-v12.13.1.tar.gz
$ # cd node-v12.13.1
$ sudo wget https://nodejs.org/dist/v12.18.3/node-v12.18.3.tar.gz
$ sudo tar xvzf node-v12.18.3.tar.gz
$ cd node-v12.18.3
$ export CCFLAGS='-march=armv7-a'
$ export CXXFLAGS='-march=armv7-a'
$ sudo -E ./configure
$ sudo -E make -j8
$ sudo -E make install
$ node --version
v12.13.1
$ npm --version
6.12.1

-j8は8スレッド使用かな？付けない時よりはログの流れが速いし、topコマンドで見る限り、指定有：97%、無：24%。８コアじゃないから-j4で十分。
かかった時間も指定有：1時間半、無：3時間だから　-j2で良かったかも。

以下は、トラブル履歴。

トラブル１．一般ユーザからsudoを使ってビルドすると古いgccが使われてしまう。
-Eを付けてもPATHだけは置き換えられてしまうので、
/etc/sudoers のパスに/usr/local/gcc-9.2.0/binを追加。

# cd node-v12.13.1
# ./configure    ※要python
WARNING: C++ compiler too old, need g++ 6.3.0 or clang++ 8.0.0 (CXX=g++)
INFO: Using floating patch "tools/icu/patches/64/source/common/putil.cpp" from "tools/icu"
INFO: Using floating patch "tools/icu/patches/64/source/i18n/dtptngen.cpp" from "tools/icu"
WARNING: warnings were emitted in the configure phase
INFO: configure completed successfully
※gcc 9.2.0の場合
INFO: Using floating patch "tools/icu/patches/64/source/common/putil.cpp" from "tools/icu"
INFO: Using floating patch "tools/icu/patches/64/source/i18n/dtptngen.cpp" from "tools/icu"
INFO: configure completed successfully

しかし、うまくいかない。

Error: selected processor does not support ARM mode `bkpt 0'

この直後にrootでログインしても

libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by

apt-get install libstdc++6
はインスト済みだが、リポジトリィのものはかなり古いようだ。
gcc-9.2.0のターゲットは /usr/local/gcc-9.2.0 だったので、
export LD_LIBRARY_PATH=/usr/local/gcc-9.2.0/lib:$LD_LIBRARY_PATH
でやり過ごそうとしたが
無駄。
やはり古いのを見てしまう。
というか仕様になっていた。
一般のユーザの~/.bash_profileなどに書くとうまくいく場合もあるらしいが

$ echo $LD_LIBRARY_PATH
/usr/local/gcc-9.2.0/lib:

トラブル２． LD_LIBRARY_PATH は効かない。

LD_LIBRARY_PATHが空っぽの時点で察する必要があった。
このNASのLinuxでは、LD_LIBRARY_PATH環境変数は一般の環境変数でしかないのだった。

どうやら、ldconfigの出番の様だ。gcc-9.2.0と心中するつもりで取り掛かるしかないのだ。

しかし、今は/etc/ld.so.confに直書きするのではなく、

/etc/ld.so.conf.dにgcc-9.2.9.confを追加するのが通らしい。

# gcc-9.2.0 configuration
/usr/local/gcc-9.2.0/lib

そして、共有ライブラリィのリンクを入れ替える

# ldconfig
/sbin/ldconfig.real: /usr/local/gcc-9.2.0/lib/libstdc++.so.6.0.27-gdb.py is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig.real: /usr/lib/libreadycloud.so.1 is not a symbolic link

これでも、

$ sudo -E ldconfig -p | grep libstdc++.so.6
        libstdc++.so.6 (libc6,soft-float) => /usr/lib/arm-linux-gnueabi/libstdc++.so.6
        libstdc++.so.6 (libc6,soft-float) => /usr/local/gcc-9.2.0/lib/libstdc++.so.6

となって古いものを見てしまう。
/etc/ld.so.conf の中身が

include /etc/ld.so.conf.d/*.conf

なので、arm-linux-gnueabi.conf より文字コードが前になりそうな
__ gcc-9.2.9.conf に名を変えたが無駄足で、
結局　 ls -l /etc/ld.so.conf.d/*.conf　の結果を見ながらファイル名を変えて、

arm-gcc-9.2.9.conf が正解！

奥が深いというより、
デフォのgccのファイル名が linux-gnueabi.conf ならOKだが、
arm- linux-gnueabi.conf なら誰もが失敗する。
こんな設定ファイルの読込み順で、共有ライブラリィのパスが決まるのって

間抜けとしか云いようがない

否、今は
include 　*****/*.conf
が普通なのだから、昨今のlinuxのノウハウの半分を占めている可能性が高い。
※とっても低レベルだが、

決して、侮れないノウハウだ。

ファイル名を linux-arm-gnueabi.conf に変えるだけで誰もが幸せになれるのにね？でも、ダレもそんなことはしないのが世の常。

$ sudo -E ldconfig -p | grep libstdc++.so.6
        libstdc++.so.6 (libc6,soft-float) => /usr/local/gcc-9.2.0/lib/libstdc++.so.6
        libstdc++.so.6 (libc6,soft-float) => /usr/lib/arm-linux-gnueabi/libstdc++.so.6

とりあえず、バイトコード生成をコメントアウトしなくて済むようになったので、リモートデバッグもできるようになるだろう。
※ソースをNFSの共有フォルダに配置しなければいけない問題はあるけど。

そして、長いコンパイルはまだまだ3時間くらい続くはずだ。

sudo make test
=== release test-perf-hooks ===
Path: sequential/test-perf-hooks
{
  name: 'node',
  entryType: 'node',
  startTime: 0,
  duration: { around: 144.90792298316956 },
  nodeStart: { around: 0 },
  v8Start: { around: 0 },
  bootstrapComplete: { around: 135.9222869873047, delay: 2500 },
  environment: { around: 0 },
  loopStart: -1,
  loopExit: -1
}
{
  name: 'node',
  entryType: 'node',
  startTime: 0,
  duration: { around: 1163.1746279895306 },
  nodeStart: { around: 0 },
  v8Start: { around: 0 },
  bootstrapComplete: { around: 135.9222869873047, delay: 2500 },
  environment: { around: 0 },
  loopStart: { around: 135.9222869873047, delay: 2500 },
  loopExit: -1
}
{
  name: 'node',
  entryType: 'node',
  startTime: 0,
  duration: { around: 1165.5776199996471 },
  nodeStart: { around: 0 },
  v8Start: { around: 0 },
  bootstrapComplete: { around: 135.9222869873047, delay: 2500 },
  environment: { around: 0 },
  loopStart: { around: 135.9222869873047, delay: 2500 },
  loopExit: { around: 1165.6191799938679 }
}
assert.js:374
    throw err;
    ^
AssertionError [ERR_ASSERTION]: duration: 389.13076999783516 >= 250
    at checkNodeTiming (/home/****/node-v12.13.1/test/sequential/test-perf-hooks.js:67:7)
    at process.<anonymous> (/home/****/node-v12.13.1/test/sequential/test-perf-hooks.js:108:3)
    at process.emit (events.js:215:7) {
  generatedMessage: false,
  code: 'ERR_ASSERTION',
  actual: false,
  expected: true,
  operator: '=='
}
Command: out/Release/node /home/****/node-v12.13.1/test/sequential/test-perf-hooks.js
[09:26|% 100|+ 2776|-   1]: Done
Makefile:296: recipe for target 'jstest' failed
make[1]: *** [jstest] Error 1
Makefile:316: recipe for target 'test' failed
make: *** [test] Error 2

ダメっぽいが、何がダメなのか判らないので、インストして終了。

OpenSSLの指定方法が不明だったので、
apt-get でインストした libssl-dev(1.0.1t-1+deb8u12)を使うことになる。

$ openssl version
OpenSSL 1.0.1t 3 May 2016

/etc/sudoersにコンパイルしたOpenSSLのパスを追加すればいいかな
Defaults secure_path=”/usr/local/openssl-1.0.2t/bin:
にすると
$ sudo openssl version
OpenSSL 1.0.2t 10 Sep 2019

やっぱりもっと新しい方がいいような
Defaults secure_path=”/usr/local/openssl-1.1.1d/bin:
OpenSSL 1.1.1d 10 Sep 2019
にしておこう。

ldconfigで書き換えてるし、rootも設定しておくか

export PATH=/usr/local/openssl-1.1.1d/bin:/usr/local/gcc-9.2.0/bin:$PATH

変奏現実

パソコンやMMORPGのことなどを思いつくまま・・・記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。

Node.js ABC順でハマる

arm-gcc-9.2.9.conf が正解！

間抜けとしか云いようがない

決して、侮れないノウハウだ。

2024年11月
日	月	火	水	木	金	土
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30