glibc mismatch?

[Maximillium]

Hi:

Using the most up-to-date DLH & Co-App - and having read just about everything in the group regarding this problem, (Thanks, Wild Willy and a few others)

here is a possible clue to check out:

2019-07-04:

Failed converting "G2Voice Broadcast #145 WHO is behind the Malaria Vaccine and WHAT is in it 6-23-2019"

https://www.brighteon.com/6054388118001

/usr/local/net.downloadhelper.coapp-1.3.0/converter/build/linux/64/ffmpeg: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /usr/local/net.downloadhelper.coapp-1.3.0/converter/build/linux/64/libavfilter.so.7)
/usr/local/net.downloadhelper.coapp-1.3.0/converter/build/linux/64/ffmpeg: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by /usr/local/net.downloadhelper.coapp-1.3.0/converter/build/linux/64/libavformat.so.58)
/usr/local/net.downloadhelper.coapp-1.3.0/converter/build/linux/64/ffmpeg: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /usr/local/net.downloadhelper.coapp-1.3.0/converter/build/linux/64/libavcodec.so.58)

2019-07-04 Failure at Brighteon.com using latest beta versions of VDH & Converter:

From VDH:

Could not get information from media 'G2Voice Broadcast #146 – What is the Endocannabinoid System in the body? 6-30-19 - Brighteon' from file '/home/chuck/Downloads/G2Voice/G2Voice #146 2019-06-30 -brighteon -1h52m59s- What is the Endocannabinoid System in the body.mp4'. The file might be corrupted.

{
    "file": "/home/chuck/Downloads/G2Voice/G2Voice #146 2019-06-30  -brighteon -1h52m59s- What is the Endocannabinoid System in the body.mp4",
    "stat": {
        "dev": 2050,
        "mode": 33188,
        "nlink": 1,
        "uid": 1000,
        "gid": 100,
        "rdev": 0,
        "blksize": 4096,
        "ino": 1835157,
        "size": 166448372,
        "blocks": 325104,
        "atimeMs": 1562285947348.4275,
        "mtimeMs": 1562286319738.4978,
        "ctimeMs": 1562286319998.4963,
        "birthtimeMs": 1562286319998.4963,
        "atime": "2019-07-05T00:19:07.348Z",
        "mtime": "2019-07-05T00:25:19.738Z",
        "ctime": "2019-07-05T00:25:19.998Z",
        "birthtime": "2019-07-05T00:25:19.998Z"
    }
}

Exit code: 1

/usr/local/net.downloadhelper.coapp-1.3.0/converter/build/linux/64/ffprobe: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /usr/local/net.downloadhelper.coapp-1.3.0/converter/build/linux/64/libavfilter.so.7)/usr/local/net.downloadhelper.coapp-1.3.0/converter/build/linux/64/ffprobe: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by /usr/local/net.downloadhelper.coapp-1.3.0/converter/build/linux/64/libavformat.so.58)
/usr/local/net.downloadhelper.coapp-1.3.0/converter/build/linux/64/ffprobe: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /usr/local/net.downloadhelper.coapp-1.3.0/converter/build/linux/64/libavcodec.so.58)

So DLH seems to depend on glibc 2.27.

My OS (OpenSuse Leap 15.0) only supplies glibc 2.26.

Info at https://groups.google.com/forum/#!search/glibc%7Csort:date
seems to indicate glibc versions up to 2.28 with many bugs being discussed.

Maybe the possible answer is to  include glibc 2.27 in the DLH install sequence,

possibly installed in a location (same directory as DLH) with pointers to it in DLH

so as not to interfere with the OS? (I had to do this with a cloud-storage service already....)

I know I'm talking out of my tookus here, but there has to be some answer to this somewhere....

[jc vdh]

thanks for this technical feedback, I forward to the tech team.

jerome

[mig]

Thanks for the feedback Maximillium.

Unfortunately we do not have the resource to provide and maintain all the missing standard library versions for the various flavours of Linux.

If you cannot update your OS version (i have no particular knowledge of the Suse distro), would you consider recompiling the vdhcoapp in your environment ? The source code is here: https://github.com/mi-g/vdhcoapp ?

[Wild Willy]

You know, there's this other guy having a problem on Linux over in this thread:

