Question about missing dependencies in Slackware 14.2 multilib
 

Hi there everyone,

I first noticed this problem whilst trying to get the acestream software to install on my system the other day. So far I've only got it working under wine, which is fine, but there are packages for Ubuntu and Debian available as well as the source code.

However, when I tried to either compile the source or use the makepkg and deb2tgz tools I began to get errors saying that 6 libraries were 'not symbolic links'. Following this, other unrelated packages I did successfully install started issuing these warnings every time as well.

I've removed all of what remained of my clumsy efforts to get this to work and run ldconfig as root, so I don't get the messages about these libraries at the moment. But, if I run one of the scripts here: https://www.slackwiki.com/Dependency_Discovery

I still get this list of missing libraries. The avcodec and avformat ones, were two of the problems before.

What I'm asking is do I need to get these relevant 6 libraries sorted before I have a chance of getting the acestream software to work in my Linux and how do I do that? I noticed that with the code, it seemed to asking for older versions of libavcodec etc. - perhaps because its a couple of years old.

https://bitbucket.org/AceStream/acestreamplayer/src

http://wiki.acestream.org/wiki/index.php/Download

I'm having trouble getting much useful from the link to the forum because it seems to be in Russian mostly.

I think someone else posted on this a couple of years ago, which I found and it prompted me to try it.

If those 6 libraries are dependent upon acestream working than yes; you will have to install them in the order in which they are listed.
With Slackware you have to satisfy the dependencies first. Once all of the dependencies are installed than you would proceed with the installation of the software.

Do do that you will have to go to the SlackBuilds repo, download them, run the SlackBuild script's, wait for the script to finish and than install them one at a time in the correct order <or> you can use sbopkg.

https://slackbuilds.org/result/?sear...vcodec&sv=14.2

https://sbopkg.org/

Package Management
https://docs.slackware.com/slackbook:package_management

You mentioned Ubuntu and Debian in the beginning of your post.
Have you been able to install acestream on those distro's w/o wine?

I'm not sure what script you ran to get that output (there were several on the page and I was too lazy to dig through the code to see what output matched which script), but have you verified those files don't exist and whether or not those packages were installed?

As for acestream, if you are using a pre-compiled binary, it might rely on older version of certain libraries. Trying to force installing older versions to support these dependencies could break other program already on the computer. Since you said it was available as source, have you considered compiling it? That should ensure it is built against the libraries already installed on your system rather than play the "dependency hell" game trying to match dependencies on your system with the ones required by the program.

If you don't mind me asking, why not just use VLC or Amarok?

Most of the time I play the dependency hell game but that's because I was taught that way by a ancient master (frankbell) that was running Slack before there was a SlackBuilds repo:-

Is there a guarantee bassmadrigal, that by compiling from src that the lib's will be right?

It can only build against what's installed in the system, so in that way, yes. However, it also depends on the requirements of the program. If it requires older or newer versions of libraries, then it may not be able to be compiled.

However, now that I'm at a point where I can look into this more (the acestream site is blocked at my work), it looks like this would be quite the project to build as it requires you to build vlc during the process (which means all the dependencies of vlc). I wasn't willing to dig into it too much more than that.

Thanks for answering my question.
I very rarely compile from src and needing other older and or a mix of newer lib's is one of the reasons I don't compile.

Also, another one of our members here advised me a long time ago not to mix compiling from src and programs from the SlackBuilds repo. If I recall correctly it's not good for the system.

======***=======*******======******======******======******======******======
Yup looking at that page that OP posted all the depends for vlc are required so if it were my system I probably wouldn't pursue it:-

That's a lot of work:-:)

Are you sure this is still a living project?

Since I already build vlc and deps from source anyway, I was somewhat intrigued by this project. However looking at the instructions, I noticed that vlc version 2.1.5 was mentioned - very old. Then I saw that the latest change to the source code repo itself was in 2014. That's where I stopped looking - or maybe I was looking in the wrong place (https://bitbucket.org/AceStream/acestreamplayer/src)?

chris

But programs from SlackBuilds ARE compiled from source, but through a script (SlackBuild), supplied BY that website. They have just already decided which options to configure the package with.

OK, I've tried installing the dependencies for VLC (as suggested by the build instructions with the code) using sbopkg, but lots of them come back with errors.
I don't know how I've managed to get so many 'gaps' in my system already, but lots of things won't build with sbopkg because it cannot find things.
But, if I run the SlackBuild scripts individually, often they will work that way instead.

No, I'm not running ubuntu or debian, so I haven't tried those packages on those distros.

