On 25/05/2022 20:40, richard.pur...@linuxfoundation.org wrote:
On Wed, 2022-05-25 at 20:28 +0300, Dmitry Baryshkov wrote:
On 25/05/2022 20:15, richard.pur...@linuxfoundation.org wrote:
On Wed, 2022-05-25 at 19:20 +0300, Dmitry Baryshkov wrote:
Building native Go tools results in the tool pointing to the wrong
location of dynamic linker (see below). The linker is looked up in the
temporary dir, which can be removed if rm_work is inherited. This
results in being unable to execute the program with the 'No such file or
directory' error. Override linker specificiation for native recipes (and
let Go build environment to pick up a correct one on it's own).
Without this patch:
$ ldd
tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man
linux-vdso.so.1 (0x00007ffe945ec000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3a7490e000)
/home/lumag/Projects/RPB/build-rpb/tmp-rpb-glibc/work/x86_64-linux/go-md2man-native/1.0.10+gitAUTOINC+f79a8a8ca6-r0/recipe-sysroot-native/usr/lib/ld-linux-x86-64.so.2
=> /lib64/ld-linux-x86-64.so.2 (0x00007f3a74d13000)
$ tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man
--help
-bash:
tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man: No
such file or directory
With the patch
$ ldd
tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man
linux-vdso.so.1 (0x00007ffd19dbf000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2d44181000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2d44586000)
$ tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man
--help
Usage of
tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man:
-in string
Path to file to be processed (default: stdin)
-out string
Path to output processed file (default: stdout)
Signed-off-by: Dmitry Baryshkov <dmitry.barysh...@linaro.org>
---
meta/classes/go.bbclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
This is definitely not the correct fix. It should be pointing at the
uninative binaries, not the host system one.
If uninative is enabled, installed binaries will be patched automatically:
$ ldd
tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man
linux-vdso.so.1 (0x00007fff4a3ef000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f86998a9000)
/home/lumag/Projects/RPB/build-rpb/tmp-rpb-glibc/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
=> /lib64/ld-linux-x86-64.so.2 (0x00007f8699caf000)
However I can make this more explicit by using UNINATIVE_LOADER in
go.bbclass. Is that what you'd like to?
Were you using this without uninative when you sent the patch which is
why it was breaking?
Yes, RPB distro doesn't enable uninative.
I'd like to understand which scenarios you're testing.
Patching to the uninative loader would in some ways would be better but
would break the non-uninative use case so this does get tricky.
Yes. So I'd propose to merge this, to unbreak non-uninative cases. As I
said, I can try expanding it to support uninative natively.
--
With best wishes
Dmitry
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#166159):
https://lists.openembedded.org/g/openembedded-core/message/166159
Mute This Topic: https://lists.openembedded.org/mt/91336643/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