https://groups.google.com/forum/#!msg/video-downloadhelper-q-and-a/s5OJxObLNEM/yZlCUdSmBQAJ

Maybe you're seeing the same problem?

[Tom D Kat]

Yep, it's the same problem and the actual problem is described in this thread.  I'm running Linux Mint 18.3 and glibc 2.23 is installed.  So, I'll give building from source a shot and see what happens.  I need to install some software to do the build but hopefully, all will go well.  :)

Peace...

[me]

I can acknowledge the problem with glib 2.23. I had installed the latest version of companion application from the deb package. It seems that the package does not verify if mandatory requirements are met. The package is installed despite the fact that Ubuntu 16.04 LTS uses glibc 2.23. It would be better if the installation would stop and issue an error message stating the problem clearly.

Solution: Downgrade companion app to net.downloadhelper.coapp-1.2.3-1_amd64.deb.

[Vuurdraak -]

Im on Ubuntu 16.04 LTS and I got the same problem as GLIBC is version 2.23

I see below somebody says downgrade to: net.downloadhelper.coapp-1.2.3-1_amd64.deb

Only I can not find any downloads for this version anywhere, can somebody provide a link to this version of the download app ?

it's annoying that aggregating video's no longer function :(

[Mike Fuego]

Hi mig. Thanks for your info. As you can see (https://groups.google.com/d/msg/video-downloadhelper-q-and-a/oHuySIIEBc0/W2xL_q6FDwAJ) I'm having the same problem. In a first step, before recompiling, I think it would be very helpful when the older versions of the companion app would be available for download (archive). So we could first test little older versions and then see how it works.

Is there a version/download archive companion app available?

update (2hrs later):

Sorry. I have found the archive. Links are listed at top of this group (link https://github.com/mi-g/vdhcoapp/releases/ ). So I could install an older version.

(arg, yeah ok, first read then write...)

FYI:

With version vdhcoapp 1.2.4 everything works fine. No problems.

[Maximillium]

Mig:

What is in glibc 2.27 that VDH needs?  How about you guys recompile VDH with a version of glibc that users actually have?

May or not be the whole answer, but at least would eliminate that as a problem, might even make VDH start working for us who cannot get glibc 2.27 (?).

[Vuurdraak -]

I'm wondering if it even makes sense to use another downloadhelper executable, since the browser plugin detects that you got an older version of the coap installed and asks you to install the new version, I have continued with the latest broken coap versions, and manually render files if they are coming from Youtube by asking VDH to keep the temporary files, I then check the audio length to the video length if necessary to see which files belong together and render them in my favorite video renderer.

I did find a local: net.downloadhelper.coapp-1.1.1-1_amd64.deb

https://ufile.io/h6tt6dke

(Expires in 30 days, I don't know where to upload permanently quickly, and can not attach it here)

Edit: Owwww i missed the link to all the archived ones :D => https://github.com/mi-g/vdhcoapp/releases/ 

(Thanks Mike Fuego )

1.2.4 seems to indeed work fine :) https://github.com/mi-g/vdhcoapp/releases/tag/v1.2.4

[Maximillium]

Does VDH absolutely require glibc v2.27? 

What is IN v2.27 that is not supplied by v2.23?

Could VDH simply call on glibc without specifying the version?

I don't know - but is anyone trying to find out?

Please, you guys, re-compile VDH with glibc 2.23 so we can know?

Maybe even make it work for we who don't have 2.27 and can't get it?

[mig]

VDH does not need the glibc. The extension in javascript runs within the browser which provides the necessary standard library functions (through the glibc but this is not our problem).

The linux flavour of the companion app needs the glibc as it is a standalone application. The current version of the companion app is compiled under Ubuntu 18.04 (the latest LTS release). There may be incompatibility issues with linux distros/versions using an older glibc version. You may want to update your linux version or recompile the companion app in your current version but we do not have the resources to maintain versions of the coapp to run on old or uncommon linux distributions.

The companion app is open sourced from https://github.com/mi-g/vdhcoapp

[Maximillium]

Hello, Mig:

Color me frustrated as I can't seem to actually get an answer to my question.

O.K. - I (now) understand VDH doesn't need glibc - it's the javascript extension that needs it.

Perhaps if I rephrase the question?

Does THE EXTENSION absolutely require glibc v2.27? 

What is IN v2.27 that is not supplied by v2.23?

Could THE EXTENSION simply call on glibc without specifying the version?

Not trying to be "pushy" here - it's just that there are a lot of us out here who are having this problem of:

The App calls on a version of glibc that we don't have,

We don't have the knowledge with which to "compile" our OS,

Our OS may not be so ancient, just not as "bleeding edge" as your bloody Ubuntu (the next Microsoft trying to "take over the world"?),

and we wonder if the APP is calling on a specific version of glibc because there's something it does that earlier versions dont,

or if the APP could simply call on glibc without specifying a version.

Again, not trying to be a pest here, but without the use of a compatible glibc, VDH DOESN'T WORK for us.

There may be other issues as well, we don't know, but this glibc incompatibility is a stopper for sure since the received error specifies it.

Again:

Does THE EXTENSION absolutely require glibc v2.27? 

Is there something IN v2.27 that is not supplied by v2.23?

Could THE EXTENSION simply call on glibc without specifying a version?

[Wild Willy]

I've never run Linux but I feel your pain.  I haven't the faintest idea what glibc is.  But I believe you've misunderstood what Michel said.  The VDH extension running under control of Firefox does not use glibc.  Firefox apparently takes care of whatever requirements there might be to use glibc.  However, the CoApp runs separately from the browser & it is the CoApp that uses glibc.  Now, I find it very weird that an application would make a standard call to a standard API in some service package in such a way that the calls are unique to a particular release of that package.  Is glibc part of the operating system?  A separately downloaded tool package?  Bound into the CoApp?  Who knows, maybe some day I'll be using Linux & this will all come in handy for me.  For now, I'm just a bystander wishing you well in your quest for answers.

[Maximillium]

Willy ... I think I may have figured this "Posting" thing out....

I looked up glibc, and here's an explanation of what it is:

http://man7.org/linux/man-pages/man7/libc.7.html

and here's even more:

https://duckduckgo.com/?q=what+is+glibc+in+linux&t=ffab&ia=web

and I'm having the same problem as you as to how the version of glibc is such a problem.  Seems like the version of glibc in any particular OS would be sufficient for that OS.  In any case VDH and the coAPP work together, one doesn't work well (at all) without the other, and the consistent error received is that the coAPP CAN'T FIND version 2.27 - I guess everyone has to replace their OS to use VDH....

[Maximillium]

*Bump*

[Maximillium]

Willy:

Here's even more:

Linux From Scratch - Version 8.2

Chapter 6. Installing Basic System Software

6.9. Glibc-2.27

http://www.linuxfromscratch.org/lfs/view/8.2/chapter06/glibc.html

and:

Release/2.27 - glibc wiki

https://sourceware.org/glibc/wiki/Release/2.27#Release_blockers.3F

I might want to try this if I had another computer besides the one I depend on every day....

[Maximillium]

*Bump*

[Maximillium]

Groups

6 of 99+ (99+)

Video DownloadHelper Q&A ›

glibc mismatch? 18 posts by 8 authors

me (Maximillium change)

Jul 4

Me, too - murgt...@googlemail.com and Scott Friss

By	me (Maximillium change)

Attach a file

Edit subject

Quote original

 

Jul 4 jc vdh thanks for this technical feedback, I forward to the tech team. jerome

Jul 5 mig Thanks for the feedback Maximillium. Unfortunately we do not have the resource to provide and maintain all the missing standard library versions for the various flavours of Linux. If you cannot update your OS version (i have no particular

Jul 5 Wild Willy You know, there's this other guy having a problem on Linux over in this thread: https://groups.google.com/forum/#!msg/video-downloadhelper-q-and-a/s5OJxObLNEM/yZlCUdSmBQAJ Maybe you're seeing the same problem?

Jul 27 Tom D Kat Yep, it's the same problem and the actual problem is described in this thread. I'm running Linux Mint 18.3 and glibc 2.23 is installed. So, I'll give building from source a shot and see what happens. I need to install some software to do the

This message has been deleted.

Aug 8 me I can acknowledge the problem with glib 2.23. I had installed the latest version of companion application from the deb package. It seems that the package does not verify if mandatory requirements are met. The package is installed despite the fact

Sep 27 Vuurdraak - Im on Ubuntu 16.04 LTS and I got the same problem as GLIBC is version 2.23 I see below somebody says downgrade to: net.downloadhelper.coapp-1.2.3-1_amd64.deb Only I can not find any downloads for this version anywhere, can somebody provide a link

Oct 24 Mike Fuego Hi mig. Thanks for your info. As you can see ( https://groups.google.com/d/msg/video-downloadhelper-q-and-a/oHuySIIEBc0/W2xL_q6FDwAJ) I'm having the same problem. In a first step, before recompiling, I think it would be very helpful when the older

Nov 11 me Mig: What is in glibc 2.27 that VDH needs? How about you guys recompile VDH with a version of glibc that users actually have? May or not be the whole answer, but at least would eliminate that as a problem, might even make VDH start working for us

Nov 14 Vuurdraak - I'm wondering if it even makes sense to use another downloadhelper executable, since the browser plugin detects that you got an older version of the coap installed and asks you to install the new version, I have continued with the latest broken

Nov 19 me Does VDH absolutely require glibc v2.27? What is IN v2.27 that is not supplied by v2.23? Could VDH simply call on glibc without specifying the version? I don't know - but is anyone trying to find out? Please, you guys, re-compile VDH with glibc

Dec 8 mig VDH does not need the glibc. The extension in javascript runs within the browser which provides the necessary standard library functions (through the glibc but this is not our problem). The linux flavour of the companion app needs the glibc as it

Dec 10 me Hello, Mig: Color me frustrated as I can't seem to actually get an answer to my question. O.K. - I (now) understand VDH doesn't need glibc - it's the javascript extension that needs it. Perhaps if I rephrase the question? Does THE EXTENSION

Dec 10 Wild Willy I've never run Linux but I feel your pain. I haven't the faintest idea what glibc is. But I believe you've misunderstood what Michel said. The VDH extension running under control of Firefox does not use glibc. Firefox apparently takes care of

Dec 11 me Willy ... I think I may have figured this "Posting" thing out.... I looked up glibc, and here's an explanation of what it is: http://man7.org/linux/man-pages/man7/libc.7.html and here's even more: https://duckduckgo.com/?q=what+is+glibc+in+linux

Dec 13 me *Bump*

Dec 15 me Willy: Here's even more: Linux From Scratch - Version 8.2 Chapter 6. Installing Basic System Software 6.9. Glibc-2.27 http://www.linuxfromscratch.org/lfs/view/8.2/chapter06/glibc.html and: Release/2.27 - glibc wiki https://sourceware.org/glibc/w

me (Maximillium change)

3:50 AM (2 minutes ago)

*Bump*

- hide quoted text -

[Peter wein.peter]

Ubuntu 16.04 is still in use it is a long term service version and unless other versions very stable (so like 8.04, 12.04.,16.04... and unlike 10.04., 14.04., and 18.04 which are not as useful to use). Glibc is a important lib. You cannot easily replace it. I used patchelf to patch the companion lib but it was not working, now I see why.

Please you cannot change the rules and leave us alone !I think there are many users of 16.04 which will change disto in April next year. But not now. This is understandable cause you would want to work with your LTS as long as possible.

[Peter wein.peter]

I was able to compile and install on Ubuntu 16.04 LTS, while dissolving disgusting issues which took me 8 h ( most of it waiting for compiling):

1. Clone or download
   https://github.com/mi-g/vdhcoapp
   
   
2. Follow build.md in converter/. The scripts are very dumb, in every error case, the next build is a fresh 'rebuild all'. So all cloned dirs are removed and checked out cleanly again. This takes half an hour or so with a 50 MBit connection.
3. in get_sources.sh (converter), there has been an update of a git link:

replace orc.git line

(cd $SRCDIR; git clone git://anonscm.debian.org/pkg-gstreamer/orc.git orc; cd orc; git checkout "$ORC_VER")

with

(cd $SRCDIR; git clone https://salsa.debian.org/gstreamer-team/orc.git orc; cd orc; git checkout "$ORC_VER")

Execute get_sources and build.sh as described in build.md then. This took me 4 hours on my netbook (Asus ASUSPRO BU201LA-DT030G, Intel Core i7-4650U (Intel Core i7) with a Samsung Evo 850 ssd, so it's not complete slow, and I was astonished how long it took, a kernel compiling back then was rather faster).

1. On Ubuntu 16.04 you need to install the following:

sudo apt install npm
sudo npm install --global gulp
npm install -g n
sudo n 11.15.0

Links: 

http://benedictroeser.de/2015/03/grunt-findet-unter-ubuntu-node-nicht-usrbinenv-node-datei-oder-verzeichnis-nicht-gefunden/

https://stackoverflow.com/questions/55921442/how-to-fix-referenceerror-primordials-is-not-defined-in-node

Reason are compiling issues with Ubuntu default npm gulp installs. So node.js must be v11.x and gulp v3 for example to compile through. If you face some other issue, google for it. I think there was one 
issue left with a definition const { spawn } but I forgot how to solve it. Maybe with the upper mentioned commands it is updated correctly.

1. After running for linux x86_64 system:

gulp build-linux-64
gulp deb-linux-64

You have a ready compiled version 1.2.4 in builds/ folder, which you can install with the Software Updater. Then Downloading works again. On Youtube always with some irritating noisy features, but you get to results in most of the cases.




[jc vdh]

impressive, thanks for the feedback !

jerome

[Tom D Kat]

Thanks for the detailed instructions!  I managed to get the companion application complied, but didn't know how to get it installed.   I'll give your steps a try.

On a side note, for the Video DownloadHelper developers: would it be possible to statically link future versions of the companion application?  The executable will be much larger, but would avoid these kinds of problems.

Thanks!

Peace...

[mig]

On a side note, for the Video DownloadHelper developers: would it be possible to statically link future versions of the companion application?  The executable will be much larger, but would avoid these kinds of problems.

No sorry. This is not technically possible and it wouldn't pass Mozilla Firefox nor Google Chrome review anyway.

[Maximillium]

The EXTENSION fails as soon as it tries to access glibc v2.7.

Is there some reason we can talk all around this issue (glibc v2.7) and not actually answer it?

On Tuesday, December 10, 2019 at 6:35:10 AM UTC-8, Maximillium wrote:

Hello, Mig:

Color me frustrated as I can't seem to actually get an answer to my question.

O.K. - I (now) understand VDH doesn't need glibc - it's the javascript extension that needs it.

Perhaps if I rephrase the question?

Does THE EXTENSION absolutely require glibc v2.27? 

What is IN v2.27 that is not supplied by v2.23?

Could THE EXTENSION simply call on glibc without specifying the version?

Not trying to be "pushy" here - it's just that there are a lot of us out here who are having this problem of:

1) The App calls on a version of glibc that WE DON'T HAVE,

2) Most of us haven't the knowledge with which to "compile" our OS,

3) Our OS may not be so ancient, just not as "bleeding edge" as your bloody Ubuntu (the next "Microsoft" trying to "take over the world"?),

and we wonder if the EXTENSION is calling on a specific version of glibc because there's something it does that earlier versions don't,

or if the EXTENSION could simply call on glibc without specifying a version.

Again, not trying to be a pest here, but without the use of a compatible glibc, VDH DOESN'T WORK for us.

There may be other issues as well, we don't know, but this glibc incompatibility is a stopper for sure since THE RECEIVED ERROR SPECIFIES IT.

[mig]

I thought that was answered: recent coapp releases are compiled under Ubuntu 18.04 using glibc 2.27. If your system uses an older glibc version, you should recompile the coapp to build the package.

[Maximillium]

On Friday, December 27, 2019 at 4:50:00 AM UTC-8, mig wrote:

I thought that was answered: recent coapp releases are compiled under Ubuntu 18.04 using glibc 2.27. If your system uses an older glibc version, you should recompile the coapp to build the package.

Once again, and answer but no answer to THE QUESTION.  "I thought that was answered...."

YES, we now know that releases are compiled under Ubuntu 18.04 using glibc 2.27.

YES, we now know that it's the EXTENSION that calls on glibc 2.27.

The EXTENSION STOPS when it can't find VERSION 2.27 of glibc.

BEGGING THE QUESTION:

1) Does THE EXTENSION absolutely require glibc v2.27? 

2) Is there something IN v2.27 that is not supplied by other versions of glibc?

Could THE EXTENSION simply call on glibc without specifying a version?

Leading to another question:

3) If Ubuntu "upgrades" and uses another version of glibc, will THE EXTENSION cease to work because of the version change?

This is getting ridiculous.

[mig]

 

1) Does THE EXTENSION absolutely require glibc v2.27? 

The extension doesn't. The coapp does.

 

2) Is there something IN v2.27 that is not supplied by other versions of glibc?

