Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228730 > unrolled thread

clipgrab as alternative to youtube-dl

Back to article view | Back to linux.debian.user

Contents

  clipgrab as alternative to youtube-dl Fred <fred@blakemfg.com> - 2020-11-17 21:30 +0100
    Re: clipgrab as alternative to youtube-dl The Wanderer <wanderer@fastmail.fm> - 2020-11-17 21:30 +0100
      Re: clipgrab as alternative to youtube-dl Fred <fred@blakemfg.com> - 2020-11-17 22:30 +0100
        Re: clipgrab as alternative to youtube-dl The Wanderer <wanderer@fastmail.fm> - 2020-11-17 22:50 +0100
          Re: clipgrab as alternative to youtube-dl Fred <fred@blakemfg.com> - 2020-11-18 03:10 +0100
    Re: clipgrab as alternative to youtube-dl Greg Wooledge <wooledg@eeg.ccf.org> - 2020-11-17 21:30 +0100
      Re: clipgrab as alternative to youtube-dl Fred <fred@blakemfg.com> - 2020-11-17 22:20 +0100
      Re: clipgrab as alternative to youtube-dl Stefan Monnier <monnier@iro.umontreal.ca> - 2020-11-17 22:40 +0100
    Re: clipgrab as alternative to youtube-dl Anssi Saari <as@sci.fi> - 2020-11-18 15:00 +0100
      AppImage files (was: clipgrab as alternative to youtube-dl) Fred <fred@blakemfg.com> - 2020-11-18 15:10 +0100
        Re: AppImage files (was: clipgrab as alternative to youtube-dl) Marc Shapiro <marcnshap@gmail.com> - 2020-11-20 03:30 +0100
      How to run AppImage file (was: clipgrab as alternative to youtube-dl) Fred <fred@blakemfg.com> - 2020-11-25 20:20 +0100
        Re: How to run AppImage file (was: clipgrab as alternative to  youtube-dl) Reco <recoverym4n@enotuniq.net> - 2020-11-25 20:40 +0100
          Re: How to run AppImage file (was: clipgrab as alternative to  youtube-dl) Fred <fred@blakemfg.com> - 2020-11-25 22:10 +0100
          Re: How to run AppImage file (was: clipgrab as alternative to  youtube-dl) Fred <fred@blakemfg.com> - 2020-11-25 22:20 +0100
            Re: How to run AppImage file (was: clipgrab as alternative to  youtube-dl) Greg Wooledge <wooledg@eeg.ccf.org> - 2020-11-25 22:20 +0100
              Re: How to run AppImage file (was: clipgrab as alternative to  youtube-dl) Fred <fred@blakemfg.com> - 2020-11-26 01:40 +0100
                Re: How to run AppImage file (was: clipgrab as alternative to  youtube-dl) Andrei POPESCU <andreimpopescu@gmail.com> - 2020-11-26 10:30 +0100
            Re: How to run AppImage file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-11-26 17:30 +0100
              Re: How to run AppImage file Fred <fred@blakemfg.com> - 2020-11-26 17:40 +0100
                Re: How to run AppImage file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-11-26 20:30 +0100
                  Re: How to run AppImage file Fred <fred@blakemfg.com> - 2020-11-27 01:50 +0100

Page 1 of 2  [1] 2  Next page →

#228730 — clipgrab as alternative to youtube-dl

Hello,

I would like to try clipgrab as youtube-dl sometimes doesn't work.  I 
would not have made a donation on the clipgrab web site if I had first 
noticed that no support what so ever is available.

There is a binary for Linux available for download as a AppImage file. 
What is an AppImage file and what does one do with it.  The program was 
probably compiled for Ubuntu.  Is it likely to also run on Debian?

I also looked into compiling the source code which is often as easy as 
following some simple instructions.  The compile makes use of qmake 
which gives the error:

qmake: could not exec '/usr/lib/i386-linux-gnu/qt4/bin/qmake': No such 
file or directory

/usr/bin/qmake is a link that points to /usr/bin/qtchooser which is 
picking the wrong version of qt.  Qt5 is needed and is installed.  I 
have set an environment variable QT_SELECT=qt5 but the chooser is not 
fooled.  So, if the binary is not usable how do I select qt5?

Best regards,
Fred

[toc] | [next] | [standalone]

#228731

