| Message ID | 20220525162035.808477-1-dmitry.baryshkov@linaro.org |
|---|---|
| State | Accepted, archived |
| Commit | 44b397daa68b4d0a461225fe9ff7db8b5fcfdb7b |
| Headers | show |
| Series | go.bbclass: fix path to linker in native Go builds | expand |
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.baryshkov@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. Cheers, Richard
On 25/05/2022 20:15, richard.purdie@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.baryshkov@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?
On Wed, 2022-05-25 at 20:28 +0300, Dmitry Baryshkov wrote: > On 25/05/2022 20:15, richard.purdie@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.baryshkov@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? 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. Cheers, Richard
On 25/05/2022 20:40, richard.purdie@linuxfoundation.org wrote: > On Wed, 2022-05-25 at 20:28 +0300, Dmitry Baryshkov wrote: >> On 25/05/2022 20:15, richard.purdie@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.baryshkov@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.
diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass index 1a9a0bc1d426..df088c7590b7 100644 --- a/meta/classes/go.bbclass +++ b/meta/classes/go.bbclass @@ -45,7 +45,9 @@ GO_LINKMODE ?= "" GO_LINKMODE:class-nativesdk = "--linkmode=external" GO_LINKMODE:class-native = "--linkmode=external" GO_EXTRA_LDFLAGS ?= "" -GO_LDFLAGS ?= '-ldflags="${GO_RPATH} ${GO_LINKMODE} -I ${@get_linuxloader(d)} ${GO_EXTRA_LDFLAGS} -extldflags '${GO_EXTLDFLAGS}'"' +GO_LINUXLOADER ?= "-I ${@get_linuxloader(d)}" +GO_LINUXLOADER:class-native = "" +GO_LDFLAGS ?= '-ldflags="${GO_RPATH} ${GO_LINKMODE} ${GO_LINUXLOADER} ${GO_EXTRA_LDFLAGS} -extldflags '${GO_EXTLDFLAGS}'"' export GOBUILDFLAGS ?= "-v ${GO_LDFLAGS} -trimpath" export GOPATH_OMIT_IN_ACTIONID ?= "1" export GOPTESTBUILDFLAGS ?= "${GOBUILDFLAGS} -c"
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.baryshkov@linaro.org> --- meta/classes/go.bbclass | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)