This is the way it works: if you compile against 2.27 (as it is now) it requires glibc >= 2.27

 

3) If Ubuntu "upgrades" and uses another version of glibc, will THE EXTENSION cease to work because of the version change?

No, it will work well if the runtime version is >= 2.27

 

This is getting ridiculous.

Linux has some constraints. If you have this kind of problems and cannot solve them, I suggest you move to Windows.

 

[Vuurdraak -]

"Linux has some constraints. If you have this kind of problems and cannot solve them, I suggest you move to Windows" lol what BS

That is like saying , I am going to compile my program in such a way that it will only support the latest version of Windows, regardless if another version is still supported by Microsoft like Windows 8, and say we no longer support our program on a Windows version that is supported by Microsoft.

 As Ubuntu 16.04 LTS is still supported by Ubuntu for one and a halve years, but we refuse to compile our software in such away that the older version of Ubuntu can run it too.

Or saying it in a more simple way, why would you compile a program with a higher version of GlibC, when that program really doesn't need any functionality of that higher version, killing all the older versions of Linux who can not run that higher version, as all other software on the OS is compiled against a lower version, hence you would need to recompile ALL OTHER software on your OS to be able to use the higher GlibC library, or it won't run.

It's a bit like saying even though our program can run fine in DirectX 9, we are going to compile it so it can only run when you have DirectX 11 installed, just to annoy anybody who can not run DirectX 11.