[Multipart message — attachments visible in raw view] — view raw

On 2020-11-17 at 15:21, Fred wrote:

> I also looked into compiling the source code which is often as easy as 
> following some simple instructions.  The compile makes use of qmake 
> which gives the error:
> 
> qmake: could not exec '/usr/lib/i386-linux-gnu/qt4/bin/qmake': No such 
> file or directory
> 
> /usr/bin/qmake is a link that points to /usr/bin/qtchooser which is 
> picking the wrong version of qt.  Qt5 is needed and is installed.  I 
> have set an environment variable QT_SELECT=qt5 but the chooser is not 
> fooled.  So, if the binary is not usable how do I select qt5?

I think you have the qtchooser syntax wrong.

'man qtchooser' says that the value passed to QT_SELECT is the same as
that which would be passed to 'qtchooser -qt='. Testing that, I get:


$ qtchooser -qt=4 -print-env
QT_SELECT="4"
QTTOOLDIR="/usr/lib/x86_64-linux-gnu/qt4/bin"
QTLIBDIR="/usr/lib/x86_64-linux-gnu"
wanderer@apologia:~$ qtchooser -qt=5 -print-env
QT_SELECT="5"
QTTOOLDIR="/usr/lib/qt5/bin"
QTLIBDIR="/usr/lib/x86_64-linux-gnu"
$ QT_SELECT=4 qtchooser -print-env
QT_SELECT="4"
QTTOOLDIR="/usr/lib/x86_64-linux-gnu/qt4/bin"
QTLIBDIR="/usr/lib/x86_64-linux-gnu"


IOW: the value you need to pass in is '5', not 'qt5'.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#228738

On 11/17/20 1:27 PM, The Wanderer wrote:
> On 2020-11-17 at 15:21, Fred wrote:
> 
>> I also looked into compiling the source code which is often as easy as
>> following some simple instructions.  The compile makes use of qmake
>> which gives the error:
>>
>> qmake: could not exec '/usr/lib/i386-linux-gnu/qt4/bin/qmake': No such
>> file or directory
>>
>> /usr/bin/qmake is a link that points to /usr/bin/qtchooser which is
>> picking the wrong version of qt.  Qt5 is needed and is installed.  I
>> have set an environment variable QT_SELECT=qt5 but the chooser is not
>> fooled.  So, if the binary is not usable how do I select qt5?
> 
> I think you have the qtchooser syntax wrong.
> 
> 'man qtchooser' says that the value passed to QT_SELECT is the same as
> that which would be passed to 'qtchooser -qt='. Testing that, I get:
> 
> 
> $ qtchooser -qt=4 -print-env
> QT_SELECT="4"
> QTTOOLDIR="/usr/lib/x86_64-linux-gnu/qt4/bin"
> QTLIBDIR="/usr/lib/x86_64-linux-gnu"
> wanderer@apologia:~$ qtchooser -qt=5 -print-env
> QT_SELECT="5"
> QTTOOLDIR="/usr/lib/qt5/bin"
> QTLIBDIR="/usr/lib/x86_64-linux-gnu"
> $ QT_SELECT=4 qtchooser -print-env
> QT_SELECT="4"
> QTTOOLDIR="/usr/lib/x86_64-linux-gnu/qt4/bin"
> QTLIBDIR="/usr/lib/x86_64-linux-gnu"
> 
> 
> IOW: the value you need to pass in is '5', not 'qt5'.
> 
Hi,
You are quite right.  I don't see from the man page how one is required 
to tell qtchooser to set the environment variable instead of doing it 
oneself.  In a hurry I didn't notice the option -qt=version.

Thanks for the help.
Best regards,
Fred

[toc] | [prev] | [next] | [standalone]

#228740

[Multipart message — attachments visible in raw view] — view raw

On 2020-11-17 at 16:27, Fred wrote:

> On 11/17/20 1:27 PM, The Wanderer wrote:
>
>> On 2020-11-17 at 15:21, Fred wrote:
>> 
>>> I also looked into compiling the source code which is often as easy as
>>> following some simple instructions.  The compile makes use of qmake
>>> which gives the error:
>>>
>>> qmake: could not exec '/usr/lib/i386-linux-gnu/qt4/bin/qmake': No such
>>> file or directory
>>>
>>> /usr/bin/qmake is a link that points to /usr/bin/qtchooser which is
>>> picking the wrong version of qt.  Qt5 is needed and is installed.  I
>>> have set an environment variable QT_SELECT=qt5 but the chooser is not
>>> fooled.  So, if the binary is not usable how do I select qt5?
>> 
>> I think you have the qtchooser syntax wrong.
>> 
>> 'man qtchooser' says that the value passed to QT_SELECT is the same as
>> that which would be passed to 'qtchooser -qt='. Testing that, I get:

>> $ QT_SELECT=4 qtchooser -print-env
>> QT_SELECT="4"
>> QTTOOLDIR="/usr/lib/x86_64-linux-gnu/qt4/bin"
>> QTLIBDIR="/usr/lib/x86_64-linux-gnu"
>> 
>> 
>> IOW: the value you need to pass in is '5', not 'qt5'.
> 
> Hi,
> You are quite right.  I don't see from the man page how one is required 
> to tell qtchooser to set the environment variable instead of doing it 
> oneself.  In a hurry I didn't notice the option -qt=version.

AFAICT, you don't need to tell qtchooser to do it. As the test still
quoted above shows, if you just set QT_SELECT and don't specify -qt=,
the other settings will be adjusted to match.

The practical necessities depend on exactly what is being invoked and
how, but it seems to me that if the build system is in fact calling
qtchooser, then setting QT_SELECT=5 should make it use Qt5.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#228746

On 11/17/20 2:41 PM, The Wanderer wrote:
> On 2020-11-17 at 16:27, Fred wrote:
> 
>> On 11/17/20 1:27 PM, The Wanderer wrote:
>>
>>> On 2020-11-17 at 15:21, Fred wrote:
>>>
>>>> I also looked into compiling the source code which is often as easy as
>>>> following some simple instructions.  The compile makes use of qmake
>>>> which gives the error:
>>>>
>>>> qmake: could not exec '/usr/lib/i386-linux-gnu/qt4/bin/qmake': No such
>>>> file or directory
>>>>
>>>> /usr/bin/qmake is a link that points to /usr/bin/qtchooser which is
>>>> picking the wrong version of qt.  Qt5 is needed and is installed.  I
>>>> have set an environment variable QT_SELECT=qt5 but the chooser is not
>>>> fooled.  So, if the binary is not usable how do I select qt5?
>>>
>>> I think you have the qtchooser syntax wrong.
>>>
>>> 'man qtchooser' says that the value passed to QT_SELECT is the same as
>>> that which would be passed to 'qtchooser -qt='. Testing that, I get:
> 
>>> $ QT_SELECT=4 qtchooser -print-env
>>> QT_SELECT="4"
>>> QTTOOLDIR="/usr/lib/x86_64-linux-gnu/qt4/bin"
>>> QTLIBDIR="/usr/lib/x86_64-linux-gnu"
>>>
>>>
>>> IOW: the value you need to pass in is '5', not 'qt5'.
>>
>> Hi,
>> You are quite right.  I don't see from the man page how one is required
>> to tell qtchooser to set the environment variable instead of doing it
>> oneself.  In a hurry I didn't notice the option -qt=version.
> 
> AFAICT, you don't need to tell qtchooser to do it. As the test still
> quoted above shows, if you just set QT_SELECT and don't specify -qt=,
> the other settings will be adjusted to match.
> 
> The practical necessities depend on exactly what is being invoked and
> how, but it seems to me that if the build system is in fact calling
> qtchooser, then setting QT_SELECT=5 should make it use Qt5.
> 
Hi,
qtchooser -qt=5 -print-env    does change to 5

qtchooser -qt=5       does not change the version.  Some command needs 
to follow.

qtchooser -print-env     shows "default"

To compile clipgrab:  qmake -qt=5 clipgrab.pro & & make
qmake is a link to qtchooser.

Best regards,
Fred

[toc] | [prev] | [next] | [standalone]

#228732

On Tue, Nov 17, 2020 at 01:21:55PM -0700, Fred wrote:
> I would like to try clipgrab as youtube-dl sometimes doesn't work.

Feel free to try whatever you like, but if you want youtube-dl to work,
don't use the Debian packages of it.  It changes too fast for a stable
release to handle.  Use upstream instead.

[toc] | [prev] | [next] | [standalone]

#228737

