/lib/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

[Patrick Dupre]

Hello,

I get:
/lib/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

when it try to run qtiplot.
I installed:
liborigin2-20110829-2-x86_64.pkg.tar.xz  usr
qtiplot-0.9.8.9-2-x86_64.pkg.tar.xz

what is strange is that
rpm -qf /lib/ld-linux.so.2
glibc-2.16-28.fc18.i686

why i686, while it should use glibc-2.16-28.fc18.x86_64
ie. /lib64/ld-2.16.so

It seems that the version of qtiplot hasd not been compiled properly!

Could you help?

thank.

[Michael Schwendt]

On Fri, 08 Mar 2013 16:59:33 +0100, Patrick Dupre wrote:
> Hello,
>
> I get:
> /lib/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
>
> when it try to run qtiplot.
> I installed:
> liborigin2-20110829-2-x86_64.pkg.tar.xz  usr
> qtiplot-0.9.8.9-2-x86_64.pkg.tar.xz
>
> what is strange is that
> rpm -qf /lib/ld-linux.so.2
> glibc-2.16-28.fc18.i686

Why did you run that query? What does it prove?
> why i686, while it should use glibc-2.16-28.fc18.x86_64
> ie. /lib64/ld-2.16.so

Because the executable contains a hardcoded path for the run-time linker.
If it was built on a platform where that one is stored in /lib, that's
what you get.
> It seems that the version of qtiplot hasd not been compiled properly!
>
> Could you help?

Contact the person who provides those precompiled packages?

And as I'm curious, have you tried creating a softlink to
/lib64/ld-linux-x86-64.so.2 as a work-around?

[Patrick Dupre]

> Hello,
>
> I get:
> /lib/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
>
> when it try to run qtiplot.
> I installed:
> liborigin2-20110829-2-x86_64.pkg.tar.xz  usr
> qtiplot-0.9.8.9-2-x86_64.pkg.tar.xz
>
> what is strange is that
> rpm -qf /lib/ld-linux.so.2
> glibc-2.16-28.fc18.i686
>
> why i686, while it should use glibc-2.16-28.fc18.x86_64
> ie. /lib64/ld-2.16.so
>
> It seems that the version of qtiplot hasd not been compiled properly!
>
> Could you help?

I fixed this issue by:

ln -s /lib64/ld-2.16.so /lib/ld-linux-x86-64.so.2

but now, I get:
./qtiplot: error while loading shared libraries: libmuparser.so.0:  
cannot open shared object file: No such file or directory
I have:
/usr/lib64/libmuparser.so.2
/usr/lib64/libmuparser.so.2.2.2

How can I fix that?
Should I just make a link or install another package providing  
libmuparser.so.0?

Thank.

[Reindl Harald]

Am 08.03.2013 18:31, schrieb Patrick Dupre:
> but now, I get:
> ./qtiplot: error while loading shared libraries: libmuparser.so.0: cannot open shared object file: No such file or
> directory
> I have:
> /usr/lib64/libmuparser.so.2
> /usr/lib64/libmuparser.so.2.2.2
>
> How can I fix that?
> Should I just make a link or install another package providing libmuparser.so.0?

what says "which ld"

i had this missing after a bad update some week sago
and "yum reinstall binutils" fixed the issue which
leaded to a failing update of the grub.conf due kernel update

[Ralf Corsepius]

On 03/08/2013 06:57 PM, Reindl Harald wrote:
> Am 08.03.2013 18:31, schrieb Patrick Dupre:
> > but now, I get:
> > ./qtiplot: error while loading shared libraries: libmuparser.so.0: cannot open shared object file: No such file or
> > directory
> > I have:
> > /usr/lib64/libmuparser.so.2
> > /usr/lib64/libmuparser.so.2.2.2
> >
> > How can I fix that?
> > Should I just make a link or install another package providing libmuparser.so.0?
>
> what says "which ld"
>
> i had this missing after a bad update some week sago
> and "yum reinstall binutils" fixed the issue which
> leaded to a failing update of the grub.conf due kernel update

From what I can gather, Patrick is trying to install a foreign, 
incompatible distro's (Likely Archlinux) binary tarballs on Fedora and 
has begun to screw up his installation.