In other words is there any functionality in GlibC 2.27 that the coapp desperately really needs, that is not in an older version ??? If not then it's just lazy compiling without thinking about the fact that using higher GlibC versions, will effectively make sure less people can use your program, without a real reason.

[mig]

By making the product completely free on Linux (while commercial on Windows and Mac) and distributing the software as open source, i would have expected that Linux users with not-so-common or older distributions would make the effort of running the build script in their environment.

[Vuurdraak -]

First of all we already got a solution by using an older coapp version, supplied here: https://github.com/mi-g/vdhcoapp/releases/tag/v1.2.4

So there is no need for anybody to jump through hoops and start compiling your own software, something that is not always as strait forward, as not everybody using Linux has a university software degree.

Also compiling your own software can cause that software to bloat when you do not know what your doing, as you might be compiling all (un)necessary libraries into the software, iaw DLL hell compiled in to your software, like OBS (Open Broadcasting Software) which I compiled my self so I can run it with NVenc support (hardware Nvidia encoder) is 2Gig in my system due to all the libraries that are linked in to it, to make it run.

By the way I am still using Ubuntu 16.04 LTS, because if I "upgrade" to version 18.04 LTS some programs that I am using will be removed from my computer, as they are not in the new 18.04 LTS repositories, making me lose functionality that I am using now (video editor filters in my case) which I might not be able to get running again in a new version of Ubuntu.

