GUVCView for the 32-bit Slackos...

Audio editors, music players, video players, burning software, etc.
Post Reply
Message
Author
User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

GUVCView for the 32-bit Slackos...

#1 Post by Mike Walsh »

Morning, all.

I've always used guvcview in the 'buntu-based Pups; it's a neat little webcam package for short-term capturing of odd items'n'stuff if you don't necessarily want to fire up bigger apps to do the job. There's been .pet packages available for this for a long time, but they've never worked in the 32-bit Slackos; until now.

Slacko's Luvcview works fine for simply showing your cam's output, but you can't record clips with it. As part of a 'rationalization' plan across my kennels, I'm slowly getting my favourite apps to work in all my Puppies, whether 'Buntu or Slackware-based.

This entailed a bit of a 'lib chase' (as was expected!), but it didn't take as much doing as I'd feared. I 'borrowed' many of the missing components from the guvcview package put together for Wary, which I run very successfully in Racy 5.5....and the rest came from Precise 571. Despite it being an older version, it seems many of the required dependencies are still the same.

You can find the Slacko GuvcView package at my MediaFire a/c, here:-

http://www.mediafire.com/file/otruc0zsg ... 0-i686.pet

Apologies if anybody's already done this; I couldn't find any reference to it in the Forum if they have! Feedback would be useful, as always, please, if you decide to try this out.

Enjoy.


Mike. :wink:

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#2 Post by greengeek »

Hi Mike,

in answer to your question on the other thread - I have always used a version 1.7.3 guvcview pet successfully on Slacko 5.6. Dont remember where I originally got it from though. However I did not experience the specific problem that Mochi had with segmentation faults when he used the same version... I suspect that different hardware can generate different errors.

I just tried the 1.5.3 pet you have offered here and got the following:

Code: Select all

# guvcview
guvcview: error while loading shared libraries: libgtk-3.so.0: cannot open shared object file: No such file or directory
cheers!

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#3 Post by Mike Walsh »

Hi, GG. Yes, I rather suspect there's more than a grain of truth in that statement.....although whenever I've made up packages on the big Compaq (which is 64-bit AMD-based), and then transferred them to the Dell (32-bit Intel-based), they've always run without a hitch.

But hardware certainly must play some part in compatibility, I'll grant you that. And, er.....I don't remember where I got the 1.5.3 package, now, either..! All I know is it runs in several of my Pups, on this hardware, flawlessly.....so it stood a good chance of running, on this same hardware (by isolating the necessary components for a stand-alone package), in the Slackos too.

And it does (which is the main thing).


Mike. :wink:

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#4 Post by greengeek »

Hi Mike, hope you don't mind me posting the 1.7.3 pet that I mentioned above. I have now located where I originally got it from in the OscarTalks repo here:

http://smokey01.com/OscarTalks/

Download link:
http://smokey01.com/OscarTalks/guvcview ... cko5.6.pet

cheers!

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#5 Post by Mike Walsh »

Hiya, GG.

Nah, no problemo, mate. I'm curious, though; mine's around 6.5 MB in size, and I see yours is about 2.5 MB. Higher compression.....or just 'stripped'?

In fact, now I come to think of it, I know why mine's so much bigger. Mine was a crib from (and a rebuild of) the Wary package. Like me, I guess you know how basic Wary is, and how much extra stuff it needs to just run 'normal' apps/progs, yes?

I'm guessing the binary was compiled in Wary.....so, naturally, it needed a hell of a lot of 'extra' stuff to run in 560/570. I'd lay odds of 10-1 that's the reason why. Before Billtoo & Mikeslr put me onto the package compiled for Racy, I'd already modified the Wary package to run on there. It needed quite a bit of extra stuff, I remember (I spent quite a while on pkgs.org, digging around for what I needed)....and when I extracted the Racy package to take a squizz at it, I was surprised at the difference in size. Racy already had most of the necessary libs, etc, to run Guvcview.....whereas the Wary package wanted a lot of additional stuff, since it had been compiled under more basic 'surroundings'... I ended up with different versions of multiple libs & other things, I know that much.

We live & learn, don't we?

----------------------------------------------------------------------

EDIT:-
greengeek wrote:I just tried the 1.5.3 pet you have offered here and got the following:

Code: Select all

# guvcview 
guvcview: error while loading shared libraries: libgtk-3.so.0: cannot open shared object file: No such file or directory
I can tell you why that happened. Your libgtk-3.0.so.0 is under /usr/share/guvcview/libs. Mine is under /usr/lib/i386-linux-gnu.

Different layout, y'see.....


Mike. :wink:

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#6 Post by greengeek »

Mike Walsh wrote:I can tell you why that happened. Your libgtk-3.0.so.0 is under /usr/share/guvcview/libs. Mine is under /usr/lib/i386-linux-gnu.

Different layout, y'see.....
Ahh, interesting. I have seen quite a bit of software that installs to that 386linuxgnu thingy but never knew what to make of it. I usually drag libs out of there and chuck 'em in with the rest of the clusterfrack of libs floating around in /lib or usr/lib.

That's probably breaking all the rules of course but oh well.
8)

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#7 Post by Mike Walsh »

Hey, GG.

We do indeed live & learn. I've just built a Remmina package for the 5-series Slackos tonight - a modification of the 'Trusty' package - which had most of its libs in /usr/lib/i386-linux-gnu. Trying to use that got me nowhere fast; Slacko, of course, doesn't use it (uses something like slacko-linux-i486 instead, but it still wouldn't work sticking 'em in there, either).

So I stuck everything in /usr/lib, as 'normal'. And then it behaved itself..!

I'm beginning to realise this 'i386-linux-gnu' thing is peculiar to 'buntu-based Puppies. We have Shuttleworth & Canonical to thank for that particular abortion.... Most of the time, even when doing builds for 'buntu Pups, I just stick everything in /lib or /usr/lib (and they still find them).....and run.

And, like you, I never have been able to figure out what the reason is for its existence. 'Cos if you trace it back, it appears to be kinda 'back-linked' into itself...

????? WTF..?? :?


Mike. :wink:

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#8 Post by greengeek »

Mike Walsh wrote:????? WTF..?? :?
Indeed! I do wonder if sticking the libs in that special folder has some sort of "PRELOAD" function (like what OscarTalks does with some of his packages - separating special versions of libs that he does not want to "infect" the whole system with?). ie: a "clash avoidance" mechanism.

It would be nice to have a puppy built with critical components like kernel, glibc, GTK, and libs etc all modular so that new components could be grafted in at will.

Obviously I'm a crazy dreamer
:?

Post Reply