Sorry, Patrick, I can only recommend you to stop doing this.

Ralf

[Reindl Harald]

Am 08.03.2013 19:09, schrieb Ralf Corsepius:
> On 03/08/2013 06:57 PM, Reindl Harald wrote:
> > Am 08.03.2013 18:31, schrieb Patrick Dupre:
> > > but now, I get:
> > > ./qtiplot: error while loading shared libraries: libmuparser.so.0: cannot open shared object file: No such file or
> > > directory
> > > I have:
> > > /usr/lib64/libmuparser.so.2
> > > /usr/lib64/libmuparser.so.2.2.2
> > >
> > > How can I fix that?
> > > Should I just make a link or install another package providing libmuparser.so.0?
> >
> > what says "which ld"
> >
> > i had this missing after a bad update some week sago
> > and "yum reinstall binutils" fixed the issue which
> > leaded to a failing update of the grub.conf due kernel update
>
> From what I can gather, Patrick is trying to install a foreign, 
> incompatible distro's (Likely Archlinux) binary
> tarballs on Fedora and has begun to screw up his installation

oh - i missed this ones
why does someone think was RPM, YUM and repos invited?
> > when it try to run qtiplot.
> > I installed:
> > liborigin2-20110829-2-x86_64.pkg.tar.xz  usr
> > qtiplot-0.9.8.9-2-x86_64.pkg.tar.xz

ok, so i am not the one thinking that he is acting on
his system without any plan and produce troubles after
troubles until it is screwed enough that only a blank
install helps

[Patrick Dupre]

Quoting ven, 08 mar 2013 Ralf Corsepius :
> On 03/08/2013 06:57 PM, Reindl Harald wrote:
> > Am 08.03.2013 18:31, schrieb Patrick Dupre:
> > > but now, I get:
> > > ./qtiplot: error while loading shared libraries: libmuparser.so.0:  
> > > cannot open shared object file: No such file or
> > > directory
> > > I have:
> > > /usr/lib64/libmuparser.so.2
> > > /usr/lib64/libmuparser.so.2.2.2
> > >
> > > How can I fix that?
> > > Should I just make a link or install another package providing  
> > > libmuparser.so.0?
> >
> > what says "which ld"
> >
> > i had this missing after a bad update some week sago
> > and "yum reinstall binutils" fixed the issue which
> > leaded to a failing update of the grub.conf due kernel update
>
> From what I can gather, Patrick is trying to install a foreign,  
> incompatible distro's (Likely Archlinux) binary tarballs on Fedora  
> and has begun to screw up his installation.
>
> Sorry, Patrick, I can only recommend you to stop doing this.

Thank Ralf for the advise.

However, it seems to be working fine with the link.
which ld
/bin/ld

Anyway, I was able to find a package qtiplot compiled for fedora 18.
I would have even try to rebuild from the sources if I could fine
compilable sources!
If there was a straight way of doing the job, I would have do it!

Thank.

[Reindl Harald]

Am 08.03.2013 19:32, schrieb Patrick Dupre:
> Anyway, I was able to find a package qtiplot compiled for fedora 18.
> I would have even try to rebuild from the sources if I could fine
> compilable sources!
> If there was a straight way of doing the job, I would have do it!

man rpmbuild
http://fedoraproject.org/wiki/How_to_create_an_RPM_package

this is really no rocket science

i use a lot of things whiche are not available
in a RPM form BUT my rule is
* NEVER install any binary outside of RPM
* NEVER build any software as root
* NEVER call "make install" to screw my systems
* ALWAYS use rpmbuild/SPEC-Files with a dedicated user
* ALWAYS generate src.rpm packages and archive them for later

there is no single reason to act any other way
if something can not be packaged clean ina RPM
it can not be installed in a clean way at all

and this way i am able to work with a fedora setup over
many years with dist-upgrades and you can be pretty sure
any of my machin e sinstalled with F) years ago are as
clean as a fresh install because it saves me a lot of
troubles make dist-upgrades and do the cleanups and
perfection of the config/envirnonment while the machines
are in production instead start twice a year from scratch

[Patrick Dupre]

Hello Reindl,