But sure you are right video download helper is free in Linux and I am happy for that.

Sstill if it is unnecessary to use a higher GlibC version, why use it if it creates problems for some people, who might just be somebodies mother or father, who their kid installed Linux on their lappy, and now they can not download videos any more:D ? 

[Catalin Suru]

Some videos don't work with older versions of VDH coapp, and, at least in Slackware 14.2, the source code for the latest version does not compile.

There is a solution to use the precompiled version of the coapp, with older linux distributions. This was done in Slackware, other distrbutions may need a few adjustments of the steps.

1. install the coapp. The tar.gz version dumps a directory. In bin/ we have the coapp binary, and in converter/ we have ffmpeg4, with the faulty glibc version for the codec libraries.

2. Install the ffmpeg4 precompiled package. In slack, it dumps the directory /usr/lib64/ffmpeg4.

3. Go to the converter directory. This is something like /net.downloadhelper.coapp-1.3.0/converter/build/linux/64. The ffmpeg binary works out of the box, but the codec libraries need replacing.

3.1  Try to download a video. When it failed, in the details link, it shows which libraries request the missing glibc version. Remove them from the converter directory. A link for each one might be needed instead (see the Note).

DONE. Now VDH works as intended.

Note: at leat in slack 14.2, ffmpeg4 codec libs (installed as a package with the correct glibc in step 2) are not visible by default and the ffmpeg binary from the converter directory will not complain about missing libs. A solution was to create a link to them from /usr/lib64/ffmpeg4 to /usr/lib64 ( /usr/lib64/libavcodec.so.58 -> /usr/lib64/ffmpeg4/libavcodec.so.58, ...)