On 11/17/20 1:24 PM, Greg Wooledge wrote:
> On Tue, Nov 17, 2020 at 01:21:55PM -0700, Fred wrote:
>> I would like to try clipgrab as youtube-dl sometimes doesn't work.
> 
> Feel free to try whatever you like, but if you want youtube-dl to work,
> don't use the Debian packages of it.  It changes too fast for a stable
> release to handle.  Use upstream instead.
> 

Hi Greg,

I have never used the Debian package for youtube-dl.  For the last 
several months when I tried to update there was a message saying the 
current version could not be found.  This was probably because of a 
recent DMCA takedown.  However, I just tried an update and it was 
successful.  The version date is today.

Maybe I don't need clipgrab after all!

Best regards,
Fred

[toc] | [prev] | [next] | [standalone]

#228739

>> I would like to try clipgrab as youtube-dl sometimes doesn't work.
> Feel free to try whatever you like, but if you want youtube-dl to work,
> don't use the Debian packages of it.  It changes too fast for a stable
> release to handle.  Use upstream instead.

Debian's `youtube-dl` works fine for me, but indeed you don't want to
use the version from Debian `stable`.  I normally use Debian `testing` but
have found it necessary to update it from Debian `unstable` occasionally.
Luckily it doesn't come with any significant dependency, so installing
from `unstable` is not problematic, even on Debian `stable`.


        Stefan

[toc] | [prev] | [next] | [standalone]

#228752

Fred <fred@blakemfg.com> writes:

> There is a binary for Linux available for download as a AppImage
> file. What is an AppImage file and what does one do with it.  The
> program was probably compiled for Ubuntu.  Is it likely to also run on
> Debian?

AppImage files are a kind of package that contain an app and all its
dependencies so yes, it's very likely it'll run on Debian. All you have
to do is make the AppImage file executable and run it. I recently got
into these since I have a problem with the Firefox Debian bundles but
someone maintains a current Firefox build as AppImage.

[toc] | [prev] | [next] | [standalone]

#228753 — AppImage files (was: clipgrab as alternative to youtube-dl)

On 11/17/20 11:47 PM, Anssi Saari wrote:
> Fred <fred@blakemfg.com> writes:
> 
>> There is a binary for Linux available for download as a AppImage
>> file. What is an AppImage file and what does one do with it.  The
>> program was probably compiled for Ubuntu.  Is it likely to also run on
>> Debian?
> 
> AppImage files are a kind of package that contain an app and all its
> dependencies so yes, it's very likely it'll run on Debian. All you have
> to do is make the AppImage file executable and run it. I recently got
> into these since I have a problem with the Firefox Debian bundles but
> someone maintains a current Firefox build as AppImage.
> 

Hi,
Thanks for your answer.  I was able to get clipgrab to compile but the 
AppImage file is a later version and may be a better choice if it will 
run on Debian.

Best regards,
Fred

[toc] | [prev] | [next] | [standalone]

#228791 — Re: AppImage files (was: clipgrab as alternative to youtube-dl)

On 11/18/20 6:07 AM, Fred wrote:
> On 11/17/20 11:47 PM, Anssi Saari wrote:
>> Fred <fred@blakemfg.com> writes:
>>
>>> There is a binary for Linux available for download as a AppImage
>>> file. What is an AppImage file and what does one do with it. The
>>> program was probably compiled for Ubuntu.  Is it likely to also run on
>>> Debian?
>>
>> AppImage files are a kind of package that contain an app and all its
>> dependencies so yes, it's very likely it'll run on Debian. All you have
>> to do is make the AppImage file executable and run it. I recently got
>> into these since I have a problem with the Firefox Debian bundles but
>> someone maintains a current Firefox build as AppImage.
>>
>
> Hi,
> Thanks for your answer.  I was able to get clipgrab to compile but the 
> AppImage file is a later version and may be a better choice if it will 
> run on Debian.

I am using it on a Ddevuan system and it works just fine.

Marc

[toc] | [prev] | [next] | [standalone]

#229073 — How to run AppImage file (was: clipgrab as alternative to youtube-dl)

