On 2020/5/12 上午10:47, Jeremy A. Puhlman wrote:
On 5/11/2020 7:30 PM, Kang Kai wrote:
On 2020/5/10 下午9:40, Richard Purdie wrote:
On Wed, 2020-05-06 at 09:54 +0800, kai wrote:
From: Kai Kang <[email protected]>
It requires gcc 5.0 via OE-Core rev abc741a. On centos 7, the gcc
version is too low then it has to build with buildtools-extended-
tarball
which provides nativesdk-gcc.
But it fails to build nspr-native:
gcc abstract.o -Xlinker -L../../dist/lib -lplc4 -L../../dist/lib
-lnspr4 -lpthread -o abstract
/PATH/TO/x86_64-wrlinuxsdk-linux/bin/ld: /lib64/librt.so.1:
undefined reference to `__clock_getcpuclockid@GLIBC_PRIVATE'
/PATH/TO/x86_64-wrlinuxsdk-linux/bin/ld: /lib64/librt.so.1:
undefined reference to `__clock_nanosleep@GLIBC_PRIVATE'
/PATH/TO/x86_64-wrlinuxsdk-linux/bin/ld: /lib64/librt.so.1:
undefined reference to `__clock_settime@GLIBC_PRIVATE'
/PATH/TO/x86_64-wrlinuxsdk-linux/bin/ld: /lib64/librt.so.1:
undefined reference to `__clock_getres@GLIBC_PRIVATE'
collect2: error: ld returned 1 exit status
make: *** [Makefile:379: abstract] Error 1
Add nativesdk-glibc to buildtools-extended-tarball. And it increases
size of buildtools-extended-tarball about 3K from 48356989 to
48360329.
Signed-off-by: Kai Kang <[email protected]>
---
meta/recipes-core/meta/buildtools-extended-tarball.bb | 1 +
1 file changed, 1 insertion(+)
This doesn't make sense. Does it mean we need a new uninative version
instead?
Cheers,
Richard
```This works in dunfell, as of right now. This should have been
fixed with:
```https://patchwork.openembedded.org/patch/171584/
Hi Jeremy,
I can't receive mails from maillist for now. So reply here.
I suppose when I build oe-core master on ubunu 16.04, it already
contains the commit. I'll double check it.
Yeah it is in master right now. I am not entirely sure why you would
be seeing it. There was some discussion on
the list about twiddling with the location of /etc/ld.so.conf and
relocating it in the generation of sdks in general, but
I have not been able to poke at it today. If that went in, it might
have caused the issue. Basically what I saw when I was
looking in to it, was the sdk ld.so.conf was not getting loaded(in the
case of the patch because it was looking for etc/etc), but
if it got moved or something similar, it might cause a similar issue.
If you are still seeing the issue on master, strace the link of the
file with -f and look at what is going on with the load of ld.so.conf and
that might explain what is going on. Also make sure that ld.so.conf is
still there and has reasonable content.
Thank you very much for your detailed comment. I'll try it.
--
Kai Kang
Wind River Linux
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138148):
https://lists.openembedded.org/g/openembedded-core/message/138148
Mute This Topic: https://lists.openembedded.org/mt/74012860/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
