Skip to contentSkip to conversation

dtc: bump version to 1.4.7

PATCH New Geoff Levand 2 participants 9 messages Jul 24, 2018 – Jul 30, 2018 1 message not in the archive

lore
Share & tools
lore
#0 lore raw

PATCH 1/2 dtc: bump version to 1.4.7

Bump from 1.4.4 to 1.4.7.

---
 package/dtc/dtc.hash | 2 +-
 package/dtc/dtc.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
package/dtc/dtc.hash +1 -1
index 75c2e40eea..b402c2249b 100644
@@ -1,2 +1,2 @@
 # from https://www.kernel.org/pub/software/utils/dtc/sha256sums.asc
-sha256 470731d5c015b160d26a96645dbb1c7337d6e7b8c98244612002b66bedf6cffb  dtc-1.4.4.tar.xz
+sha256 6643e8f00ff86350f465bb54b2185058b5b1b7bac01a0842c81a52b86589cde7 dtc-1.4.7.tar.xz
package/dtc/dtc.mk +1 -1
index 1bcee29bb3..8388793c01 100644
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-DTC_VERSION = 1.4.4
+DTC_VERSION = 1.4.7
 DTC_SOURCE = dtc-$(DTC_VERSION).tar.xz
 DTC_SITE = https://www.kernel.org/pub/software/utils/dtc
 DTC_LICENSE = GPL-2.0+ or BSD-2-Clause (library)
Signature · 1 line
2.14.1
#1 lore raw

PATCH 1/2 dtc: bump version to 1.4.7

Hello,

Quoted 7 lines · Geoff Levand

Bump from 1.4.4 to 1.4.7.

---
 package/dtc/dtc.hash | 2 +-
 package/dtc/dtc.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Applied to master, thanks.

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
#2 lore raw

PATCH 1/2 dtc: bump version to 1.4.7

In reply to Geoff Levand

Hello,

Quoted 7 lines · Geoff Levand

Bump from 1.4.4 to 1.4.7.

---
 package/dtc/dtc.hash | 2 +-
 package/dtc/dtc.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

This is failing all over the place in the autobuilders:

http://autobuild.buildroot.net/?reason=%dtc-1.4.7

Could you look into those issues and provide a patch to address them ?

Thanks!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
#3 lore raw

PATCH 1/2 dtc: bump version to 1.4.7

Hi Simon,

Any ideas about what's wrong?

Some builds show this error:

LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)

Which seems to be triggered from this:

https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Include/pyport.h#L701

I'll continue to look into it.

-Geoff

Quoted 14 lines · Thomas Petazzoni
Quoted 7 lines · Geoff Levand

Bump from 1.4.4 to 1.4.7.

---
 package/dtc/dtc.hash | 2 +-
 package/dtc/dtc.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

This is failing all over the place in the autobuilders:

http://autobuild.buildroot.net/?reason=%dtc-1.4.7

Could you look into those issues and provide a patch to address them ?

A message that is not in the archive (sent off-list or not yet received): CAPnjgZ1297i1+K=SUB-Y37jjabqxdJRA13iPxPe=MND5da44WA@mail.gmail.com

#5 lore raw

PATCH 1/2 dtc: bump version to 1.4.7

Hi Simon,

After looking at it a bit more, it seems setup.py is using the host toolchain (/usr/bin/gcc), and not the cross toolchain when linking.

Any idea how to fix this?