There might be other ways to add them to the library path, but a few calls to 'ln -s' seemed fastest.

[Catalin Suru]

Also, before step 3.1, try to run the ffmpeg binary from the converter directory ('./ffmpeg', with no parameters), in a terminal.

If it complains about a library with the wrong glibc version, delete the faulty library from the converter directory (net.downloadhelper.coapp-1.3.0/converter/build/linux/64/) and create a link for it (as in the Note) , if needed). Repeat until it runs with no errors. Then go to step 3.1.

[HR]

Maybe, if you don't have the resources to "provide and maintain all library version", how about you compile your dist on the minimal viable version instead of the newest one?
One might call it "backwards compatibility" and would be a nice move considering those of us who can not "just upgrade" our OS versions as we please...

[Michael Kaiser]

+1  for 'compile your dist on minimal version' or at least the general version.

Running latest openSUSE Leap 15.2 (glibc 2.26)..

[Maximillium]

I wanted this to be in the same thread to which everyone is directed as an explanation of this problem:

[quote:]
jc vdh
Sep 12, 2020, 12:05 AM (1 day ago)
Hi, please read this https://groups.google.com/d/msg/video-downloadhelper-q-and-a/Z3iY4yhFvU8/mj3nAimxBQAJ jerome


Maximillium
Sep 12, 2020, 4:02 AM (1 day ago)
   
