What If .........Slack needs Systemd (Slackbuilds)
SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Systemd should build with -j2 or higher MAKEOPTS flags. If it's not then I'd do a query of any dependencies in the system and double or triple check everything before continuing. Check your compiler as well.
One minimal build I've seen (LFS-systemd experimental) disables gudev and python support from the main build.
As an option try testing flags...
These flags are for entirely optional features according to the documentation. Maybe it's something else though if this isn't it.
Has anyone checked the configure script to see if a flag for
Tobi, I was able to reproduce the same error with an AMD CPU only.
libsystemd-shared.la is being build by systemd itself, so either amd cpu's are doing some different things in parallel, or there is something different wrong.
I have currently no Intel systems available, the building was done on an Athlon QL-66 (dual-core) and a Phenom II X6 (six cores), both had that problem. Might be reasonable to add the information to your Wiki that in case of errors on AMD CPUs compiling with -j1 is recommended.
Congratulation, bartgymnast! Looks like you successfully ported that (so hatred) SystemD into Slackware!
Agree. It looks like it is compiled. Now to actually make it work takes a good bit of changes to the startup scripts, and in some cases, changes to the services themselves.
Then, we have SystemD. Beyond of that, is just a question of taste (or religious beliefs) on using it or not.
Not exactly. It is a question of reliability. Network analysis for dependencies is an NP hard problem. It can be done for small environments such as desktops. But then, the time it takes is better put to use in actually starting them than in computing which comes first. Systemd attempts to do that with a "preprocessed network state"... Unfortunately, it can't be reliable as some things depend on outside operation before they can be started. Also systemd has trouble with timing issues - look at NetworkManager. Systemd has to depend on NetworkManager to tell it when things are ready, unfortunately, NetworkManager also depends on external things (like DHCP, DNS...) to be ready, and some of them aren't. By default systemd assumes the network is ready when NetworkManager is started... or (if directed) when NetworkManager tells systemd the network is ready. Then systemd starts things that depend on the network... like apache, which has been known to fail because the network isn't quite ready (dhcp took a little too long), or DNS isn't quite ready (after all it takes time to load tables...). Sometimes it works - if other services cause these to delay a bit while they get started. But it is now a VERY hard problem to solve when it doesn't work. And then there are services that SOMETIMES have additional dependencies - like apache needing a database (is it local... or remote? or both?)
I've just compiled the systemd package on a freshly installed Virtualbox Slackware64 14.1 with an AMD Phenom II X4, with -j7, it did error on the readme while copying stuff over to the package. Tried to build it again with the "install readme" line commented out and it build successfully.