pylibfdt/setup.py --verbose build_ext --inplace
running build_ext
building '_libfdt' extension
swigging pylibfdt/libfdt.i to pylibfdt/libfdt_wrap.c
swig -python -I/br-bug/build/dtc-1.4.7 -o pylibfdt/libfdt_wrap.c pylibfdt/libfdt.i
/br-bug/host/bin/aarch64-linux-gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -fPIC -I libfdt -I . -fPIC -I/br-bug/host/include/python2.7 -c /br-bug/build/dtc-1.4.7/libfdt/fdt.c -o build/temp.linux-x86_64-2.7/br-bug/build/dtc-1.4.7/libfdt/fdt.o -I/br-bug/build/dtc-1.4.7 -I/br-bug/build/dtc-1.4.7/libfdt
...
/usr/bin/gcc -pthread -shared -L/br-bug/host/lib -Wl,-rpath,/br-bug/host/lib -Wl,--enable-new-dtags -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -fPIC -I libfdt -I . build/temp.linux-x86_64-2.7/br-bug/build/dtc-1.4.7/libfdt/fdt.o build/temp.linux-x86_64-2.7/br-bug/build/dtc-1.4.7/libfdt/fdt_ro.o build/temp.linux-x86_64-2.7/br-bug/build/dtc-1.4.7/libfdt/fdt_wip.o build/temp.linux-x86_64-2.7/br-bug/build/dtc-1.4.7/libfdt/fdt_sw.o build/temp.linux-x86_64-2.7/br-bug/build/dtc-1.4.7/libfdt/fdt_rw.o build/temp.linux-x86_64-2.7/br-bug/build/dtc-1.4.7/libfdt/fdt_strerror.o build/temp.linux-x86_64-2.7/br-bug/build/dtc-1.4.7/libfdt/fdt_empty_tree.o build/temp.linux-x86_64-2.7/br-bug/build/dtc-1.4.7/libfdt/fdt_addresses.o build/temp.linux-x86_64-2.7/br-bug/build/dtc-1.4.7/libfdt/fdt_overlay.o build/temp.linux-x86_64-2.7/pylibfdt/libfdt_wrap.o -L/br-bug/host/lib -lpython2.7 -o /br-bug/build/dtc-1.4.7/_libfdt.so /usr/bin/ld: build/temp.linux-x86_64-2.7/br-bug/build/dtc-1.4.7/libfdt/fdt.o: Relocations in generic ELF (EM: 183)

-Geoff

#6 lore raw

PATCH 1/1 dtc: Add set-ldshared.patch

In reply to Thomas Petazzoni

Fixes pylibfdt cross compile errors.

http://autobuild.buildroot.net/?reason=%dtc-1.4.7

---

Hi Thomas,

This gets the dtc package to build with python support, but it seems the real problem is that python distutils doesn't set LDSHARED correctly, which should default to CC.

-Geoff

 package/dtc/set-ldshared.patch | 13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 package/dtc/set-ldshared.patch
package/dtc/set-ldshared.patch new file +13 -0
new file mode 100644
index 0000000000..09220da359
@@ -0,0 +1,13 @@
+diff --git a/pylibfdt/Makefile.pylibfdt b/pylibfdt/Makefile.pylibfdt
+index 9507d3d..c2ac8e9 100644
+--- a/pylibfdt/Makefile.pylibfdt
++++ b/pylibfdt/Makefile.pylibfdt
+@@ -8,7 +8,7 @@ PYMODULE = $(PYLIBFDT_objdir)/_libfdt.so
+ define run_setup
+ 	SOURCES="$(1)" CPPFLAGS="$(CPPFLAGS)" OBJDIR="$(PYLIBFDT_objdir)"
+ 	VERSION="$(dtc_version)"
+-	$(PYLIBFDT_objdir)/setup.py --quiet $(2)
++	LDSHARED="$(CC) -shared" $(PYLIBFDT_objdir)/setup.py --quiet $(2)
+ endef
+ 
+ $(PYMODULE): $(PYLIBFDT_srcs)
Signature · 1 line
2.14.1
#7 lore raw

PATCH 1/1 dtc: Add set-ldshared.patch

Hello,

Quoted 3 lines · Geoff Levand

Fixes pylibfdt cross compile errors.

http://autobuild.buildroot.net/?reason=%dtc-1.4.7

Are you sure your patch is fixing the host-dtc build issues ?

I am seeing two different build issues:

- One for host-dtc, which looks like this:

INSTALL-PYLIB
pylibfdt/libfdt_wrap.c: In function 'SWIG_Python_NewShadowInstance':
pylibfdt/libfdt_wrap.c:2483:65: error: declaration of 'swig_this' shadows a global declaration [-Werror=shadow]
SWIG_Python_NewShadowInstance(SwigPyClientData *data, PyObject *swig_this)

                                                                 ^

