早安，今日开始正式编译KDE Plasma5桌面环境，用户登录界面以及Plymouth…随后就是昨日未编译完毕的KDE程式——KGet，KTorrent，以及最重要的Krita——但是首先要将不再需要的twm，xclock与xterm删去。解压缩这三个程式（twm等）的压缩包，循着BLFS间给定的设置完毕之后，执行make uninstall。twm与xclock无法通过执行这个命令进行卸载，所以依旧循着BLFS给定的安装之后的文件列表进行了手动删除，总之一切顺利…继续编译安装需要的。
按照默认设置编译与安装了Plymouth，但是稍后编译安装完毕Plasma5以及一份用户管理器之后，再进行设置好了（设置完毕之后当然需要进行initrd的更新）——执行make install之后根目录之下多出了很多文件夹，没办法，只得先执行make uninstall，然后再看看怎样设置的话，不会多出这么多文件夹来——查看了安装过程中终端输出的内容，这些文件夹是配合systemd需要的，看起来需要于设置过程中禁掉systemd支持才行。
然后参考了Plymouth源文件夹中的INSTALL文件，最后按照这样的配置设置并且安装了Plymouth：
./configure –prefix=/usr –disable-static –with-system-root-install –sysconfdir=/etc –localstatedir=/var –enable-systemd-integration=no –with-systemdunitdir=/tmp/a
若是再次启动的时候有问题，将–with-systemdunitdir中的选项留空试一试…首先配置一下Plymouth，于/etc/rc.d/init.d间添加了这两个文件：
plasmastart：
echo “Welcome To Liddys Linux ver 11.0!”
plymouth show-splash
plasmastop：
plymouth quit
然后运行了如下命令：
ln -sv ../init.d/plasmastart /etc/rc.d/rc5.d/S09PlasmaStart
ln -sv ../init.d/plasmastop /etc/rc.d/rc5.d/S99PlasmaStop
并且将这两个文件更为了可执行…稍后全部配置完毕之后，重启试试能否顺利启动Plasma，若是不行的话，再找原因——现在先编译Plasma5。
Plasma5编译完毕，但是测试之前还需要编译LightDM作为用户选择界面。选择了WebKit的界面作为LightDM界面（https://github.com/antergos/web-greeter）（编译时设置修改为：–with-greeter-session=lightdm-webkit2-greeter）…应该编译的程式包大致编译完毕，重启至Liddy’s Linux间查看效果（在此之前再次执行了mkinitramfs 5.13.12）。
…运行结果——能够正常显示lightdm并且可以成功登录，但是无法进入Plasma5桌面环境——查看日志以及试着打开Plasma5的窗口，发现.qml文件缺失…再次查看Liddy’s Linux中的/etc/profile/qt5.sh文件，发现/usr/lib/qt5/qml与/opt/qt5/lib/qml不存在，反倒存在于/usr/lib/qml以及/opt/qt5/qml…那样于这个文件之间新添这两行代码：
pathappend /usr/lib/qml QML2_IMPORT_PATH
pathappend $QT5DIR/qml QML2_IMPORT_PATH
再次启动试一试。顺带一提，Plymouth也没有正常启动…暂且删去/etc/rc.d/rc5.d/S09PlasmaStart与/etc/rc.d/rc5.d/S99PlasmaStop文件（刚刚发现还打错了…是Plymouth，而非Plasma…），然后再进行调试…再次启动之后Plasma5桌面显示正常，除去因为Intel的内置显卡的问题，屏幕有时闪烁，也是日后解决…还有这些问题发现：
无法挂载其他硬盘或Liddy’s Linux所在硬盘中的其他分区，提示没有权限；
Konsole字体配置似乎不对；
XTerm仍旧存在，明日备份系统之前进行手动卸载；
iBus运行出现了问题，循着iBus的提示进行了解决：
export GTK_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export QT_IM_MODULE=ibus
ibus-daemon -d
将以上内容保存至/etc/profile.d/ibus.py，再登陆就可以了。另外SunPinYin还是无法正常输入中文，明日解决——需要一个命令，但是忘了…明日再记录下来。显卡没办法（或许启动Plasma5-Wayland可以解决？明日试一试。），而且现在的任务是继续编译需要的程式——基于KDE程式框架的程式还有KGet，Krita与KTorrent。另外Plymouth先保存着算了…哎，看起来Plymouth确实基于systemd，即使顺利进入Plasma5——意味着成功加载X Window Server，再以debug模式运行Plymouth也无法顺利启动，有时间再想办法解决，或者下次编译Liddy’s Linux时进行解决——那时的咱就拥有改写代码的能力来着。
提前顺带着将XTerm删掉了…对了，值得庆幸的是，Liddy’s Linux间Wifi可以正常搜索到…上次编译最后也没有实现。
通过这个命令（Git）有打Arch的程式库间下载了不需要Systemd就能够运行的Plymouth：git clone https://aur.archlinux.org/plymouth-nosystemd.git
但是拷贝完毕之后…只发现了一些Arch Linux需要的文件，补丁文件以及PKGBUILD——这个文件里面有需要的设置，咱没有用过Arch Linux…看来Arch Linux的程式包构建…与自己进行构建（LFS/BLFS）差不了多少，然后添加特定文件实现包管理功能…这是咱的猜想，不过值得借鉴。总之看到了需要的设置内容：–disable-systemd-integration，试一试好了，稍后看一下这次编译安装完毕之后能否于Liddy’s Linux环境中运行。顺带着将/etc/rc.d/init.d/中的plasmastart与plasmastop更为了正确的名称…plymouthstart与plymouthstop，xinit也经过重装将设置文件调整为正确的/etc/X11/app-defaults。
进行Quazip的安装时，CMake的默认设置中添加了这个选项：-DQUAZIP_QT_MAJOR_VERSION=5
编译OpenColorIO时遇到的错误：
/usr/bin/ld: /usr/lib/libyaml-cpp.a(exp.cpp.o): relocation R_X86_64_32 against `.rodata.str1.8′ can not be used when making a shared object; recompile with -fPIC
依照提示重新编译一遍Yaml-Cpp即可。随后继续编译OpenColorIO时又遇到了其他错误——
/usr/include/OpenImageIO/platform.h:97:6: 错误：#error “This version of OIIO is meant to work only with C++14 and above”
重新设置一下再编译试一试，设置中添加“-DCMAKE_CXX_FLAGS=“-std=c++17””…没有用，看来应该在编译OpenImageIO时加入才对…没办法，重新编译罢…但是故障依旧，看起来需要换一种方式…以C++11来编译OpenImageIO试一试（-DCMAKE_CXX_FLAGS=”-std=c++11″），随后再进行OpenColorIO的编译——还是没有用，随后经查看发生编译错误的源文件所在文件夹中的flags.make文件，发现这样的问题：
CXX_FLAGS = -std=c++17 -O3 -DNDEBUG -fvisibility=hidden -fvisibility-inlines-hidden -DUSE_GCC -Wall -Wextra -Wswitch-enum -std=c++11
…这样设置的话当然无法使用-std=c++17进行编译…这次使用“-DCMAKE_CXX_FLAGS=” -std=c++17 -O3 -DNDEBUG -fvisibility=hidden -fvisibility-inlines-hidden -DUSE_GCC -Wall -Wextra -Wswitch-enum””试一试…设置之后仍旧发现自动添加了-std=c++11，看来最后直接改文件之前，已经再次设置完毕，那样再试着查看一下CMakeCache.txt…没有发现-std=c++11的踪迹——直接改文件罢（src/apps/ociolutimage/CMakeFiles/ociolutimage.dir/flags.make）！…编译能够继续，但是又发生了如下错误：
/usr/bin/ld: CMakeFiles/ociolutimage.dir/main.cpp.o: undefined reference to symbol ‘_ZN16OpenImageIO_v2_310ParamValue11clear_valueEv’
/usr/bin/ld: /usr/lib/libOpenImageIO_Util.so.2.3: error adding symbols: DSO missing from command line
…先将OpenImageIO的设置更为-std=c++17进行安装，然后再想办法…不顾现在更变为-std=c++17也没什么作用，因为稍后将会重新安装——尽可能满足OpenImageIO的依赖要求的话，编译成功的几率也会越高——虽然咱对编程不太懂，但很容易看得出来是symbol——变量相关…缺失，因为依赖库缺失导致。
想着”准备下载OpenGL“，但是这时才发现OpenGL已预装至Mesa，果然咱对OpenGL不熟悉…看起来不需要重新编译Mesa，那样还是从OpenImageIO入手好了——顺带着调整了一下OpenColorIO的设置：cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DCMAKE_CXX_FLAGS=”-std=c++17″ -DOPENGL_opengl_LIBRARY=/usr/lib -DOPENGL_xmesa_INCLUDE_DIR=/usr/include -Dpystring_INCLUDE_DIR=/usr/include -DOCIO_BUILD_GPU_TESTS=OFF -DOCIO_BUILD_TESTS=OFF -Wno-dev ..
这样的话就能够使用GLEW的支持了。OpenImageIO能够搜索到OpenGL的支持…顺带着再次试着编译OpenColorIO时提示错误为”找不到pystring/pystring.h“，试着寻找确实也找不到…那样PyString当初安装至了何处？总之再看看这次的编译结果罢，大概率同样是需要重新编译OpenImageIO…重新编译的时候又遇到了如下错误：
[ 74%] Linking CXX executable ociochecklut
/usr/bin/ld: error: /usr/lib: read: 是一个目录
将待编译程式源代码所在目录中link.txt中的/usr/lib删去，剩下/usr/lib中的所要链接的库即可…此后又遇到了上面的错误，找不到symbol（变量符号？）…解决方法是于相关文件所在的文件夹中link.txt间添加库”/usr/lib/libOpenImageIO_Util.so“即可…这里是参考资料：https://blog.csdn.net/jacke121/article/details/55095217
继续编译，又遇到了如下问题：
/usr/include/Imath/half.h:902:7: 错误：conflicting declaration ‘using half = class Imath_3_1::half’
是Imath与OpenEXR互相冲突的问题…寻找解决方法的时候看到了如下内容：
Is there a way to build OpenEXR against imath?
You can choose to build OpenEXR against an external installation of Imath, or the default CMake configuration will download and build it automatically during the OpenEXR build process. Note that the half 16-bit floating point data type is included in Imath.
…应该是安装完毕Imath之后…不对，咱的编译顺序是Imath，然后是OpenEXR，看起来不是”编译完毕Imath之后需要重新再安装OpenEXR“的问题——看来Imath与OpenEXR只能先禁掉一个了，编译OpenColorIO的过程中，咱选择禁掉Imath…新版本的OpenEXR与Imath存在冲突，希望下次编译Liddy’s Linux的时候会被解决掉罢…大概是这样的原因——但是OpenColorIO不需要Imath，经查找…再重编译一遍OpenEXR算了…不，Imath与OpenEXR皆重新编译，不过Imath设置中看到不需要OpenEXR…总之，再次编译OpenEXR，并且为OpenColorIO指定再次编译的OpenEXR而非再次有打GitHub间下载…这样试一下——已经重新安装完毕，但是应该没有作用…因为安装的文件列表当中看不到OpenEXR版本的half.h——但是OpenColorIO下载的版本中有——看来只能修改源文件了，修改OpenColorIO的源文件…应该是half.h有打OpenEXR版本3开始被Imath重新定义的关系。
重新添加了这些选项：“-DIlmBase_DIR=/usr -DHalf_INCLUDE_DIR=/usr/include -DHalf_LIBRARY=/usr/lib”，然后再次解决了之前所提到的问题(/usr/lib是一个目录，)…再次遇到如下问题：
[ 70%] Linking CXX executable ociobakelut
/usr/bin/ld: ../../OpenColorIO/libOpenColorIO.so.2.0.2: undefined reference to half::_eLut' /usr/bin/ld: ../../OpenColorIO/libOpenColorIO.so.2.0.2: undefined reference tohalf::_toFloat’
/usr/bin/ld: ../../OpenColorIO/libOpenColorIO.so.2.0.2: undefined reference to `half::convert(int)’
…经查找，Imath所提供的half.h中没有这些定义…咱再找找OpenEXR中有没有这些。暂时使用的方法为于OpenColorIO.dir中flags.make与links.make间添加OpenEXR与Imath所安装的库文件与定义文件…但是应该不会太管用，大概…果然还是这个问题。没办法，暂且只能于设置间添加-DOCIO_BUILD_APPS=OFF，现在只需要库文件，krita可以使用…哎。希望下次编译Liddy’s Linux时，能够解决这个问题罢——可恶。
编译Krita的设置如下：“cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DOPENEXR_INCLUDE_DIR=/usr/include -DCRASH_ON_SAFE_ASSERTS=ON -Wno-dev ..”
编译Krita时遇到的错误：
/sources/krita-4.4.8/build/libs/pigment/kritapigment_autogen/EWIEGA46WW/../../../../../libs/pigment/KoColorSpaceMaths.h:117:10: 致命错误：half.h：没有那个文件或目录
…看来Krita希望寻找的half.h也是旧Imath/OpenEXR中…哎，以防万一，首先看看OpenEXR源文件压缩包中有没有half.h，若是没有的话更改Krita的源文件，若是有的话试着在再一次重新编译OpenEXR之后将half.h导入至/usr/include中——答案是没有，没办法…不过在修改源文件之前，首先看看添加-I/usr/include/Imath有没有效果…有效果倒是有效果，但是编译至52%的时候遇到了与新安装的OpenColorIO库有关的错误…只能重新再编译一遍OpenColorIO了，之所以耗费许多时间不断进行调试与编译是因为OpenColorIO源代码间附带的程式源代码无法继续编译下去，那样的话暂且禁掉OpenColorIO的附带程式，结果通过（可以正常生成需要的库文件）…哎。（cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS=”-std=c++17″ -DOCIO_BUILD_APPS=OFF -DOCIO_BUILD_GPU_TESTS=OFF -DOCIO_BUILD_TESTS=OFF -Wno-dev ..）——顺利编译安装完毕，但是问题依旧…再次翻看安装记录与OpenColorIO源代码文件夹，以及进一步对比Debian中OpenColorIO安装文件信息，发现/usr/include/OpenColorIO整个文件夹缺失，将源代码包中需要的.h文件拷贝至/usr/include/OpenColorIO中罢…参见此处：https://packages.debian.org/bullseye/amd64/libopencolorio-dev/filelist
——但是添加了缺失的头文件，编译过程依旧报错…怎么回事，咱再多加思考思考…稍微查了一下，果然是Bug——https://bugs.kde.org/show_bug.cgi?id=440708，没办法，只好寻找版本为1.1.1的OpenColorIO，编译安装至/opt/OpenColorIO-1.1.1,然后继续编译Krita…这是现在唯一的解决方法——哎。
编译OpenColorIO时遇到了如下错误：
cc1plus：所有的警告都被当作是错误
经查找，解决方法是将编译选项中的-Werror去掉…编译成功，随后于/etc/ld.so.conf间添加了“/opt/OpenColorIO-1.1.1”，再次运行/sbin/ldconfig。这次再编译Krita的时候，添加了选项：-DOCIO_LIBRARIES=/opt/OpenColorIO-1.1.1/lib/libOpenColorIO.so.1.1.1 -DOCIO_INCLUDE_DIR=/opt/OpenColorIO-1.1.1/include。希望这次能够顺利编译完毕。（注意，若是将OCIO_INCLUDE_DIR设定为/opt/OpenColorIO-1.1.1/include/OpenColorIO的话，会导致找不到/opt中的OpenColorIO头文件，转向寻找/usr/include中的…还是会链接安装好的/usr/lib中的OpenColorIO库，导致Bug再次发生。）
继续编译Krita时遇到如下问题：
/sources/krita-4.4.8/plugins/impex/exr/exr_converter.cc: 在成员函数‘void EXRConverter::Private::decodeData4(Imf_3_1::InputFile&, ExrPaintLayerInfo&, KisPaintLayerSP, int, int, int, int, Imf_3_1::PixelType)’中:
/sources/krita-4.4.8/plugins/impex/exr/exr_converter.cc:384:22: 错误：‘frameBuffer’ has incomplete type
In file included from /usr/include/OpenEXR/ImfAttribute.h:16,
from /sources/krita-4.4.8/plugins/impex/exr/exr_converter.cc:25:
/usr/include/OpenEXR/ImfForward.h:75:24: 附注：forward declaration of ‘class Imf_3_1::FrameBuffer’
…是OpenEXR…而且若只是调整设置的话，应该无解——只能够改动Krita的源代码，应该是大小写的问题？试一试好了——不对，虽然咱现在不大懂编程，但是翻阅源代码还能看得出不是大小写的问题——解决方法是于exr_converter.cc中添加了对ImfFrameBuffer.h与ImfHeader.h的引用…
这样就可以了——随后链接的时候又出现了很多错误，不详细列出——因为几乎全部为undefined reference的错误…于build/plugins/impex/exr/CMakeFiles/kritaexrexport.dir/link.txt间添加“/usr/lib/libOpenEXR.so”即可（kritaexrimport.dir文件夹中的link.txt也一样）。
这次Krita编译与安装终于成功…因为Plymouth已经按照移除systemd进行了重新编译安装，那样试着重新将plymouthstart与plymouthstop脚本链接至/etc/rc.d/rc5.d间…
ln -sv ../init.d/plymouthstart /etc/rc.d/rc5.d/S09PlymouthStart && ln -sv ../init.d/plymouthstop /etc/rc.d/rc5.d/S99PlymouthStop
然后再次生成initrd文件，重启…Plymouth还是无法使用，提示的错误依旧（无法连接到服务？莫非还是systemd么…），不过还不重要，以后再进行调试或是这个版本的Liddy’s Linux暂不支持…此外还发现两个问题：
Wacom无线模块无法使用，但是USB连接的话可以正常使用。
无法进行终端输入sudo reboot或sudo halt/sudo shutdown以外的重启/关机。
…日后再进行解决，现如今先将所有程式全部编译完毕——至少Krita能够正常使用…但是屏幕闪烁更加严重了，咱查一下以前编译Liddy’s Linux的日志，那时解决了这个问题…还有重新做了链接，/etc/X11/app-defalts至app-defaults，因为不这样的话无法正常启动…可恶，下次编译必须要多注意了。
最后屏幕闪烁通过以下方式解决——/etc/X11/xorg.conf.d/20-intel.conf间这些内容进行了注释解除，使其生效。
Option “DRI” “3”
Option “AccelMethod” “sna”
Option “AccelMethod” “uxa”
成功解决屏幕闪烁…那样今日的编译暂且为此，该是进行备份的时候了…这次备份完毕之后，只剩下最后的其他需要的程式的编译了，以及解决能够解决的问题等等。
今日编译与安装的程式包列表如下：
smartmontools-7.2
AccountsService-0.6.55
Plymouth-0.9.5
kdecoration-5.22.4
libkscreen-5.22.4
libksysguard-5.22.4
breeze-5.22.4
breeze-gtk-5.22.4
layer-shell-qt-5.22.4
kscreenlocker-5.22.4
oxygen-5.22.4
kinfocenter-5.22.4
kwayland-server-5.22.4
kwin-5.22.4
plasma-workspace-5.22.4
plasma-disks-5.22.4
bluedevil-5.22.4
kde-gtk-config-5.22.4
khotkeys-5.22.4
kmenuedit-5.22.4
kscreen-5.22.4
kwallet-pam-5.22.4
kwayland-integration-5.22.4
kwrited-5.22.4
milou-5.22.4
plasma-nm-5.22.4
plasma-pa-5.22.4
plasma-workspace-wallpapers-5.22.4
polkit-kde-agent-1-5.22.4
powerdevil-5.22.4
plasma-desktop-5.22.4
kdeplasma-addons-5.22.4
kgamma5-5.22.4
ksshaskpass-5.22.4
plasma-sdk-5.22.4
sddm-kcm-5.22.4
discover-5.22.4
breeze-grub-5.22.4
breeze-plymouth-5.22.4
kactivitymanagerd-5.22.4
plasma-integration-5.22.4
plasma-tests-5.22.4
plymouth-kcm-5.22.4
xdg-desktop-portal-kde-5.22.4
drkonqi-5.22.4
plasma-vault-5.22.4
plasma-browser-integration-5.22.4
kde-cli-tools-5.22.4
systemsettings-5.22.4
plasma-thunderbolt-5.22.4
plasma-firewall-5.22.4
plasma-systemmonitor-5.22.4
qqc2-breeze-style-5.22.4
ksystemstats-5.22.4
libxklavier-5.4
lightdm-1.30.0
（LightDM Greeter）web-greeter-2.2.5
KTorrent-21.08.0
Libmms-0.6.4
KGet-21.08.0
Kseexpr-4.0.3.0
Imath-3.1.3
OpenEXR-3.1.2
Libheif-1.12.0
GLEW-2.2.0
Python3模块 Sip-6.2.0（使用pip install sip进行安装）
Python3模块 PyQt5-5.15.2（使用pip install PyQt5进行安装）
Vc-1.4.2
QuaZip-1.1
Yaml-cpp-0.7.0
PyString-1.1.3（make && make PREFIX=/usr install）
PyBind11-2.8.0
OpenImageIO-2.3.8.0（添加了-DCMAKE_CXX_FLAGS=”-std=c++17″）
OpenEXR-3.1.2 再安装（似乎没有作用？）
OpenColorIO-2.0.2（只编译了库文件等）
OpenColorIO-1.1.1（安装至/opt间——-DCMAKE_INSTALL_PREFIX=/opt/OpenColorIO-1.1.1，设置中添加了-DOCIO_BUILD_STATIC=OFF）
Krita-4.4.8
Be First to Comment