On Sat, Feb 6, 2016 at 9:07 AM, Nathan Sowatskey wrote:
> /lib/ld-linux-x86-64.so.2 /usr/bin/testprog
> Illegal instruction
thats your problem. It seems to be compiled for a newer architecture
than whats emulated on qemu
--
___
yocto mailing list
yocto
Thanks :-)
/lib/ld-linux-x86-64.so.2 /usr/bin/testprog
Illegal instruction
/lib/ld-linux-x86-64.so.2 --list /usr/bin/testprog
linux-vdso.so.1 (0x7ffec29ee000)
libsnmp.so.30 => /usr/lib/libsnmp.so.30 (0x7fab23671000)
libQt5Network.so.5 => /usr/lib/libQt5Network.so
by ld.so I mean dynamic linker shared lib not literally ld.so file
it should be in /lib/ld*.so
On Fri, Feb 5, 2016 at 11:36 PM, Nathan Sowatskey wrote:
> Hi Khem
>
> Thanks for trying to help :-)
>
> I read what you have suggested below as trying to execute “ld.so” and passing
> my program as a
Hi Khem
Thanks for trying to help :-)
I read what you have suggested below as trying to execute “ld.so” and passing
my program as an argument.
I can’t find a file called “ld.so” on either my Yocto image, or even the Ubuntu
box that I am using to build it (which I use as a comparative reference
Hi Khem
Thanks for trying to help :-)
I read what you have suggested below as trying to execute “ld.so” and passing
my program as an argument.
I can’t find a file called “ld.so” on either my Yocto image, or even the Ubuntu
box that I am using to build it (which I use as a comparative reference
On Fri, Feb 5, 2016 at 12:46 PM, Burton, Ross wrote:
>
> On 5 February 2016 at 19:56, Khem Raj wrote:
>>
>> >> interpreter /lib64/ld-linux-x86-64.so.2
>> >
>> >
>> > Does the loader hunt around for this, as this is certainly not present
>> > in a
>> > default OE image?
>>
>> no it wont. infact th
On 5 February 2016 at 19:56, Khem Raj wrote:
> >> interpreter /lib64/ld-linux-x86-64.so.2
> >
> >
> > Does the loader hunt around for this, as this is certainly not present
> in a
> > default OE image?
>
> no it wont. infact thats the loader.
Yeah, what I meant is would the kernel hunt for that
On Fri, Feb 5, 2016 at 11:53 AM, Burton, Ross wrote:
>
> On 5 February 2016 at 18:12, Nathan Sowatskey wrote:
>>
>> interpreter /lib64/ld-linux-x86-64.so.2
>
>
> Does the loader hunt around for this, as this is certainly not present in a
> default OE image?
no it wont. infact thats the loader.
On 5 February 2016 at 18:12, Nathan Sowatskey wrote:
> interpreter /lib64/ld-linux-x86-64.so.2
Does the loader hunt around for this, as this is certainly not present in a
default OE image?
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https:
Thanks Khem. Please see below:
readelf -a /usr/bin/testprog
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (cu
On Fri, Feb 5, 2016 at 10:23 AM, Nathan Sowatskey wrote:
> Hi Kem
>
> The testprog was given to me as a .deb package by a third party to test. I
> did not compile it and I don’t know what they did either.
OK, paste the out of readelf -a on this binary
its mosly looking for libraries in wrong pat
_
>>> From: Nathan Sowatskey
>>> Sent: Friday, February 5, 2016 10:09 AM
>>> To: Fred Ollinger
>>> Cc: Burton, Ross; yocto@yoctoproject.org
>>> Subject: Re: [yocto] libgcc_s not present in Yocto image
>>>
>>> Thanks Fred.
>>>
To: Fred Ollinger
> Cc: Burton, Ross; yocto@yoctoproject.org
> Subject: Re: [yocto] libgcc_s not present in Yocto image
>
> file /usr/bin/testprog
> /usr/bin/testprog: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked, interpreter /lib
>> From: Nathan Sowatskey
>> Sent: Friday, February 5, 2016 10:09 AM
>> To: Fred Ollinger
>> Cc: Burton, Ross; yocto@yoctoproject.org
>> Subject: Re: [yocto] libgcc_s not present in Yocto image
>>
>> Thanks Fred.
>>
>> I am usi
; To: Fred Ollinger
> Cc: Burton, Ross; yocto@yoctoproject.org
> Subject: Re: [yocto] libgcc_s not present in Yocto image
>
> Thanks Fred.
>
> I am using qemux86_64 on Intel i7 chips with OSX. The target is likewise
> Intel.
>
> I am assuming that is quite generic, but …
&
llinger
> Cc: Burton, Ross; yocto@yoctoproject.org
> Subject: Re: [yocto] libgcc_s not present in Yocto image
>
> Thanks Fred.
>
> I am using qemux86_64 on Intel i7 chips with OSX. The target is likewise
> Intel.
>
> I am assuming that is quite generic, but …
>
> Regar
] libgcc_s not present in Yocto image
Thanks Fred.
I am using qemux86_64 on Intel i7 chips with OSX. The target is likewise Intel.
I am assuming that is quite generic, but …
Regards
Nathan
> On 5 Feb 2016, at 19:06, Fred Ollinger wrote:
>
> My guess is that the executable is not compile
t;
> Frederick
>
>
> From: Burton, Ross
> Sent: Friday, February 5, 2016 9:56 AM
> To: Nathan Sowatskey
> Cc: yocto@yoctoproject.org; Fred Ollinger
> Subject: Re: [yocto] libgcc_s not present in Yocto image
>
>
> On 5 Februa
octo@yoctoproject.org; Fred Ollinger
> Subject: Re: [yocto] libgcc_s not present in Yocto image
>
> Hi Ross
>
> Many thanks for following up. Fred also offered some helpful suggestions in a
> different thread.
>
> The program in question was supplied to me by a third party
My guess is that the executable is not compiled for his hardware.
Frederick
From: Burton, Ross
Sent: Friday, February 5, 2016 9:56 AM
To: Nathan Sowatskey
Cc: yocto@yoctoproject.org; Fred Ollinger
Subject: Re: [yocto] libgcc_s not present in Yocto image
On 5
What are results of:
$ file testprog
Frederick
From: Nathan Sowatskey
Sent: Friday, February 5, 2016 9:47 AM
To: Burton, Ross
Cc: yocto@yoctoproject.org; Fred Ollinger
Subject: Re: [yocto] libgcc_s not present in Yocto image
Hi Ross
Many thanks for
On 5 February 2016 at 17:47, Nathan Sowatskey wrote:
> find /usr/lib -name libgcc_s.so.1
> root@qemux86-64:~#
>
> I don’t have that lib.
>
As I said, libgcc_s.so.1 is in /lib, not /usr/lib.
> With ldd I get:
>
> ldd /usr/bin/testprog
> /usr/bin/ldd: line 117: /usr/bin/testprog: No such file or
Hi Ross
Many thanks for following up. Fred also offered some helpful suggestions in a
different thread.
The program in question was supplied to me by a third party for testing, so I
shall obscure the name here and call it testprog.
It was installed by:
dpkg -i ./testprog.deb
Where the .deb
On Fri, 2016-02-05 at 15:50 +, Burton, Ross wrote:
>
> On 5 February 2016 at 15:24, Nathan Sowatskey
> wrote:
> > I suspect that my test program, which was supplied to me as a .deb
> > package, was compiled on Ubuntu, and so links to libgcc_s.so.1. I
> > can’t see any obvious way to get libgc
On 5 February 2016 at 15:24, Nathan Sowatskey wrote:
> I suspect that my test program, which was supplied to me as a .deb
> package, was compiled on Ubuntu, and so links to libgcc_s.so.1. I can’t see
> any obvious way to get libgcc_s.so.1 on Yocto. I already have:
>
libgcc contains /lib/libgcc_s
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Thank you Burton and Tanu. The upshot here seems to be that there is a platform
dependency on whether one links to libgcc_s.a or libgcc_s.so.1:
"libgcc.a or libgcc_s.so.1 on some platforms”.
I suspect that my test program, which was supplied to me as a .deb package, was
compiled on Ubuntu, and
On 5 February 2016 at 11:40, Nathan Sowatskey wrote:
> Is there a way to get the libgcc_s library on a Yocto image? Is that even
> the right thing to do?
>
It's fairly likely that your binary is actually linking to libgcc_s.so.1
(which by default is in /lib, part of libgcc). libgcc_s.so is the
On Fri, 2016-02-05 at 12:40 +0100, Nathan Sowatskey wrote:
> Hi
>
> I am working with a test program which has a dependency on libgcc_s.
>
> On Ubuntu that is available, for example from a 14.04 Ubuntu desktop build:
>
> find /usr/lib -name "*gcc*”
> ...
> /usr/lib/gcc/x86_64-linux-gnu/4.8/libg
Hi
I am working with a test program which has a dependency on libgcc_s.
On Ubuntu that is available, for example from a 14.04 Ubuntu desktop build:
find /usr/lib -name "*gcc*”
...
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so
...
On the Yocto image I am building (see below for conf files), I d
30 matches
Mail list logo