This is really not very common. Most programs compiled from source have a wide range of versions they're able to support. Only occasionally have I run into issues where the program wants a newer version of library than what I have installed. And you tend to only run into issues with programs wanting older versions of a library if the library had a substantial rewrite or the program hasn't been updated in a long time (back when the kernel went from 2.6 to 3.0, a lot of programs relying on the kernel wouldn't compile because they only checked for a 2.6.x version and didn't look for anything 2.6 or greater.

The problem is much more likely to happen when you use pre-compiled binaries. If you get binaries that are designed for 14.2 (or -current, if you're running that), you won't typically run into problems since the dependencies should match what's already installed on the system. But if you try and take a package from -current and install it on 14.2, many times it won't work because it depends on a specific version of a library that's in -current and not in 14.2. This also applies when you take pre-compiled binaries for other distros. The likelihood of having the same dependency versions goes down drastically.

Luckily, many libraries, while they may have different versions, sport the same ABI, so multiple versions will have the same compatibility and will work without issue. This is why, while still not very likely, it is much more likely to run into issues with pre-compiled binaries rather than building from source. If you look at -current's changelog and search for "Shared library .so-version bump.", you can see that while this happens occasionally, it's not a normal thing. But sometimes when that library needs to be updated, it causes a massive amount of packages to be rebuilt, because they all rely on the older version (an upgraded openssl required 61 packages to be rebuilt).

As ehartman stated, most of the SlackBuild from SBo are compiling the software from source. What that member likely meant was that self-compiling software typically installs into /usr/local/, where SlackBuilds tend to install into /usr/. While this isn't typically an issue by itself, items installed into /usr/local/ aren't typically tracked by the package manager and most of the time, things in /usr/local/ have precedence over /usr/, which means if you manually compile fakeprog-2.0 and it is installed into /usr/local/, but you find it doesn't work and then find a fakeprog-1.0 SlackBuild that is supposed to work and it is installed into /usr/, most programs are going to look at the fakeprog-2.0 installed into /usr/local/, and unless you kept the source, you can't uninstall it easily.

This is an unlikely example, but I typically don't recommend manually compiling and installing software since it won't be tracked by the package manager and makes it more difficult to uninstall. If I need to build something that doesn't have a SlackBuild, I'll figure out the compile options by manually compiling it, but NOT installing it. Then I'll create a SlackBuild so that I can create a package that can be installed.

The thing I see more frequently on the forum is don't mix and match binary packages from multiple repos, as they might have different versions of dependencies they rely on. You tend to not run into problems if they're standalone repos, only designed to install one thing (ktown, mate, etc). And, while I don't know if this is intentional, it seems like Eric's repo tends to mix with repos based off of SBo pretty well.

Sorry for the novel...

Those files DO exist, in the case of for example, libavcodec.

EDIT: Actually, they don't, do they - comparing the two lists! But the problem when I tried to compile the code, was that the required libraries weren't symbolic links. Which I looked up and it was suggested to delete one version of the file and then create a symlink to another, with the required name.

However, that list above is different to what I had on Sunday - there were 3 versions of libavcodec in the /lib folder, each with a more precise name (libavcodec.so.56 ... libavcodec.so.56.123, or whatever). The error messages were telling me that the problem was that none of them were symbolic links. And they weren't, they were regular files, I think.

If this is a stock Slackware 14.2 install, the files should be symlinks. On my system, I have the following:

Can you provide us the actual error message? And what you're doing to get it? Once I get home, I may be able to try things out to get a working version and let you know what you need to do.

No, I don't mind you asking. I don't know if you've used the acestream software or not, but it has a couple of components, the ace-player is just like vlc, but the 'ace-engine' is the server which you need to have running to connect to the swarm of people sharing the stream. I don't think you can access these streams which have 'Content IDs' without having the engine/server running and I don't think you can access them using regular VLC alone. The windows package installs all of this at once. I do have VLC 3 installed from alienbob, because I can access the acestream server on a localhost webpage, and send the stream through VLC to my chromecast - whereas doing it direct from a browser or from the ace-player to chromecast doesn't seem to work.

All that slackware needs is to have the ace-engine part running, therefore. I guess the source code is building this ace-player as well, which is unnecessary.

I might be wrong, however - perhaps there is a way to connect to these streams from ordinary media players that I haven't tried.

Right, I know now where the extra versions of libavcodec.so and so on came from now (that caused the error messages). They came from the debian package on that webpage which I tried extracting, making into a package and installing. Now that I've removed that, they're gone.

As for the code, it has a config.sh, a bootstrap.sh and configure.sh. The config.sh you're supposed to edit for your 'HOST', then run bootstrap.sh. Somehow I got through the bootstrap part before, just by changing the HOST type to "x86_64" from "i686-w64-mingw32". You can also edit the VLC version, which is 2.1.5, as someone said. I tried changing that to 3.0.4 just now. Neither version will work now, anyway. I get:

And, if I try using sbopkg to build the dependencies for the latest vlc on there first, as I should - loads of them won't.
The first one that fails is libbluray. I.e.:

But I do actually have it installed:

Thanks for explaining.

I'll have to read how to create a SlackBuild in order to install a pkg.:)

@Pipeline79

Thanks for explaining why you didn't want only VLC or Amarok.
It sounds like ace stream is more than a regular player.

Sorry your still getting errors that I am not able to help with.

Start here and then fill in the blanks while removing the comments after you read and understand them.

https://slackbuilds.org/templates/

Thanks-:)

Good to hear. When you convert a package from another distro, it's good to run installpkg --warn /location/to/package.txz as this will notify you if it is going to overwrite any existing Slackware files. I'm wondering if that is related to your libxml error below, but I'll get to that in a bit.

You can also remove the i686-w64-mingw32 from the HOST variable and leave it blank. I read somewhere, maybe on the website or one of their readmes, that you needed to do that on Linux.

This specific error is because it is trying to patch vlc, but the patch wasn't designed for this version and the code doesn't match, so it doesn't know what to change. I was able to get through this section with leaving the version at 2.1.5, so I'm not sure why that's failing. But if you want to run 3.0.4, you have a few options, either try running it without any patches comment out line 78-84 in bootstrap.sh. If you want to try and load the other patches (so far, 10-locale.patch is failing), change the else in line 81 to elif [ "$i" -gt "10" ]; then and see if it is able to patch the rest.

This looks like you might've accidentally overwritten Slackware files when you installed that converted package. The first thing I would attempt is to reinstall libxml2 and libxm2-compat32 to make sure it is installed properly.

I think it will prompt for both the regular patched version as well as the compat32.

If that doesn't work, we'd need to look at the config.log that is generated. It is most likely in /tmp/SBo/libbluray-1.0.2/config.log. This will hopefully help point us to the reason why it isn't working.

The link orbea posted is the templates that SBo uses to generate SlackBuilds. They are a bit more complicated than what a simple SlackBuild could contain, but most of that is to ensure uniformity of packages provided by SBo. A *very* simple SlackBuild is below.

You just need to set the PKGNAM and VERSION variables and add any ./configure options you need.

The big difference with making a Slackware package instead of installing directly is using the DESTDIR variable on make install. This will install everything for that program in the directory you specify. Then you just cd into that directory and run the makepkg command. If you want a description for the package when installing, you would need to make a slack-desc file and put it under a $PKG/install/ directory, but it isn't required.

Most of the first half of the above is just to simplify making the package by setting default directories where it will extract the source and temporary install location, as well as removing any previous attempts at packaging and extracting the source.

Once you understand the basics of what a SlackBuild does like the above, then the templates SBo uses can be understood better. They have examples for multiple build tools like autotools (which uses configure), cmake, python, and more.

Thanks for your help bassmadrigal & Ztcoracat. I'm going to go through your suggestions now.

You're Welcome-

I hope you get it installed and working.

==================******======================******=======================******=================== =======******============

I'm still reading the links in the pages you linked orbea; Thanks:-

bassmadrigal,
Thanks for the simple script:-:)