I tried your suggetsion on 3 packages:
labplot-2.0.0.alpha3.tar.bz2
dwg2dxf-2.1.tar.gz
scidavis-0.2.4.tar.bz2

For all of them the compilation fails when doing rpmbuild --ba
exactly the same way as I previously did, ie "manually"!!!

This is only an option when the packages have been properly built and
in that case you do not have to worry, the packages are available  
through you!!!

Regards.
> Am 08.03.2013 19:32, schrieb Patrick Dupre:
> > Anyway, I was able to find a package qtiplot compiled for fedora 18.
> > I would have even try to rebuild from the sources if I could fine
> > compilable sources!
> > If there was a straight way of doing the job, I would have do it!
>
> man rpmbuild
> http://fedoraproject.org/wiki/How_to_create_an_RPM_package
>
> this is really no rocket science
>
> i use a lot of things whiche are not available
> in a RPM form BUT my rule is
> NEVER install any binary outside of RPM
> NEVER build any software as root
> NEVER call "make install" to screw my systems
> ALWAYS use rpmbuild/SPEC-Files with a dedicated user
> ALWAYS generate src.rpm packages and archive them for later
>
> there is no single reason to act any other way
> if something can not be packaged clean ina RPM
> it can not be installed in a clean way at all
>
> and this way i am able to work with a fedora setup over
> many years with dist-upgrades and you can be pretty sure
> any of my machin e sinstalled with F) years ago are as
> clean as a fresh install because it saves me a lot of
> troubles make dist-upgrades and do the cleanups and
> perfection of the config/envirnonment while the machines
> are in production instead start twice a year from scratch

[Reindl Harald]

Am 08.03.2013 23:09, schrieb Patrick Dupre:
> Hello Reindl,
>
> I tried your suggetsion on 3 packages:
> labplot-2.0.0.alpha3.tar.bz2
> dwg2dxf-2.1.tar.gz
> scidavis-0.2.4.tar.bz2
>
> For all of them the compilation fails when doing rpmbuild --ba
> exactly the same way as I previously did, ie "manually"!!!
>
> This is only an option when the packages have been properly built and
> in that case you do not have to worry, the packages are available through you!!!

you should learn to post informations
most of your postings are meaningless words

* post the SPEC-file
* post the outpus

you can not expect that anybody will help you
if you screw up your system and some magican
will help you out with his glass ball

[Michael Schwendt]

On Fri, 08 Mar 2013 19:32:15 +0100, Patrick Dupre wrote:
> > Sorry, Patrick, I can only recommend you to stop doing this.
>
> Thank Ralf for the advise.
>
> However, it seems to be working fine with the link.
> which ld
> /bin/ld

ld is a build-time tool and nothing to do with your issues at all. ;-)

[Michael Schwendt]

On Fri, 08 Mar 2013 18:57:40 +0100, Reindl Harald wrote:
> Am 08.03.2013 18:31, schrieb Patrick Dupre:
> > but now, I get:
> > ./qtiplot: error while loading shared libraries: libmuparser.so.0: cannot open shared object file: No such file or
> > directory
> > I have:
> > /usr/lib64/libmuparser.so.2
> > /usr/lib64/libmuparser.so.2.2.2
> >
> > How can I fix that?
> > Should I just make a link or install another package providing libmuparser.so.0?
>
> what says "which ld"
>
> i had this missing after a bad update some week sago
> and "yum reinstall binutils" fixed the issue which
> leaded to a failing update of the grub.conf due kernel update

libmuparser.so.0 != libmuparser.so.2

There may be a very good reason why the version has been increased.
One would need to examine both libs in detail.
Even if in corner-case scenarios with some libs one can use a symlink as a
temporary work-around, please don't get used to that. You can shoot
yourself into the feet easily when doing that with other libs.
Better (re)build from source.

$ repoquery --whatprovides 'libmuparser.so.0()(64bit)'
$

[Gordon Messmer]

On 03/08/2013 07:59 AM, Patrick Dupre wrote:
> It seems that the version of qtiplot hasd not been compiled properly!

You might be able to try these packages:
http://nucleo.fedorapeople.org/rpms/qtiplot/