to jc
Hi Jerome:
I'm totally familiar with that link and thread.  It is a classic case of misunderstandings and is no help whatsoever.

glibc is the C program library that receives incoming program calls to the operating system - it IS the operating system.
Whatever, of many thousands of programs that exist, calls on glibc and glibc functions carry out the program functions -
at least this is as I understand it.  Not a guru here.

Hundreds of versions of linux use the C library (glibc) to run thousands of programs and they all seem to work
except DVH which USED TO WORK with multiple versions of linux using multiple versions of glibc.
It is this latest version that seemingly would require everyone to switch to ubuntu v-whatever.  Many of us
haven't the hardware to support newer OS versions, but older or lighter versions of linux do work - but don't
have glibc 2.27.  Many totally current versions of linux, extremely complete and polished OSs, don't use
glibc 2.27.  I'm still waiting for an answer to the question WHY can't the coapp call on glibc instead of glibc 2.27 ?

"I thought the question had been answered."  NO; the coapp specifically fails looking for glibc 2.27 which
it seems only users of ONE flavor of linux - ubuntu - seem to have, rendering it useless for anyone else.

DVH has been a wonderful and much-appreciated body of work, and THANK YOU, MIG, for allowing linux users
to use it for free -- but understand, by creating a coapp that absolutely requires one specific version of glibc,
the app has been taken away from us ... so thank you for the time we did have it.

[Alan Swithenbank]

Please pardon me if I'm replying in some wrong manner or in the wrong place, but, I never use google groups, etc. so I'm

not sure what's what...;^) I'm trying to deal with the glibc 2.27 issue as well. I'd be happy to recompile under Ubuntu 16.04,

but I hit some kind of dependency issue related to 'aom' that I can't get past. (Per the source/build script outputs, 'aom'

won't download is the problem. I made one suggested change for the source location in the scripts, but, didn't help).

I've  also tried downgrading to an earlier version of the companion app, but, when I try to do so the install automatically

updates to the latest version.  So, if anyone knows how to make 'aom' happy when compiling, or how to force the install

of earlier versions I'd be grateful to hear about it. Thanks!