SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
First of all, thanks to both of you for your continued help and support! I'm hoping that at the end of this saga I'll be able to provide an "idiot's guide" that will enable others to avoid the pitfalls in to which I'm running!
Well spotted! Yes, I make no claims to being a programmer! I was taught FOCAL and Fortran IV at college nearly 50 years ago, and at one point became quite adept at 6502 machine code - but that's where my experience ends! I can usually make sense of C code and modify it, but I would certainly hesitate to write anything complex from scratch! As you rightly surmise, I took the kodi-17.X slackbuild and carried out the minimum number of modifications necessary to get it to build! Its a bit late at night now, but I will follow this line tomorrow!
Quote:
Can't follow you on this:
Quote:
1) Platform: This went OK once I switched from the build dialog in @abga's other thread to the one in the "README" in the Platform folder.
What have you exactly switched to?
Ah, yes! You are building on an ARM platform. I'm building on x86_64. My standard build procedure is to have a "Build" folder in my home directory, containing (in this instance) a kodi-18 subdirectory containing the tar.gz source file, slackbuild , etc. As per standard slackbuild, the build actually takes place in the /tmp directory. For the addons, I've created an addons subdirectory in the kodi-18 directory to make archiving easier at the end of the day! I moved into the addons sub-directory and ran your script (having made suitable adjustments to the paths), but when I attempted to use your script for platform, the build failed, but the README file suggested:
Code:
git clone https://github.com/Pulse-Eight/platform.git
mkdir platform/build
cd platform/build
cmake ..
make -j8
make install
ldconfig
It was creating the build sub-directory and building from within there that solved the problem!
Then I hit the buffers with the kodi-platform build, where you appear to have spotted my error! I will have another go at this tomorrow!
Once again, many thanks to all for your support and help! Hopefully this thread will be of use to others attempting the same!
I'm hoping that at the end of this saga I'll be able to provide an "idiot's guide" that will enable others to avoid the pitfalls in to which I'm running!
Already available!: https://www.linuxquestions.org/quest...5/#post5957433
(specific for Slackware ARM & Raspberry Pi - but if you read over those particularities, I'm sure you'll learn also some generally applicable hints&info)
Quote:
Originally Posted by pchristy
Ah, yes! You are building on an ARM platform. I'm building on x86_64. My standard build procedure is to have a "Build" folder in my home directory, containing (in this instance) a kodi-18 subdirectory containing the tar.gz source file, slackbuild , etc. As per standard slackbuild, the build actually takes place in the /tmp directory. For the addons, I've created an addons subdirectory in the kodi-18 directory to make archiving easier at the end of the day! I moved into the addons sub-directory and ran your script (having made suitable adjustments to the paths), but when I attempted to use your script for platform, the build failed, but the README file suggested:
Code:
git clone https://github.com/Pulse-Eight/platform.git
mkdir platform/build
cd platform/build
cmake ..
make -j8
make install
ldconfig
It was creating the build sub-directory and building from within there that solved the problem!
Again, it shouldn't matter for what platform I'm (manually) building, there is general knowledge in that post.
Yes, I'm using the /kit/kodi-slack-build/ as an absolute path & convention for the built top tree, just to make sure the whole HowTo is, as you say, idiot proof. But you can always modify my instructions and substitute /kit/kodi-slack-build/ with /tmp/
As for building the add-ons, these are wrapped in cmake and if you run the commands I presented, cmake will automatically create the platform/build directory and build the add-on. Please follow them, they're the way to properly build the add-ons with cmake.
Bingo! Finally got it all to work! I don't know what I did wrong yesterday (probably a bit tired!), but starting afresh this morning, everything built perfectly, once I'd adjusted the paths.
Thank you very much for your help!
The whole process is still a little untidy in that, aside from kodi itself, everything else installs directly instead of via the slackware packaging tools. I don't see an easy way around this, as everything has to be done in just the right order to enable success. However, that is something to think about for the future!
Later today, I will sit down and document the steps I have taken to get it all to work. Hopefully this will help others in the same situation as me!
In the meantime, thanks for your invaluable input!
Happy to hear you got it finally.
I think you didn't do anything wrong but didn't realize you had to be root to be able to create /kit/kodi-slack-build/ and work in it and I was not explicit about it. As root, after you created /kit/kodi-slack-build/ you shoud have chown it to your user:
and then switch back to your user and work in it. In /tmp you have write access by default as a user and that's why you succeeded.
I'm always doing compilation work as root, I don't advocate this, but I also don't see a sense in not being root.
Besides, I'm also always putting the /tmp folder on a dedicated partition (good practice) and on ARM (Raspberry Pi), due to the small storage size of the SDCards, I'm keeping this partition at 1GB. I wouldn't start a big compilation like kodi in 1 GB space...
Now, with your experience, I edited my new Kodi 18 How-To and added these root requirements details - at the beginning - in bold, section:
"Edit: - some more "idiot-proof-ness" https://www.linuxquestions.org/quest...5/#post5957433
You shouldn't regard the Slackware ARM that different form main Slackware X86, it's the same, just the boot sequence differs according to the ARM platform, the toolchain is a little different (transparent for you anyways), there are some patches applied to the core Slackware packages by the maintainer (drmozes) and there are some specific switches to use for optimization purposes during compilations, but these switches are not mandatory, since the toolchain already optimizes the code "averagely".
Like you, I always do my compilations as root, so I don't think that was the issue. But there is one other thing that is bothering me slightly. I'm only passingly familiar with the Raspberry Pi, but I believe its a 32-bit system? I'm building on a pure 64 bit system. On Slackware64, 64 bit libraries should go in lib64. As a rule, the plain lib directories are almost empty. However, I believe that the various 'buntus work the other way around, with lib being the default directory, and lib32 used in multi-lib setups. (Anyone able to confirm this?)
Since Kodi seems to have been developed for Linux on 'buntu of some flavour, various stages of the build seem to be putting stuff in /usr/local/lib when I think they should be going in lib64. I'm not expert enough to know the ins and outs of this, nor familiar enough with the cmake process to know how to fix it, but it is something that needs addressing.
It would also be nice to get the pre-build stuff (crossguid, etc) and pvr.hts into proper slackware packages, though as they are fairly small, and going into /usr/local anyway, this probably isn't too much of an issue. Just me wanting to be tidy!
Whatever, it is currently working, and when I write it all up, this is one thing that I'll have to warn about as a TODO item! This is going to be very much a work-in-progress, and hopefully, those, like yourself, with more experience than I will be able to fine tune things.
But at least I now have a build process that works, thanks in no small part to your input!
Forgot to give you some hints about packing the addons, once you compiled them. If you take this sequence:
Code:
mkdir /tmp/addons-18/
cd /tmp/addons-18/
git clone https://github.com/Pulse-Eight/platform.git
cd /tmp/addons-18/platform/
cmake -DCMAKE_INSTALL_PREFIX=/usr/local
make && make install
ldconfig
In order to be able to pack it, you'll stop after the first make - the one in bold, and then follow the "I don't have time" section from this wonderful How-To: https://docs.slackware.com/howtos:sl...ding_a_package
And proceed with the following sequence:
Code:
#start clean
rm -rf /tmp/build
mkdir /tmp/build
make install DESTDIR=/tmp/build
strip -s /tmp/build/usr/local/lib/* /tmp/build/usr/local/bin/*
cd /tmp/build
mkdir install/ && cd install/
mcedit slack-desc
Put in slack-desc whatever info you want by respecting the format, for example:
Code:
# HOW TO EDIT THIS FILE:
# The "handy ruler" below makes it easier to edit a package description.
# Line up the first '|' above the ':' following the base package name, and
# the '|' on the right side marks the last column you can put a character in.
# You must make exactly 11 lines for the formatting to be correct. It's also
# customary to leave one space after the ':' except on otherwise blank lines.
|-----handy-ruler------------------------------------------------------|
platform-addon: platform-addon for kodi 18
platform-addon: bla bla bla
Then, create the package:
Code:
cd /tmp/build/
makepkg -l y -c n ../platform-addon-package.tgz
# move it form /tmp to your storage place
mv /tmp/platform-addon-package.tgz /your-storage-place/
#and clean up the mess
rm -rf /tmp/build/
See, you don't need to create a Slackbuild script, but only pack your compilation and then install the package with installpkg. Some compilations are not that simple and might require some preparation before putting them in a package. You get a lot of inspiration in other existing slackbuilds from slackbuilds.org
Like you, I always do my compilations as root, so I don't think that was the issue. But there is one other thing that is bothering me slightly. I'm only passingly familiar with the Raspberry Pi, but I believe its a 32-bit system? I'm building on a pure 64 bit system. On Slackware64, 64 bit libraries should go in lib64. As a rule, the plain lib directories are almost empty. However, I believe that the various 'buntus work the other way around, with lib being the default directory, and lib32 used in multi-lib setups. (Anyone able to confirm this?)
Since Kodi seems to have been developed for Linux on 'buntu of some flavour, various stages of the build seem to be putting stuff in /usr/local/lib when I think they should be going in lib64. I'm not expert enough to know the ins and outs of this, nor familiar enough with the cmake process to know how to fix it, but it is something that needs addressing.
You're right. Slackware ARM is 32 bit and on Slackware x86-64 you'll have lib64 folders but the addons will know how&where to install (the build scripts are smart enough to notice the difference). Actually the addon build script will read the content of the core Kodi cmake files, the ones you deleted in your first attempt to build Kodi (that line I asked you to comment) and in those cmake files the path to lib64 will be available.
Quote:
Originally Posted by pchristy
It would also be nice to get the pre-build stuff (crossguid, etc) and pvr.hts into proper slackware packages, though as they are fairly small, and going into /usr/local anyway, this probably isn't too much of an issue. Just me wanting to be tidy!
One way is to archive the build tree (source code and the compiled binaries) with the exact (&absolute) path and then, when you want to uninstall something, unpack them, enter the source directory and issue "make uninstall", but that is not always clean. Better pack them like I instructed you in my previous post.
I'm doing a lot of fine-tuning for ARM, because the ARM CPUs are orders of magnitude weaker compared to the actual (billions of transistors) x86 CPUs. For a "monster" like Kodi, you need to "squeeze" all the juice from those little ARM SoCs, that's making use of all the HW acceleration possible&available.
You're welcome(again)!
Last edited by abga; 02-06-2019 at 04:55 AM.
Reason: rewording
It would also be nice to get the pre-build stuff (crossguid, etc)
Just noticed this and had a look again in your SlackBuild (post #1).
If you read section 3.2: https://github.com/xbmc/xbmc/blob/ma...l-dependencies
You'll learn that you can build flatbuffers, crossguid and libfmt internally in Kodi (rapidjson I had to compile on my own, it didn't work).
In your SlackBuild you're doing this compilation separately and you can add the following (in bold) to your cmake line:
You are right! I missed that completely! For some reason, I assumed that crossguid, etc, had to be built and installed prior to building kodi itself, or else the build would fail! D'oh!
That also simplifies the packaging a lot! It means I only have to devise a slackbuild for the addon "helpers" and pvr.hts - everything else will be included in the kodi slackware package! Excellent!
I have a few other things I have to get on with today, and it will probably do me good to get away from a computer screen for a while, and come back to this refreshed later today or tomorrow.
Ah! OK, so we're not there yet! I've managed to make a slackbuild that will build the "helpers" and pvr.hts, and thought I had a slackbuild that would make kodi itself. I therefore removed all traces of kodi from my system and went for a new build. The kodi build failed! It looks like you can't build flatbuffers at the same time as kodi - it has to be built and installed first, as I originally thought.
I'm attaching my slackbuild, and here's the error:
crossguid was required to be built before the Kodi compilation in Kodi 17.x, it can be built internally in Kodi 18, I did it 2 times already.
As mentioned before, in Kodi 18 I only had to build rapidjson before the compilation (on Slackware ARM), adding it as a "-DENABLE_INTERNAL_RAPIDJSON=ON" to the cmake line didn't help. But I haven't got a compilation failure because of it, instead, the cmake project preparation script would throw me an error while looking after it and it won't build it internally. But maybe my "-DENABLE_INTERNAL_RAPIDJSON=ON" syntax was not right, haven't checked that...
I haven't got issues with instructing cmake to build crossguid, flatbuffers and fmt internally, with:
The initial cmake - project preparation would print:
Code:
-- Found CrossGUID: /kit/kodi-slack-build/kodi-build/build/lib/libcrossguid.a (found version "8f399e8bd4")
...
-- Found FlatBuffers: /kit/kodi-slack-build/kodi-build/build/bin/flatc (found version "1.9.0")
-- Found Fmt: /kit/kodi-slack-build/kodi-build/build/lib/libfmt.a (found version "5.1.0")
The short error snippet you presented is not really helpful, it might not even be related to flatbuffers, as the compilation is done in parallel and there are make jobs doing different tasks.
In your /tmp/PC/kodi-build/CMakeFiles/ you should inspect the two files: CMakeError.log & CMakeOutput.log, maybe you can spot something there.
And, while testing, you could change the make line in your SlackBuild and generate a compilation log:
Nevertheless, if still failing, change the main cmake line back to its original form (SlackBuild from post #1) and build the crossguid, flatbuffers and fmt individually, like you did it successfully in the first place.
Last edited by abga; 02-06-2019 at 05:56 PM.
Reason: typo
@abga: Thanks again for you thoughts. I built fstrcmp and rapidjason separately prior to building Kodi-18 the first time around and they are still there. I don't have a problem with building those dependencies as slackbuilds are either available or simple to produce.
I'm not going to get much time on this today. I was notified yesterday afternoon that a friend and colleague had died suddenly and unexpectedly, and I'm going to have to spend a lot of today dealing with the consequences of that, but I will get back to this in due course.
I think I've found the problem - which also explains why it builds on the Pi, but not on x86_64!
I'm not that familiar with the Pi, but I believe it uses a single core processor. On x86_64, if you set -j > 1 during the cmake --build process, the flatbuffer build is not complete before its needed! Setting -j1 - or not setting it at all - allows the build to complete perfectly!
So, I now have a slackbuilds for both kodi-18 and the kodi-18-addons that work. I've only tested the addons slackbuild with pvr.hts, but in principle it should work with any other addons that are built in a similar fashion.
I'm attaching both here so that others can have a go and avoid the pitfalls that I've fallen into!
The process is as follows: If you don't already have them, download and install the dependencies: fstrcmp and rapidjson. Download xbmc-18.0-Leia.tar.gz from here: https://github.com/xbmc/xbmc/releases and put it in a suitable directory, along with the kodi-18.Slackbuild. Run the slackbuild. The completed package will be in the /tmp directory, and can be installed with the standard slackware package install commands.
run ldconfig
Put the kodi-18-addons.Slackbuild in a new folder and run it. This will download the required source codes for platform, kodi-platform and pvr.hts, and build AND INSTALL them in the correct sequence. The completed packages will be left in /tmp and can be archived in case they should ever need re-installing. The resulting packages can also be un-installed using removepkg.
Its then just a case of running kodi and activating the pvr.hts addon.
If you need any other binary addons, they can be added to the end of the addons slackbuild using the pvr.hts as a guide.
Any comments gratefully received, and once again, many thanks to abga for his help and assistance!
I think I've found the problem - which also explains why it builds on the Pi, but not on x86_64!
I'm not that familiar with the Pi, but I believe it uses a single core processor. On x86_64, if you set -j > 1 during the cmake --build process, the flatbuffer build is not complete before its needed! Setting -j1 - or not setting it at all - allows the build to complete perfectly!
Most modern ARM (development) boards are multi-core and I'm building Kodi on Raspberry Pi 2B/3B, which are both quad-core, with 3 (due to RAM limitations) or 4 make jobs, otherwise it'll take a lot of time to complete the building process. Only the original and "obsolete" Raspberry Pi was single-core.
I doubt that the issue you were experiencing was caused by parallel compilation, because there are mechanisms in place that should avoid such compilation breakages: https://www.gnu.org/software/make/ma.../Parallel.html
- cmake is also able to build in parallel since 3.14 https://cmake.org/cmake/help/latest/...LEL_LEVEL.html https://cmake.org/cmake/help/latest/...uild-tool-mode
A full compilation failure log might provide more details about what really happened and if it's because of the parallel execution, then it should be reported to the Kodi devs, in order to fix the building process.
I tend to believe it was more of a download failure/timeout on some of the source packages the Kodi script is taking from the online repositories (the sources for crossguid, flatbuffers and fmt could be downloaded), as this happened to me several times while building Kodi 17.
While I'm not using SlackBuilds, other than for inspiration/patches, and not really experienced with creating them, I noticed they are not optimized for parallel compilation and maybe this is the right/safe approach. There is no magic formula to determine the optimal number of parallel compilation jobs for every system, see: https://www.linuxquestions.org/quest...ml#post5951040
But, with such a "monster" like Kodi, a parallel compilation might be tolerated. Using the following make statement should be OK:
Code:
# for make
make -j$(nproc)
# the original from the Kodi documentation for cmake
cmake --build . -- VERBOSE=1 -j$(getconf _NPROCESSORS_ONLN)
I took a look at your SlackBuilds and here are my comments/suggestions:
1. kodi-18.SlackBuild
- here, if you believe that the parallel compilation broke the build and want to play on the safe side, build the crossguid, flatbuffers and fmt dependencies individually and sequentially, as you did it in your original SlackBuild. They will be built inside the Kodi source tree and will be automatically taken from there by the final Kodi "make install" (Kodi's own build scripts), thus, you don't need to care about handling them individually with SlackBuilds.
- and then, for the main Kodi compilation, use multiple cmake jobs. It's a huge compilation and you should make use of all the resources a system might provide. Put back/uncomment the number of cmake jobs:
2. kodi-18-addons.Slackbuild.txt
- in this SlackBuild you're using "make -j8" for the compilations and that number might be a little too high for most of the systems. Additionally, these Add-Ons are pretty small and would compile very fast even by using one core. My suggestion would be to either use a simple "make", or substitute "make -j8" with:
Code:
make -j$(nproc)
Last edited by abga; 02-09-2019 at 07:57 PM.
Reason: are
OK, this is getting weird! My main desktop machine is a quad-core Intel i7 based device with 16GB of ram. I use it for video editing, hence the high spec. Although its a quad core, the hyper-threading makes it look like 8. In my workshop, I have my old desktop machine. This has a quad-core AMD Bulldozer CPU with 8GB of ram.
On the AMD machine, I can leave the -j to auto-detect the number of processors, and kodi builds perfectly. If I leave the Intel machine the same way, I get the error. (Logs attached) Could it be something to do with the hyper-threading?
To test this theory, I've just tried building on the Intel machine with -j4 - it builds perfectly! Set it back to autodetect, and it fails! Put it back to -j4 and it builds! It looks as if that line:
needs modifying to detect the number of *real* processors, not virtual ones. I'm going to go away and have a Google for that, but if anyone knows how to do that, I'd like to know!
I'm attaching the log files from the failed build in case they give a clue as to what is going on.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