OK, I can get the required packages for VLC built using sbopkg now.
I was also able to get a compiled version of VLC-3.0.1 made with the scripts in that code, but I had to comment out the 'patches' and it seems like if I do that I just end up with a regular version of VLC. Not that useful!

After looking through the instructions more thoroughly for the Ubuntu/Debian archives I tried to install, I don't think you're supposed to actually install them as packages. You're supposed to extract them to your /opt directory and just run a 'start-engine' script from there and that gives the engine part I wanted, that's it.

Unfortunately, seems they don't work on Slackware because of slackware Python being UTF-2 not UTF-4 encoding. Someone else has already posted about this and tried working round it by installing a custom python environment for this with pyenv. Still not working though.

But, I can get a readymade docker image for this working fine for now, so I guess I can't complain too much. Don't need wine.

Were you able to get acestream installed?

Hi,

No, not by trying to build the code on the bitbucket link, or by adding one of the other Linux packages to the /opt directory and running that from there.

The build instructions suggest you alter the 'config' file to which version of VLC you want to use as the base. Then you run the 'bootstrap.sh' script before doing the 'configure.sh' and finally doing 'make'.

At the 'bootstrap.sh' stage I still can't get it successfully processed without removing the lines in that script which refer to 'patches'. There is a 'patches' folder within the directory I'm working from. My guess is these need to be added to give the acestream functionality to the VLC player, and possibly create the acestream server as well.

As for running one of the packages for Linux, only tested on Debian or Ubuntu from the /opt directory, I just get this:-

Somebody else on this site tried to get this to work too: https://www.linuxquestions.org/quest...074/page3.html

Sorry to hear you haven't been able to get it to work.

I'm not sure what else you can try.