I don't see anything suspicious in the build (the same cmdline as in 2.22 version), but it uses
libhugetlbfs/1_2.22-r0-old/temp/log.do_compile:arm-oe-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Werror=return-type --sysroot=/jenkins/mjansa/build/ros/oe-melodic-gatesgarth/libhugetlbfs/1_2.22-r0/recipe-sysroot -I.. -O2 -Wall -g -o obj32/linkhuge_rw.o -c linkhuge_rw.c libhugetlbfs/1_2.22-r0-old/temp/log.do_compile:arm-oe-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Werror=return-type --sysroot=/jenkins/mjansa/build/ros/oe-melodic-gatesgarth/libhugetlbfs/1_2.22-r0/recipe-sysroot -B./obj32 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -ldl -L../obj32 -o obj32/linkhuge_rw -Wl,--no-as-needed -lpthread -ldl -lhugetlbfs_privutils -Wl,--hugetlbfs-align obj32/linkhuge_rw.o obj32/testutils.o libhugetlbfs/1_2.23-r0-new/temp/log.do_compile:arm-oe-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Werror=return-type --sysroot=/jenkins/mjansa/build/ros/oe-melodic-gatesgarth/libhugetlbfs/1_2.23-r0/recipe-sysroot -I.. -O2 -Wall -g -o obj32/linkhuge_rw.o -c linkhuge_rw.c libhugetlbfs/1_2.23-r0-new/temp/log.do_compile:arm-oe-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Werror=return-type --sysroot=/jenkins/mjansa/build/ros/oe-melodic-gatesgarth/libhugetlbfs/1_2.23-r0/recipe-sysroot -B./obj32 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -ldl -L../obj32 -o obj32/linkhuge_rw -Wl,--no-as-needed -lpthread -ldl -lhugetlbfs_privutils -Wl,--hugetlbfs-align obj32/linkhuge_rw.o obj32/testutils.o And the git log between 2.22 and 2.23 is also very short and looks reasonable. https://github.com/libhugetlbfs/libhugetlbfs/compare/2.22...2.23 When checking with readelf -l it also shows the error about PHDR segment: arm-oe-linux-gnueabi-readelf -l ./1_2.22-r0-old/sysroot-destdir/usr/lib/libhugetlbfs/tests/obj32/linkhuge_rw Elf file type is DYN (Shared object file) Entry point 0x201105 There are 10 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x00200034 0x00200034 0x00140 0x00140 R 0x4 INTERP 0x000174 0x00200174 0x00200174 0x0001d 0x0001d R 0x1 [Requesting program interpreter: /usr/lib/ld-linux-armhf.so.3] LOAD 0x000000 0x00200000 0x00200000 0x1222c 0x1222c R E 0x200000 LOAD 0x1ffdf0 0x005ffdf0 0x005ffdf0 0x102e0 0x202ec RW 0x200000 DYNAMIC 0x1ffdf8 0x005ffdf8 0x005ffdf8 0x00128 0x00128 RW 0x4 NOTE 0x000194 0x00200194 0x00200194 0x00044 0x00044 R 0x4 GNU_EH_FRAME 0x012224 0x00212224 0x00212224 0x00008 0x00008 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 EXIDX 0x001c5c 0x00201c5c 0x00201c5c 0x00008 0x00008 R 0x4 GNU_RELRO 0x1ffdf0 0x005ffdf0 0x005ffdf0 0x00210 0x00210 RW 0x4 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.ABI-tag .note.gnu.build-id .dynsym .dynstr .gnu.hash .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .ARM.extab .ARM.exidx .rodata .eh_frame .eh_frame_hdr 03 .fini_array .init_array .dynamic .got .data .bss 04 .dynamic 05 .note.ABI-tag .note.gnu.build-id 06 .eh_frame_hdr 07 08 .ARM.extab .ARM.exidx 09 .fini_array .init_array .dynamic .got arm-oe-linux-gnueabi-readelf -l ./1_2.23-r0-new/sysroot-destdir/usr/lib/libhugetlbfs/tests/obj32/linkhuge_rw Elf file type is DYN (Shared object file) Entry point 0x31cd1 There are 10 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000000 0x00000000 0x00000000 0x00000 0x00000 R 0 readelf: Error: the PHDR segment is not covered by a LOAD segment INTERP 0x030d40 0x00030d40 0x00030d40 0x0001d 0x0001d R 0x1 [Requesting program interpreter: /usr/lib/ld-linux-armhf.so.3] LOAD 0x030d40 0x00030d40 0x00030d40 0x120b8 0x120b8 R E 0x200000 LOAD 0x1ffdf0 0x003ffdf0 0x003ffdf0 0x102e0 0x202ec RW 0x200000 DYNAMIC 0x1ffdf8 0x003ffdf8 0x003ffdf8 0x00128 0x00128 RW 0x4 NOTE 0x030d60 0x00030d60 0x00030d60 0x00044 0x00044 R 0x4 GNU_EH_FRAME 0x042df0 0x00042df0 0x00042df0 0x00008 0x00008 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 EXIDX 0x032828 0x00032828 0x00032828 0x00008 0x00008 R 0x4 GNU_RELRO 0x1ffdf0 0x003ffdf0 0x003ffdf0 0x00210 0x00210 RW 0x4 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.ABI-tag .note.gnu.build-id .dynsym .dynstr .gnu.hash .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .ARM.extab .ARM.exidx .rodata .eh_frame .eh_frame_hdr 03 .fini_array .init_array .dynamic .got .data .bss 04 .dynamic 05 .note.ABI-tag .note.gnu.build-id 06 .eh_frame_hdr 07 08 .ARM.extab .ARM.exidx 09 .fini_array .init_array .dynamic .got And the diff between these 2: --- 1_2.22-r0-old/sysroot-destdir/usr/lib/libhugetlbfs/tests/obj32/linkhuge_rw.readelf 2020-09-16 04:32:11.885444764 -0700 +++ 1_2.23-r0-new/sysroot-destdir/usr/lib/libhugetlbfs/tests/obj32/linkhuge_rw.readelf 2020-09-16 04:31:56.621234211 -0700 @@ -1,21 +1,22 @@ Elf file type is DYN (Shared object file) -Entry point 0x201105 +Entry point 0x31cd1 There are 10 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align - PHDR 0x000034 0x00200034 0x00200034 0x00140 0x00140 R 0x4 - INTERP 0x000174 0x00200174 0x00200174 0x0001d 0x0001d R 0x1 + PHDR 0x000000 0x00000000 0x00000000 0x00000 0x00000 R 0 +readelf: Error: the PHDR segment is not covered by a LOAD segment + INTERP 0x030d40 0x00030d40 0x00030d40 0x0001d 0x0001d R 0x1 [Requesting program interpreter: /usr/lib/ld-linux-armhf.so.3] - LOAD 0x000000 0x00200000 0x00200000 0x1222c 0x1222c R E 0x200000 - LOAD 0x1ffdf0 0x005ffdf0 0x005ffdf0 0x102e0 0x202ec RW 0x200000 - DYNAMIC 0x1ffdf8 0x005ffdf8 0x005ffdf8 0x00128 0x00128 RW 0x4 - NOTE 0x000194 0x00200194 0x00200194 0x00044 0x00044 R 0x4 - GNU_EH_FRAME 0x012224 0x00212224 0x00212224 0x00008 0x00008 R 0x4 + LOAD 0x030d40 0x00030d40 0x00030d40 0x120b8 0x120b8 R E 0x200000 + LOAD 0x1ffdf0 0x003ffdf0 0x003ffdf0 0x102e0 0x202ec RW 0x200000 + DYNAMIC 0x1ffdf8 0x003ffdf8 0x003ffdf8 0x00128 0x00128 RW 0x4 + NOTE 0x030d60 0x00030d60 0x00030d60 0x00044 0x00044 R 0x4 + GNU_EH_FRAME 0x042df0 0x00042df0 0x00042df0 0x00008 0x00008 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 - EXIDX 0x001c5c 0x00201c5c 0x00201c5c 0x00008 0x00008 R 0x4 - GNU_RELRO 0x1ffdf0 0x005ffdf0 0x005ffdf0 0x00210 0x00210 RW 0x4 + EXIDX 0x032828 0x00032828 0x00032828 0x00008 0x00008 R 0x4 + GNU_RELRO 0x1ffdf0 0x003ffdf0 0x003ffdf0 0x00210 0x00210 RW 0x4 Section to Segment mapping: Segment Sections... Reverting https://github.com/libhugetlbfs/libhugetlbfs/commit/852dcc963ce44861ed7c4e225aa92ff2b5b43579 fixes this build issue, but I still don't see why it fails this way. I'll send revert to unblock my builds, but hopefully zangrc would be able to debug it a bit more or discuss this with upstream (I don't use libhugetlbfs at all, it just shown up in world builds..) Cheers, On Tue, Sep 15, 2020 at 8:31 PM Khem Raj <[email protected]> wrote: > On Tue, Sep 15, 2020 at 9:44 AM Martin Jansa <[email protected]> > wrote: > > > > This is somehow causing strip to fail when building for arm (I'm seeing > it e.g. in raspberrypi4 builds): > > > > ERROR: libhugetlbfs-1_2.23-r0 do_populate_sysroot: Fatal errors occurred > in subprocesses: > > Command '['arm-oe-linux-gnueabi-strip', '--remove-section=.comment', > '--remove-section=.note', > 'libhugetlbfs/1_2.23-r0/sysroot-destdir/usr/lib/libhugetlbfs/tests/obj32/linkhuge_rw']' > returned non-zero exit status 1. > > Subprocess output:arm-oe-linux-gnueabi-strip: > libhugetlbfs/1_2.23-r0/sysroot-destdir/usr/lib/libhugetlbfs/tests/obj32/stmuFa58: > error: PHDR segment not covered by LOAD segment > > arm-oe-linux-gnueabi-strip: > libhugetlbfs/1_2.23-r0/sysroot-destdir/usr/lib/libhugetlbfs/tests/obj32/stmuFa58[.interp]: > file format not recognized > > > > I wonder if this file has specific linker script used to do linking ? > > > It might be reproducible only with ld-is-gold in DISTRO_FEATURES. > > > > Can you please look into that? > > > > > > On Fri, Sep 11, 2020 at 3:25 AM zangrc <[email protected]> > wrote: > >> > >> 0001-tests-add-explicit-permissions-to-open-call.patch > >> Removed since this is included in 2.23 > >> > >> Signed-off-by: Zang Ruochen <[email protected]> > >> --- > >> ...dd-explicit-permissions-to-open-call.patch | 41 ------------------- > >> .../libhugetlbfs/libhugetlbfs_git.bb | 5 +-- > >> 2 files changed, 2 insertions(+), 44 deletions(-) > >> delete mode 100644 > meta-oe/recipes-benchmark/libhugetlbfs/files/0001-tests-add-explicit-permissions-to-open-call.patch > >> > >> diff --git > a/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-tests-add-explicit-permissions-to-open-call.patch > b/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-tests-add-explicit-permissions-to-open-call.patch > >> deleted file mode 100644 > >> index 9d52b908e..000000000 > >> --- > a/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-tests-add-explicit-permissions-to-open-call.patch > >> +++ /dev/null > >> @@ -1,41 +0,0 @@ > >> -From d07d2f9601b49bb72cd4b36838f0c238bd1b0fc1 Mon Sep 17 00:00:00 2001 > >> -From: Khem Raj <[email protected]> > >> -Date: Wed, 15 Jan 2020 18:45:09 -0800 > >> -Subject: [PATCH] tests: add explicit permissions to open() call > >> - > >> -Fixes > >> -gethugepagesizes.c:227:35: error: open with O_CREAT in second argument > needs 3 arguments > >> -| fd = open(fname, O_WRONLY|O_CREAT); > >> -| ^ > >> - > >> -Upstream-Status: Submitted [ > https://groups.google.com/forum/#!topic/libhugetlbfs/anNtDXbQKro] > >> -Signed-off-by: Khem Raj <[email protected]> > >> ---- > >> - tests/gethugepagesizes.c | 4 ++-- > >> - 1 file changed, 2 insertions(+), 2 deletions(-) > >> - > >> -diff --git a/tests/gethugepagesizes.c b/tests/gethugepagesizes.c > >> -index 9551b38..5777265 100644 > >> ---- a/tests/gethugepagesizes.c > >> -+++ b/tests/gethugepagesizes.c > >> -@@ -223,7 +223,7 @@ void setup_fake_data(long sizes[], int n_elem) > >> - FAIL("mkdtemp: %s", strerror(errno)); > >> - > >> - sprintf(fname, "%s/meminfo-none", fake_meminfo); > >> -- fd = open(fname, O_WRONLY|O_CREAT); > >> -+ fd = open(fname, O_WRONLY|O_CREAT, 0600); > >> - if (fd < 0) > >> - FAIL("open: %s", strerror(errno)); > >> - if (write(fd, meminfo_base, > >> -@@ -233,7 +233,7 @@ void setup_fake_data(long sizes[], int n_elem) > >> - FAIL("close: %s", strerror(errno)); > >> - > >> - sprintf(fname, "%s/meminfo-hugepages", fake_meminfo); > >> -- fd = open(fname, O_WRONLY|O_CREAT); > >> -+ fd = open(fname, O_WRONLY|O_CREAT, 0600); > >> - if (fd < 0) > >> - FAIL("open: %s", strerror(errno)); > >> - if (write(fd, meminfo_base, > >> --- > >> -2.25.0 > >> - > >> diff --git a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb > b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb > >> index 4768d7b63..b349096ec 100644 > >> --- a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb > >> +++ b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb > >> @@ -7,10 +7,10 @@ DEPENDS = "sysfsutils" > >> RDEPENDS_${PN} += "bash python3-core" > >> RDEPENDS_${PN}-tests += "bash python3-core" > >> > >> -PV = "2.22" > >> +PV = "2.23" > >> PE = "1" > >> > >> -SRCREV = "e6499ff92b4a7dcffbd131d1f5d24933e48c3f20" > >> +SRCREV = "6b126a4d7da9490fa40fe7e1b962edcb939feddc" > >> SRC_URI = " \ > >> git://github.com/libhugetlbfs/libhugetlbfs.git;protocol=https \ > >> file://skip-checking-LIB32-and-LIB64-if-they-point-to-the-s.patch \ > >> @@ -24,7 +24,6 @@ SRC_URI = " \ > >> file://0004-shm.c-Mark-glibc-specific-changes-so.patch \ > >> file://0005-Include-dirent.h-for-ino_t.patch \ > >> file://0006-include-limits.h-for-PATH_MAX.patch \ > >> - file://0001-tests-add-explicit-permissions-to-open-call.patch \ > >> file://0001-huge_page_setup_helper-use-python3-interpreter.patch \ > >> " > >> > >> -- > >> 2.25.1 > >> > >> > >> > >> > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#87119): https://lists.openembedded.org/g/openembedded-devel/message/87119 Mute This Topic: https://lists.openembedded.org/mt/76770888/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