On 11/17/20 11:47 PM, Anssi Saari wrote:
> Fred <fred@blakemfg.com> writes:
> 
>> There is a binary for Linux available for download as a AppImage
>> file. What is an AppImage file and what does one do with it.  The
>> program was probably compiled for Ubuntu.  Is it likely to also run on
>> Debian?
> 
> AppImage files are a kind of package that contain an app and all its
> dependencies so yes, it's very likely it'll run on Debian. All you have
> to do is make the AppImage file executable and run it. I recently got
> into these since I have a problem with the Firefox Debian bundles but
> someone maintains a current Firefox build as AppImage.
> 
Hi,
I downloaded the AppImage clipgrab file and made it executable but it 
won't run.

fred@ragnok:~$ ls -l ClipGrab*
-rwxr-xr-x 1 fred fred 95575752 Nov 21 07:10 ClipGrab-3.9.2-x86_64.AppImage

fred@ragnok:~$ ./ClipGrab-3.9.2-x86_64.AppImage --help
bash: ./ClipGrab-3.9.2-x86_64.AppImage: cannot execute binary file: Exec 
format error

Any ideas how to fix?

Best regards,
Fred

[toc] | [prev] | [next] | [standalone]

#229074 — Re: How to run AppImage file (was: clipgrab as alternative to youtube-dl)

	Hi.

On Wed, Nov 25, 2020 at 12:13:03PM -0700, Fred wrote:
> fred@ragnok:~$ ./ClipGrab-3.9.2-x86_64.AppImage --help
> bash: ./ClipGrab-3.9.2-x86_64.AppImage: cannot execute binary file: Exec format error

uname -m

Reco

[toc] | [prev] | [next] | [standalone]

#229083 — Re: How to run AppImage file (was: clipgrab as alternative to youtube-dl)

On 11/25/20 12:30 PM, Reco wrote:
> 	Hi.
> 
> On Wed, Nov 25, 2020 at 12:13:03PM -0700, Fred wrote:
>> fred@ragnok:~$ ./ClipGrab-3.9.2-x86_64.AppImage --help
>> bash: ./ClipGrab-3.9.2-x86_64.AppImage: cannot execute binary file: Exec format error
> 
> uname -m
> 
> Reco
> 

fred@ragnok:~$ uname -m
i686

[toc] | [prev] | [next] | [standalone]

#229085 — Re: How to run AppImage file (was: clipgrab as alternative to youtube-dl)

On 11/25/20 12:30 PM, Reco wrote:
> 	Hi.
> 
> On Wed, Nov 25, 2020 at 12:13:03PM -0700, Fred wrote:
>> fred@ragnok:~$ ./ClipGrab-3.9.2-x86_64.AppImage --help
>> bash: ./ClipGrab-3.9.2-x86_64.AppImage: cannot execute binary file: Exec format error
> 
> uname -m
> 
> Reco
> 

fred@ragnok:~$ uname -m
i686
fred@ragnok:~$ file ClipGrab-3.9.2-x86_64.AppImage
ClipGrab-3.9.2-x86_64.AppImage: ELF 64-bit LSB executable, x86-64, 
version 1 (SYSV), dynamically linked, interpreter 
/lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, stripped

Actually neither /lib64/ nor ld-linux-x86-64.so.2 exist and apt-cache 
search doesn't show anything for ld-linux-x86-64.so.
Maybe the binary wont run on Debian (or Devuan).

Best regards,
Fred

[toc] | [prev] | [next] | [standalone]

#229087 — Re: How to run AppImage file (was: clipgrab as alternative to youtube-dl)

On Wed, Nov 25, 2020 at 02:12:03PM -0700, Fred wrote:
> fred@ragnok:~$ uname -m
> i686
> fred@ragnok:~$ file ClipGrab-3.9.2-x86_64.AppImage
> ClipGrab-3.9.2-x86_64.AppImage: ELF 64-bit LSB executable, x86-64, [...]

Well, um.  It's clearly not going to work.

You either need to use a 32-bit version of the application, or you need
to use a 64-bit Debian system.

[toc] | [prev] | [next] | [standalone]

#229093 — Re: How to run AppImage file (was: clipgrab as alternative to youtube-dl)

On 11/25/20 2:15 PM, Greg Wooledge wrote:
> On Wed, Nov 25, 2020 at 02:12:03PM -0700, Fred wrote:
>> fred@ragnok:~$ uname -m
>> i686
>> fred@ragnok:~$ file ClipGrab-3.9.2-x86_64.AppImage
>> ClipGrab-3.9.2-x86_64.AppImage: ELF 64-bit LSB executable, x86-64, [...]
> 
> Well, um.  It's clearly not going to work.
> 
> You either need to use a 32-bit version of the application, or you need
> to use a 64-bit Debian system.
> 