pylibfdt/libfdt_wrap.c:2224:18: error: shadowed declaration is here [-Werror=shadow]
static PyObject *swig_this = NULL;

- One for dtc, which looks like this:

LD fdtoverlay
/usr/bin/ld: build/temp.linux-x86_64-2.7/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/build/dtc-1.4.7/libfdt/fdt.o: Relocations in generic ELF (EM: 8) /usr/bin/ld: build/temp.linux-x86_64-2.7/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/build/dtc-1.4.7/libfdt/fdt.o: Relocations in generic ELF (EM: 8) /usr/bin/ld: build/temp.linux-x86_64-2.7/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/build/dtc-1.4.7/libfdt/fdt.o: Relocations in generic ELF (EM: 8) /usr/bin/ld: build/temp.linux-x86_64-2.7/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/build/dtc-1.4.7/libfdt/fdt.o: Relocations in generic ELF (EM: 8) /usr/bin/ld: build/temp.linux-x86_64-2.7/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/build/dtc-1.4.7/libfdt/fdt.o: Relocations in generic ELF (EM: 8) /usr/bin/ld: build/temp.linux-x86_64-2.7/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/build/dtc-1.4.7/libfdt/fdt.o: Relocations in generic ELF (EM: 8) /usr/bin/ld: build/temp.linux-x86_64-2.7/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/build/dtc-1.4.7/libfdt/fdt.o: Relocations in generic ELF (EM: 8) build/temp.linux-x86_64-2.7/usr/lfs/v0/rc-buildroot-test/scripts/instance-2/output/build/dtc-1.4.7/libfdt/fdt.o: error adding symbols: File in wrong format

Your patch probably fixes the "dtc" issue, but I'm not sure it fixes the host-dtc issue.

package/dtc/set-ldshared.patch

Quoted 6 lines
package/dtc/set-ldshared.patch new file +0 -0
new file mode 100644
index 0000000000..09220da359
@@ -0,0 +1,13 @@

Patches should be Git formatted, have a description and a Signed-off-by.

package/dtc/set-ldshared.patch line 10

Quoted 10 lines
package/dtc/set-ldshared.patch new file +10 -0
+diff --git a/pylibfdt/Makefile.pylibfdt b/pylibfdt/Makefile.pylibfdt
+index 9507d3d..c2ac8e9 100644
+--- a/pylibfdt/Makefile.pylibfdt
++++ b/pylibfdt/Makefile.pylibfdt
+@@ -8,7 +8,7 @@ PYMODULE = $(PYLIBFDT_objdir)/_libfdt.so
+ define run_setup
+ 	SOURCES="$(1)" CPPFLAGS="$(CPPFLAGS)" OBJDIR="$(PYLIBFDT_objdir)"
+ 	VERSION="$(dtc_version)"
+-	$(PYLIBFDT_objdir)/setup.py --quiet $(2)
++	LDSHARED="$(CC) -shared" $(PYLIBFDT_objdir)/setup.py --quiet $(2)

Do we know why it was working before, and why it fails since the dtc update ?

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
#8 lore raw

PATCH 1/1 dtc: Add set-ldshared.patch

Hello,

Quoted 5 lines · Thomas Petazzoni

Are you sure your patch is fixing the host-dtc build issues ?

I am seeing two different build issues:

- One for host-dtc, which looks like this:

[...]

Quoted 1 line

- One for dtc, which looks like this:

Since all those problems are due to pylibfdt, which is new since 1.4.5, and that we don't use in Buildroot, I applied a simpler fix: pass NO_PYTHON=1 so that we don't build the Python support, even if the necessary dependencies are found.

See:

https://git.buildroot.org/buildroot/commit/?id=b50c95e914c6366e30145378fa82f286d4412c51

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
#9 lore raw

PATCH 1/1 dtc: Add set-ldshared.patch

Quoted 3 lines · Thomas Petazzoni

I applied a simpler fix: pass
NO_PYTHON=1 so that we don't build the Python support, even if the necessary dependencies are found.

OK, great. Thanks for looking into it.

-Geoff