That's a fine how-dee-do.  I thought I was using 64 bit.  Perhaps I have 
some upgrading to do.

fred@ragnok:~$ lscpu
Architecture:        i686
CPU op-mode(s):      32-bit, 64-bit
(the rest cut)

Best regards,
Fred

[toc] | [prev] | [next] | [standalone]

#229106 — Re: How to run AppImage file (was: clipgrab as alternative to youtube-dl)

[Multipart message — attachments visible in raw view] — view raw

On Mi, 25 nov 20, 17:38:44, Fred wrote:
> On 11/25/20 2:15 PM, Greg Wooledge wrote:
> > On Wed, Nov 25, 2020 at 02:12:03PM -0700, Fred wrote:
> > > fred@ragnok:~$ uname -m
> > > i686
> > > fred@ragnok:~$ file ClipGrab-3.9.2-x86_64.AppImage
> > > ClipGrab-3.9.2-x86_64.AppImage: ELF 64-bit LSB executable, x86-64, [...]
> > 
> > Well, um.  It's clearly not going to work.
> > 
> > You either need to use a 32-bit version of the application, or you need
> > to use a 64-bit Debian system.
> > 
> 
> That's a fine how-dee-do.  I thought I was using 64 bit.  Perhaps I have
> some upgrading to do.

That would be a cross-grade.

https://wiki.debian.org/CrossGrading

Re-installing is still considered the safer option.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#229117 — Re: How to run AppImage file

Fred <fred@blakemfg.com> writes:

> On 11/25/20 12:30 PM, Reco wrote:
>> 	Hi.
>>
>> On Wed, Nov 25, 2020 at 12:13:03PM -0700, Fred wrote:
>>> fred@ragnok:~$ ./ClipGrab-3.9.2-x86_64.AppImage --help
>>> bash: ./ClipGrab-3.9.2-x86_64.AppImage: cannot execute binary file: Exec format error
>>
>> uname -m
>>
>> Reco
>>
>
> fred@ragnok:~$ uname -m
> i686
> fred@ragnok:~$ file ClipGrab-3.9.2-x86_64.AppImage
> ClipGrab-3.9.2-x86_64.AppImage: ELF 64-bit LSB executable, x86-64,
> version 1 (SYSV), dynamically linked, interpreter
> /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, stripped

Your uname says you are running a 32-bit system (686 is 32 bit).  The
output from the file command says it's a 64 bit executable.  You can run
a 32 bit executable on a 64 bit system, but you can't run a 64 bit
executable on a 32 bit system.

[toc] | [prev] | [next] | [standalone]

#229118 — Re: How to run AppImage file

On 11/26/20 9:04 AM, Joe Pfeiffer wrote:
> Fred <fred@blakemfg.com> writes:
> 
>> On 11/25/20 12:30 PM, Reco wrote:
>>> 	Hi.
>>>
>>> On Wed, Nov 25, 2020 at 12:13:03PM -0700, Fred wrote:
>>>> fred@ragnok:~$ ./ClipGrab-3.9.2-x86_64.AppImage --help
>>>> bash: ./ClipGrab-3.9.2-x86_64.AppImage: cannot execute binary file: Exec format error
>>>
>>> uname -m
>>>
>>> Reco
>>>
>>
>> fred@ragnok:~$ uname -m
>> i686
>> fred@ragnok:~$ file ClipGrab-3.9.2-x86_64.AppImage
>> ClipGrab-3.9.2-x86_64.AppImage: ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked, interpreter
>> /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, stripped
> 
> Your uname says you are running a 32-bit system (686 is 32 bit).  The
> output from the file command says it's a 64 bit executable.  You can run
> a 32 bit executable on a 64 bit system, but you can't run a 64 bit
> executable on a 32 bit system.
> 

Yes, I see that now.  I thought I was running 64 bit.

fred@ragnok:~$ lscpu
Architecture:        i686
CPU op-mode(s):      32-bit, 64-bit
This seems to say the cpu will run 64 bit software.

Best regards,
Fred

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web