* [Buildroot] Analysis results for 2018-10-09
2018-10-10 15:48 ` [Buildroot] Analysis " Thomas Petazzoni
@ 2018-10-10 16:28 ` Matthew Weber
2018-10-10 17:57 ` Fabrice Fontaine
` (2 more replies)
2018-10-10 21:30 ` Arnout Vandecappelle
` (7 subsequent siblings)
8 siblings, 3 replies; 37+ messages in thread
From: Matthew Weber @ 2018-10-10 16:28 UTC (permalink / raw)
To: buildroot
Thomas,
On Wed, Oct 10, 2018 at 10:48 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> Here is an analysis of yesterday build results. Johan, Frank,
> Christian, Fabrice, Peter, Matt, Bernd, Giulio, Baruch, you are in Cc
> because there are questions/issues for you below. Thanks! :-)
>
> On Wed, 10 Oct 2018 08:00:10 +0200 (CEST), Thomas Petazzoni wrote:
>
> > master | 187 | 68 | 0 | 255 |
>
> These results are not very good, let's have a look at what's going on,
> and try to get everyone to help fixing those issues.
>
> > arm | boa-0.94.14rc21 | NOK | http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11 | ORPH
>
> (cd src && make - --no-print-directory - --jobserver-fds=6,7 -j)
> make: unrecognized option '--jobserver-fds=6,7'
>
> This suddenly started happening on September 9, 2018. We have not
> bumped boa. I'm not sure what caused this. It fails on different
> autobuilder machines. Boa is calling submake with $(MFLAGS), which is
> probably the issue, but why did this suddenly started to happen ?
>
> With a minimal configuration with just Boa, I cannot reproduce on my
> machine here, neither on my autobuilder where the problem is reported
> to occur.
>
> > i686 | boost-1.68.0 | NOK | http://autobuild.buildroot.net/results/1ceed7d91627711c12c4866fa6672a02fc6ddc8c |
>
> libboost_chrono shouldn't have been installed: missing select in boost/Config.in
>
> > arm | boost-1.68.0 | NOK | http://autobuild.buildroot.net/results/41054f876975214741dccd08eda999a425281b7f |
>
> libboost_atomic shouldn't have been installed: missing select in boost/Config.in
>
> Fabrice, these two are for you :)
>
> > mips64el | brltty-5.6 | NOK | http://autobuild.buildroot.net/results/7187e560e66f2bd6073b5510e2782ebdaccfb4a9 |
> > mips64el | brltty-5.6 | NOK | http://autobuild.buildroot.net/results/5f8e8b8517fda50a2e98a456933260f08054356d |
>
> Those should be fixed by
> https://git.buildroot.org/buildroot/commit/?id=9143c217213542574586c0e6a9f003e822633917.
>
> > aarch64 | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/24a280d6233b3284edd44c4528d8799c6894c11a | ORPH
> > sh4 | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/63a4f980d7cdb4b0823840f747589803fcd0d69f | ORPH
> > arc | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/1a6f2fcf1a88ecc5b598dd11c5914dcacf0e1e6b | ORPH
> > arm | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/b0829bc3343d6dc3065078e94896725b1c808bc1 | ORPH
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/package/collectd?id=d65ea85fddaf64a7762f958d1ce9fb33997648d3
>
> > x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/6c26ac3a8aa39abcb5eb390109891790610a759b |
> > x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/10654bccc3d20ec6d29d371c48dd90cbddb8c4da |
> > x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/56b564a27a06792c4854fe983da92d40c0c4708c |
>
> /home/naourr/work/instance-3/output/host/lib/go/pkg/tool/linux_amd64/link: running /home/naourr/work/instance-3/output/host/bin/x86_64-amd-linux-gnu-gcc failed: exit status 1
> /tmp/go-build283204336/b001/exe/a.out: final close failed: Invalid operation
>
> Christian, what is happening here? Could you have a look?
>
> > x86_64 | erlang-21.0 | NOK | http://autobuild.buildroot.net/results/fc633f80c7c36a90e641487f5a888fbb767c2a54 |
>
> In file included from zlib/adler32.c:11:0:
> zlib/zutil.h:172:39: error: "_LFS64_LARGEFILE" is not defined [-Werror=undef]
> (!defined(_LARGEFILE64_SOURCE) || _LFS64_LARGEFILE-0 == 0)
>
> Seems like a musl/erlang issue. Johan, Frank, could you have a look ?
>
> > arc | glibc-legal-info | NOK | http://autobuild.buildroot.net/results/64c70d82c857c272df171ae6783629c1ba92d812 | ORPH
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=b14ad0bd697038e4cf48ecf48830fb3369f1f25e.
>
> > mips64el | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/c00d22a6dcadb82a19afab6eacea654d3c41b4c5 | ORPH
> > powerpc | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/18599ea12a35b9715a67c1f4e5c4e56906235c94 | ORPH
> > arm | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/a13a5d852c83cd1fc9f2d1fc2b7302db515278b8 | ORPH
>
> Fixed by https://git.buildroot.org/buildroot/commit/package/gpsd?id=ae2a91322aeaa72d6f5354312056d16dc275470d
>
> > mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
>
>
> gstspanplc.c:223:21: error: dereferencing pointer to incomplete type 'plc_state_t {aka struct plc_state_s}'
> if (plc->plc_state->missing_samples != 0)
>
> Peter (Seiderer) ?
>
> > arm | host-go-1.11 | NOK | http://autobuild.buildroot.net/results/8d3af6f00bf34737faabc21bdccf7d025462fec7 |
>
> fatal error: unexpected signal during runtime execution
> [signal SIGBUS: bus error code=0x2 addr=0xc000800010 pc=0x42098d]
>
> This particular issue seems to happen only on Matt autobuilder. Matt,
> can you check if you can reproduce it reliably ?
I'll take a look.
>
> > powerpc | libmpeg2-0.5.1 | NOK | http://autobuild.buildroot.net/results/69f52854b222b5be1a981b96a804098fec5a849b | ORPH
> > powerpc | libmpeg2-0.5.1 | NOK | http://autobuild.buildroot.net/results/eb8dc1e67eae123a823fadc17ca7611c2cc7f621 | ORPH
>
> motion_comp_altivec.c:48:12: internal compiler error: Segmentation fault
> return vec_ld (A, (uint8_t *)B);
>
> Bernd, could you have a look at this PowerPC/Altivec issue ?
>
> > arm | luvi-v2.8.0 | NOK | http://autobuild.buildroot.net/results/2bdbb93e6404943e59791773106d8b2680211886 |
>
> luvi 2.8.0 fails to build. Bernd, you bumped this package, and J?rg
> suggested to revert the bump. Could you discuss this, and provide a fix?
>
> > aarch64 | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/dcbbae0180bc597c58fc694c3006b623633aab7f |
> > aarch64 | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/cef7e38fbd4de65d1830f681a497bc007a897502 |
> > arm | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/62143510a7ede7d92f55e908306bc367586c2748 |
> > sparc64 | Makefile:709: target-finalize | NOK | http://autobuild.buildroot.net/results/d0c1aa394745ba48d832cc77c23721ca6b453d23 |
>
> See below "target-finalize"
>
> > m68k | minizip-2.5.3 | NOK | http://autobuild.buildroot.net/results/78b8eb0f9f7f2963f0056834054f16e764bc3106 |
>
> /home/buildroot/build/instance-0/output/host/m68k-buildroot-linux-uclibc/sysroot/usr/lib/libbsd.so: undefined reference to `__register_atfork'
> collect2: error: ld returned 1 exit status
>
> I guess it would be fixed by http://patchwork.ozlabs.org/patch/978465/.
> Someone needs to review this.
>
> > powerpc | motion-release-4.1.1 | NOK | http://autobuild.buildroot.net/results/78061b61cfe3f42554a475c048d54dacacfe11d5 |
>
>
> /home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/powerpc-buildroot-linux-uclibc/sysroot/usr/lib/libavutil.a(hwcontext_drm.o): In function `drm_device_create':
> /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:50: undefined reference to `drmGetVersion'
> /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:63: undefined reference to `drmFreeVersion'
>
> Giulio, I believe you worked on this static linking problem between
> ffmpeg and libdrm. What is the status of this ?
>
> > arm | netsnmp-5.8 | NOK | http://autobuild.buildroot.net/results/9f02e0f09ae2d2a66a8d33d73f1bdd45ea8b0f16 | ORPH
>
> configure: error: The DTLS based transports require the libssl library from OpenSSL to be available and support DTLS
>
> Bernd, you did the last version bump of netsnmp, could you have a look ?
>
> > arm | open-plc-utils-1be781d1ea81... | NOK | http://autobuild.buildroot.net/results/67bc5e7ac8ae1c49c035b022a394d2f746705cf2 |
>
> I assume this would be fixed by
> http://patchwork.ozlabs.org/patch/981495/.
>
> > arc | package/glibc/glibc.mk:143:... | NOK | http://autobuild.buildroot.net/results/4a1ddb5c0afb1e80ac769d36cb720372f7bb5457 |
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/package/glibc?id=b14ad0bd697038e4cf48ecf48830fb3369f1f25e.
>
> > arm | php-7.2.10 | NOK | http://autobuild.buildroot.net/results/7b7e25bfd269f7c252d15ab4e9f1b68348823478 | ORPH
>
> multiple definition of `icu_60::MessageFormatAdapter::getArgTypeList(icu_60::MessageFormat const&, int&)'
>
> Long standing issue. Anyone brave enough to investigate ?
>
> > microblazeel | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/1c00bfa77c38f0aad7643344b16d8f401c9b927a | ORPH
> > arm | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/298fda61ab5a192c235027e1b4c57aba4e6b8b37 | ORPH
> > mips64el | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/8fe8061cb27cbab8f02e6dfb0a870d76be3f7f3e | ORPH
> > xtensa | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/80b014e965b088e6767af671d39657b415f82453 | ORPH
> > mipsel | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/40f1090a0eb720d4cce2715bca51823213efb9f9 | ORPH
> > arm | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/55933c2c4ecf8a84b283c93adf0c2ed8a4f03301 | ORPH
> > mips64el | ptpd2-ptpd-2.3.1 | NOK | http://autobuild.buildroot.net/results/08d40b95945ed0e61805b07446b5eb5731f23198 | ORPH
>
> Should be fixed by http://patchwork.ozlabs.org/patch/964746/. I haven't
> had the chance to review it.
>
> > aarch64_be | qt5base-5.11.2 | NOK | http://autobuild.buildroot.net/results/aeddb85c0262cdc23019c72e1c390d3885cb4ae4 |
> > aarch64_be | qt5base-5.11.2 | NOK | http://autobuild.buildroot.net/results/5bec7d7f14befa3a03f902ef90cc2c6589943ec2 |
>
> /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64_be-linux-gnu/7.3.1/../../../../aarch64_be-linux-gnu/bin/ld.gold: internal error in update_erratum_insn, at /home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64_be-linux-gnu/snapshots/binutils-gdb.git~users~linaro~binutils-2_28-branch/gold/aarch64.cc:998
>
> Compiler bug it seems. Anyone to have a look ?
>
> > mipsel | qt5webkit-5.9.1 | NOK | http://autobuild.buildroot.net/results/7aca204c7fd486def6306412b0a6e0bfb8234786 |
>
> {standard input}: Assembler messages:
> {standard input}:708: Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $v0,$t8,$t7'
> {standard input}:759: Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $v1,$t8,$t7'
> {standard input}:765: Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $t2,$t8,$t7'
>
> We should disable qt5webkit on mips32r6. Peter ?
>
> > arm | qt5webkit-5.9.1 | NOK | http://autobuild.buildroot.net/results/b8ae1b94891206746815fa85fafabfbd6bed8c74 |
>
> /home/naourr/work/instance-3/output/build/qt5webkit-5.9.1/Source/WebCore//.obj/platform/leveldb/LevelDBDatabase.o: In function `WebCore::LevelDBDatabase::openInMemory(WebCore::LevelDBComparator const*)':
> LevelDBDatabase.cpp:(.text._ZN7WebCore15LevelDBDatabase12openInMemoryEPKNS_17LevelDBComparatorE+0x22): undefined reference to `leveldb::NewMemEnv(leveldb::Env*)'
>
> Ah, yes, we have a patch fixing that in patchwork. I don't like it a
> lot, but I guess that's the only option.
>
> > arm | spandsp-20180108 | NOK | http://autobuild.buildroot.net/results/05885325ec274cb9860d423c57eed5e7063aedc0 |
>
> checking for TIFFOpen in -ltiff... no
> configure: error: "Cannot build without libtiff (does your system require a libtiff-devel package?)"
>
> Bernd, you added spandsp recently, could you have a look ?
>
> > powerpc | squid-4.2 | NOK | http://autobuild.buildroot.net/results/e679ef90219c5e8f9c94ddcd7d3f9582f79ef751 | ORPH
>
> ../../src/StatHist.h:112:30: error: invalid pure specifier (only '= 0' is allowed) before ';' token
> ../../src/StatHist.h:113:31: error: invalid pure specifier (only '= 0' is allowed) before ';' token
>
> Not sure. Baruch, you recently bumped the squid package, could you have
> a look ?
>
> > microblazeel | target-finalize | NOK | http://autobuild.buildroot.net/results/068fa36a0be7a2207144cfcc9d595d6099bd9e39 |
> > xtensa | target-finalize | NOK | http://autobuild.buildroot.net/results/3b17b82658842849cf72d01b6f6a4f735e13a642 |
> > xtensa | target-finalize | NOK | http://autobuild.buildroot.net/results/c76bf4a1902da001de673c2160e7f68f83072feb |
> > mips | target-finalize | NOK | http://autobuild.buildroot.net/results/a0f68aba5c02cbf053c0a425667f1393ef71a0e5 |
> > arc | target-finalize | NOK | http://autobuild.buildroot.net/results/21adc28431f328526d88158e98e84b2fab2e4275 |
> > mipsel | target-finalize | NOK | http://autobuild.buildroot.net/results/0bf569d8d0ae380bdd1c8b6ddfa111e85670e981 |
> > powerpc | target-finalize | NOK | http://autobuild.buildroot.net/results/f92fd883386a547d42e0c699f7db859f2918e3f2 |
> > powerpc | target-finalize | NOK | http://autobuild.buildroot.net/results/ca096daed97a11b9be1618bd284b626527414e88 |
> > arm | target-finalize | NOK | http://autobuild.buildroot.net/results/8b4ce48f1b612710b8f2bb1b4ca3b203e1ed6293 |
> > aarch64 | target-finalize | NOK | http://autobuild.buildroot.net/results/797e736dc81d84e63a9293a7b1b62d7d4ae29194 |
> > arc | target-finalize | NOK | http://autobuild.buildroot.net/results/dd94cc60c4eb5a102b04db52b0ee2c7417c0c2f5 |
> > x86_64 | target-finalize | NOK | http://autobuild.buildroot.net/results/8329204dc3737635b92c2fdef224992f3c302f0c |
> > arm | target-finalize | NOK | http://autobuild.buildroot.net/results/5ab016529d2ec177f2865ac184d4a91149a649db |
> > aarch64_be | target-finalize | NOK | http://autobuild.buildroot.net/results/b8e27bd74c40cbc6f6ed9c5df4f0021af4fda050 |
> > mips64el | target-finalize | NOK | http://autobuild.buildroot.net/results/a5f6626116e8e721d5f6eb1d0aebf4656b9452f0 |
> > arm | target-finalize | NOK | http://autobuild.buildroot.net/results/89b5cc38f7b45046417fa20bbd8078646e9c39ef |
> > aarch64 | target-finalize | NOK | http://autobuild.buildroot.net/results/a28d07fd7999f1505a346598ea62ac3c212db7a2 |
> > arc | target-finalize | NOK | http://autobuild.buildroot.net/results/c905171b7a2beb768e23c7b834c50df0764500e1 |
>
> I had a look at those 22 (18+4) failures, and all of them are caused either by
> pysnmp or psycopg2 issues with Python 3.7.0. pysnmp was fixed today
> (https://git.buildroot.org/buildroot/commit/?id=8122a1d85b6cc9f2adcb1243521c04ba4cae0510).
> So the only package remaining package to fix is psycopg2.
>
> Asaf, Yegor, Adam, could one of you take care of fixing psycopg2 soon ?
>
> Related to this, I find it a bit annoying that all those issues are
> detected at the target-finalize step, since package maintainers are not
> properly notified. Should we move the byte-compile step as the end of
> each Python package installation, so that if it fails, it fails
> earlier, and within the context of that package ? Is the
> byte-compilation process smart enough to skip compiling when a .pyc
> file already exists and is newer than the matching .py file ? It would
> be interesting to do a time comparison between doing per-package
> byte-compilation and one global byte-compilation at the end.
>
>
> > arc | traceroute-2.1.0 | NOK | http://autobuild.buildroot.net/results/22855418dcb5bca4b6499991bc810b368a0cfcd5 |
>
> make[3]: *** No rule to make target '-lm', needed by 'traceroute'. Stop.
> make[3]: *** Waiting for unfinished jobs....
>
> Meh ?
>
> > powerpc64le | util-linux-2.32.1 | NOK | http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b |
>
>
> checking for SELINUX... no
> configure: error: SELinux selected but libselinux not found or too old
>
> We've been having this one for a while. Could some SELinux person
> (Matt ? Adam ?) debug this ?
I can take a look. Before I dig to deep, I'd suggest applying the 2.8
bump (http://patchwork.ozlabs.org/project/buildroot/list/?series=66983).
I've finished runtime testing and it would be good to fix this and
perform my testing on the latest.
Note, this report doesn't have it, but there has been a standing
host-libsemanage 2.7 failure I've been ignoring until the 2.8 is
applied. (http://autobuild.buildroot.net/?reason=host-libsemanage-2.7)
Matt
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-10 16:28 ` Matthew Weber
@ 2018-10-10 17:57 ` Fabrice Fontaine
2018-10-10 19:14 ` Thomas Petazzoni
2018-10-10 19:05 ` Thomas Petazzoni
2018-10-12 16:00 ` Matthew Weber
2 siblings, 1 reply; 37+ messages in thread
From: Fabrice Fontaine @ 2018-10-10 17:57 UTC (permalink / raw)
To: buildroot
Dear all,
Le mer. 10 oct. 2018 ? 18:28, Matthew Weber <
matthew.weber@rockwellcollins.com> a ?crit :
> Thomas,
>
>
> On Wed, Oct 10, 2018 at 10:48 AM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> >
> > Hello,
> >
> > Here is an analysis of yesterday build results. Johan, Frank,
> > Christian, Fabrice, Peter, Matt, Bernd, Giulio, Baruch, you are in Cc
> > because there are questions/issues for you below. Thanks! :-)
> >
> > On Wed, 10 Oct 2018 08:00:10 +0200 (CEST), Thomas Petazzoni wrote:
> >
> > > master | 187 | 68 | 0 | 255 |
> >
> > These results are not very good, let's have a look at what's going on,
> > and try to get everyone to help fixing those issues.
> >
> > > arm | boa-0.94.14rc21 | NOK |
> http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11
> | ORPH
> >
> > (cd src && make - --no-print-directory - --jobserver-fds=6,7 -j)
> > make: unrecognized option '--jobserver-fds=6,7'
> >
> > This suddenly started happening on September 9, 2018. We have not
> > bumped boa. I'm not sure what caused this. It fails on different
> > autobuilder machines. Boa is calling submake with $(MFLAGS), which is
> > probably the issue, but why did this suddenly started to happen ?
> >
> > With a minimal configuration with just Boa, I cannot reproduce on my
> > machine here, neither on my autobuilder where the problem is reported
> > to occur.
> >
> > > i686 | boost-1.68.0 | NOK |
> http://autobuild.buildroot.net/results/1ceed7d91627711c12c4866fa6672a02fc6ddc8c
> |
> >
> > libboost_chrono shouldn't have been installed: missing select in
> boost/Config.in
>
Can be fixed by https://patchwork.ozlabs.org/patch/960723.
> >
> > > arm | boost-1.68.0 | NOK |
> http://autobuild.buildroot.net/results/41054f876975214741dccd08eda999a425281b7f
> |
> >
> > libboost_atomic shouldn't have been installed: missing select in
> boost/Config.in
>
Can be fixed by https://patchwork.ozlabs.org/patch/966309.
It should be noted that this patch has been merged upstream:
https://github.com/boostorg/thread/commit/f7581a366294c6f5381e0371c242af327c6da655
> >
> > Fabrice, these two are for you :)
> >
> > > mips64el | brltty-5.6 | NOK |
> http://autobuild.buildroot.net/results/7187e560e66f2bd6073b5510e2782ebdaccfb4a9
> |
> > > mips64el | brltty-5.6 | NOK |
> http://autobuild.buildroot.net/results/5f8e8b8517fda50a2e98a456933260f08054356d
> |
> >
> > Those should be fixed by
> >
> https://git.buildroot.org/buildroot/commit/?id=9143c217213542574586c0e6a9f003e822633917
> .
> >
> > > aarch64 | collectd-5.7.1 | NOK |
> http://autobuild.buildroot.net/results/24a280d6233b3284edd44c4528d8799c6894c11a
> | ORPH
> > > sh4 | collectd-5.7.1 | NOK |
> http://autobuild.buildroot.net/results/63a4f980d7cdb4b0823840f747589803fcd0d69f
> | ORPH
> > > arc | collectd-5.7.1 | NOK |
> http://autobuild.buildroot.net/results/1a6f2fcf1a88ecc5b598dd11c5914dcacf0e1e6b
> | ORPH
> > > arm | collectd-5.7.1 | NOK |
> http://autobuild.buildroot.net/results/b0829bc3343d6dc3065078e94896725b1c808bc1
> | ORPH
> >
> > Fixed by
> >
> https://git.buildroot.org/buildroot/commit/package/collectd?id=d65ea85fddaf64a7762f958d1ce9fb33997648d3
> >
> > > x86_64 | docker-containerd-v1.1.3 | NOK |
> http://autobuild.buildroot.net/results/6c26ac3a8aa39abcb5eb390109891790610a759b
> |
> > > x86_64 | docker-containerd-v1.1.3 | NOK |
> http://autobuild.buildroot.net/results/10654bccc3d20ec6d29d371c48dd90cbddb8c4da
> |
> > > x86_64 | docker-containerd-v1.1.3 | NOK |
> http://autobuild.buildroot.net/results/56b564a27a06792c4854fe983da92d40c0c4708c
> |
> >
> >
> /home/naourr/work/instance-3/output/host/lib/go/pkg/tool/linux_amd64/link:
> running
> /home/naourr/work/instance-3/output/host/bin/x86_64-amd-linux-gnu-gcc
> failed: exit status 1
> > /tmp/go-build283204336/b001/exe/a.out: final close failed: Invalid
> operation
> >
> > Christian, what is happening here? Could you have a look?
> >
> > > x86_64 | erlang-21.0 | NOK |
> http://autobuild.buildroot.net/results/fc633f80c7c36a90e641487f5a888fbb767c2a54
> |
> >
> > In file included from zlib/adler32.c:11:0:
> > zlib/zutil.h:172:39: error: "_LFS64_LARGEFILE" is not defined
> [-Werror=undef]
> > (!defined(_LARGEFILE64_SOURCE) || _LFS64_LARGEFILE-0 == 0)
> >
> > Seems like a musl/erlang issue. Johan, Frank, could you have a look ?
> >
> > > arc | glibc-legal-info | NOK |
> http://autobuild.buildroot.net/results/64c70d82c857c272df171ae6783629c1ba92d812
> | ORPH
> >
> > Fixed by
> >
> https://git.buildroot.org/buildroot/commit/?id=b14ad0bd697038e4cf48ecf48830fb3369f1f25e
> .
> >
> > > mips64el | gpsd-3.18 | NOK |
> http://autobuild.buildroot.net/results/c00d22a6dcadb82a19afab6eacea654d3c41b4c5
> | ORPH
> > > powerpc | gpsd-3.18 | NOK |
> http://autobuild.buildroot.net/results/18599ea12a35b9715a67c1f4e5c4e56906235c94
> | ORPH
> > > arm | gpsd-3.18 | NOK |
> http://autobuild.buildroot.net/results/a13a5d852c83cd1fc9f2d1fc2b7302db515278b8
> | ORPH
> >
> > Fixed by
> https://git.buildroot.org/buildroot/commit/package/gpsd?id=ae2a91322aeaa72d6f5354312056d16dc275470d
> >
> > > mips64el | gst-plugins-bad-0.10.23 | NOK |
> http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5
> | ORPH
> >
> >
> > gstspanplc.c:223:21: error: dereferencing pointer to incomplete type
> 'plc_state_t {aka struct plc_state_s}'
> > if (plc->plc_state->missing_samples != 0)
> >
> > Peter (Seiderer) ?
> >
> > > arm | host-go-1.11 | NOK |
> http://autobuild.buildroot.net/results/8d3af6f00bf34737faabc21bdccf7d025462fec7
> |
> >
> > fatal error: unexpected signal during runtime execution
> > [signal SIGBUS: bus error code=0x2 addr=0xc000800010 pc=0x42098d]
> >
> > This particular issue seems to happen only on Matt autobuilder. Matt,
> > can you check if you can reproduce it reliably ?
>
> I'll take a look.
>
> >
> > > powerpc | libmpeg2-0.5.1 | NOK |
> http://autobuild.buildroot.net/results/69f52854b222b5be1a981b96a804098fec5a849b
> | ORPH
> > > powerpc | libmpeg2-0.5.1 | NOK |
> http://autobuild.buildroot.net/results/eb8dc1e67eae123a823fadc17ca7611c2cc7f621
> | ORPH
> >
> > motion_comp_altivec.c:48:12: internal compiler error: Segmentation fault
> > return vec_ld (A, (uint8_t *)B);
> >
> > Bernd, could you have a look at this PowerPC/Altivec issue ?
>
>
> > > arm | luvi-v2.8.0 | NOK |
> http://autobuild.buildroot.net/results/2bdbb93e6404943e59791773106d8b2680211886
> |
> >
> > luvi 2.8.0 fails to build. Bernd, you bumped this package, and J?rg
> > suggested to revert the bump. Could you discuss this, and provide a fix?
> >
> > > aarch64 | Makefile:709: target-finalize | NOK |
> http://autobuild.buildroot.net/results/dcbbae0180bc597c58fc694c3006b623633aab7f
> |
> > > aarch64 | Makefile:709: target-finalize | NOK |
> http://autobuild.buildroot.net/results/cef7e38fbd4de65d1830f681a497bc007a897502
> |
> > > arm | Makefile:709: target-finalize | NOK |
> http://autobuild.buildroot.net/results/62143510a7ede7d92f55e908306bc367586c2748
> |
> > > sparc64 | Makefile:709: target-finalize | NOK |
> http://autobuild.buildroot.net/results/d0c1aa394745ba48d832cc77c23721ca6b453d23
> |
> >
> > See below "target-finalize"
> >
> > > m68k | minizip-2.5.3 | NOK |
> http://autobuild.buildroot.net/results/78b8eb0f9f7f2963f0056834054f16e764bc3106
> |
> >
> >
> /home/buildroot/build/instance-0/output/host/m68k-buildroot-linux-uclibc/sysroot/usr/lib/libbsd.so:
> undefined reference to `__register_atfork'
> > collect2: error: ld returned 1 exit status
> >
> > I guess it would be fixed by http://patchwork.ozlabs.org/patch/978465/.
> > Someone needs to review this.
> >
> > > powerpc | motion-release-4.1.1 | NOK |
> http://autobuild.buildroot.net/results/78061b61cfe3f42554a475c048d54dacacfe11d5
> |
> >
> >
> >
> /home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/powerpc-buildroot-linux-uclibc/sysroot/usr/lib/libavutil.a(hwcontext_drm.o):
> In function `drm_device_create':
> >
> /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:50:
> undefined reference to `drmGetVersion'
> >
> /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:63:
> undefined reference to `drmFreeVersion'
> >
> > Giulio, I believe you worked on this static linking problem between
> > ffmpeg and libdrm. What is the status of this ?
> >
> > > arm | netsnmp-5.8 | NOK |
> http://autobuild.buildroot.net/results/9f02e0f09ae2d2a66a8d33d73f1bdd45ea8b0f16
> | ORPH
> >
> > configure: error: The DTLS based transports require the libssl library
> from OpenSSL to be available and support DTLS
> >
> > Bernd, you did the last version bump of netsnmp, could you have a look ?
> >
> > > arm | open-plc-utils-1be781d1ea81... | NOK |
> http://autobuild.buildroot.net/results/67bc5e7ac8ae1c49c035b022a394d2f746705cf2
> |
> >
> > I assume this would be fixed by
> > http://patchwork.ozlabs.org/patch/981495/.
> >
> > > arc | package/glibc/glibc.mk:143:... | NOK |
> http://autobuild.buildroot.net/results/4a1ddb5c0afb1e80ac769d36cb720372f7bb5457
> |
> >
> > Fixed by
> >
> https://git.buildroot.org/buildroot/commit/package/glibc?id=b14ad0bd697038e4cf48ecf48830fb3369f1f25e
> .
> >
> > > arm | php-7.2.10 | NOK |
> http://autobuild.buildroot.net/results/7b7e25bfd269f7c252d15ab4e9f1b68348823478
> | ORPH
> >
> > multiple definition of
> `icu_60::MessageFormatAdapter::getArgTypeList(icu_60::MessageFormat const&,
> int&)'
> >
> > Long standing issue. Anyone brave enough to investigate ?
> >
> > > microblazeel | ptpd2-ptpd-2.3.1 | NOK |
> http://autobuild.buildroot.net/results/1c00bfa77c38f0aad7643344b16d8f401c9b927a
> | ORPH
> > > arm | ptpd2-ptpd-2.3.1 | NOK |
> http://autobuild.buildroot.net/results/298fda61ab5a192c235027e1b4c57aba4e6b8b37
> | ORPH
> > > mips64el | ptpd2-ptpd-2.3.1 | NOK |
> http://autobuild.buildroot.net/results/8fe8061cb27cbab8f02e6dfb0a870d76be3f7f3e
> | ORPH
> > > xtensa | ptpd2-ptpd-2.3.1 | NOK |
> http://autobuild.buildroot.net/results/80b014e965b088e6767af671d39657b415f82453
> | ORPH
> > > mipsel | ptpd2-ptpd-2.3.1 | NOK |
> http://autobuild.buildroot.net/results/40f1090a0eb720d4cce2715bca51823213efb9f9
> | ORPH
> > > arm | ptpd2-ptpd-2.3.1 | NOK |
> http://autobuild.buildroot.net/results/55933c2c4ecf8a84b283c93adf0c2ed8a4f03301
> | ORPH
> > > mips64el | ptpd2-ptpd-2.3.1 | NOK |
> http://autobuild.buildroot.net/results/08d40b95945ed0e61805b07446b5eb5731f23198
> | ORPH
> >
> > Should be fixed by http://patchwork.ozlabs.org/patch/964746/. I haven't
> > had the chance to review it.
> >
> > > aarch64_be | qt5base-5.11.2 | NOK |
> http://autobuild.buildroot.net/results/aeddb85c0262cdc23019c72e1c390d3885cb4ae4
> |
> > > aarch64_be | qt5base-5.11.2 | NOK |
> http://autobuild.buildroot.net/results/5bec7d7f14befa3a03f902ef90cc2c6589943ec2
> |
> >
> >
> /home/buildroot/build/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64_be-linux-gnu/7.3.1/../../../../aarch64_be-linux-gnu/bin/ld.gold:
> internal error in update_erratum_insn, at
> /home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64_be-linux-gnu/snapshots/binutils-gdb.git~users~linaro~binutils-2_28-branch/gold/aarch64.cc:998
> >
> > Compiler bug it seems. Anyone to have a look ?
> >
> > > mipsel | qt5webkit-5.9.1 | NOK |
> http://autobuild.buildroot.net/results/7aca204c7fd486def6306412b0a6e0bfb8234786
> |
> >
> > {standard input}: Assembler messages:
> > {standard input}:708: Error: opcode not supported on this processor:
> mips32r6 (mips32r6) `movz $v0,$t8,$t7'
> > {standard input}:759: Error: opcode not supported on this processor:
> mips32r6 (mips32r6) `movz $v1,$t8,$t7'
> > {standard input}:765: Error: opcode not supported on this processor:
> mips32r6 (mips32r6) `movz $t2,$t8,$t7'
> >
> > We should disable qt5webkit on mips32r6. Peter ?
> >
> > > arm | qt5webkit-5.9.1 | NOK |
> http://autobuild.buildroot.net/results/b8ae1b94891206746815fa85fafabfbd6bed8c74
> |
> >
> >
> /home/naourr/work/instance-3/output/build/qt5webkit-5.9.1/Source/WebCore//.obj/platform/leveldb/LevelDBDatabase.o:
> In function
> `WebCore::LevelDBDatabase::openInMemory(WebCore::LevelDBComparator const*)':
> >
> LevelDBDatabase.cpp:(.text._ZN7WebCore15LevelDBDatabase12openInMemoryEPKNS_17LevelDBComparatorE+0x22):
> undefined reference to `leveldb::NewMemEnv(leveldb::Env*)'
> >
> > Ah, yes, we have a patch fixing that in patchwork. I don't like it a
> > lot, but I guess that's the only option.
> >
> > > arm | spandsp-20180108 | NOK |
> http://autobuild.buildroot.net/results/05885325ec274cb9860d423c57eed5e7063aedc0
> |
> >
> > checking for TIFFOpen in -ltiff... no
> > configure: error: "Cannot build without libtiff (does your system
> require a libtiff-devel package?)"
> >
> > Bernd, you added spandsp recently, could you have a look ?
> >
> > > powerpc | squid-4.2 | NOK |
> http://autobuild.buildroot.net/results/e679ef90219c5e8f9c94ddcd7d3f9582f79ef751
> | ORPH
> >
> > ../../src/StatHist.h:112:30: error: invalid pure specifier (only '= 0'
> is allowed) before ';' token
> > ../../src/StatHist.h:113:31: error: invalid pure specifier (only '= 0'
> is allowed) before ';' token
> >
> > Not sure. Baruch, you recently bumped the squid package, could you have
> > a look ?
> >
> > > microblazeel | target-finalize | NOK |
> http://autobuild.buildroot.net/results/068fa36a0be7a2207144cfcc9d595d6099bd9e39
> |
> > > xtensa | target-finalize | NOK |
> http://autobuild.buildroot.net/results/3b17b82658842849cf72d01b6f6a4f735e13a642
> |
> > > xtensa | target-finalize | NOK |
> http://autobuild.buildroot.net/results/c76bf4a1902da001de673c2160e7f68f83072feb
> |
> > > mips | target-finalize | NOK |
> http://autobuild.buildroot.net/results/a0f68aba5c02cbf053c0a425667f1393ef71a0e5
> |
> > > arc | target-finalize | NOK |
> http://autobuild.buildroot.net/results/21adc28431f328526d88158e98e84b2fab2e4275
> |
> > > mipsel | target-finalize | NOK |
> http://autobuild.buildroot.net/results/0bf569d8d0ae380bdd1c8b6ddfa111e85670e981
> |
> > > powerpc | target-finalize | NOK |
> http://autobuild.buildroot.net/results/f92fd883386a547d42e0c699f7db859f2918e3f2
> |
> > > powerpc | target-finalize | NOK |
> http://autobuild.buildroot.net/results/ca096daed97a11b9be1618bd284b626527414e88
> |
> > > arm | target-finalize | NOK |
> http://autobuild.buildroot.net/results/8b4ce48f1b612710b8f2bb1b4ca3b203e1ed6293
> |
> > > aarch64 | target-finalize | NOK |
> http://autobuild.buildroot.net/results/797e736dc81d84e63a9293a7b1b62d7d4ae29194
> |
> > > arc | target-finalize | NOK |
> http://autobuild.buildroot.net/results/dd94cc60c4eb5a102b04db52b0ee2c7417c0c2f5
> |
> > > x86_64 | target-finalize | NOK |
> http://autobuild.buildroot.net/results/8329204dc3737635b92c2fdef224992f3c302f0c
> |
> > > arm | target-finalize | NOK |
> http://autobuild.buildroot.net/results/5ab016529d2ec177f2865ac184d4a91149a649db
> |
> > > aarch64_be | target-finalize | NOK |
> http://autobuild.buildroot.net/results/b8e27bd74c40cbc6f6ed9c5df4f0021af4fda050
> |
> > > mips64el | target-finalize | NOK |
> http://autobuild.buildroot.net/results/a5f6626116e8e721d5f6eb1d0aebf4656b9452f0
> |
> > > arm | target-finalize | NOK |
> http://autobuild.buildroot.net/results/89b5cc38f7b45046417fa20bbd8078646e9c39ef
> |
> > > aarch64 | target-finalize | NOK |
> http://autobuild.buildroot.net/results/a28d07fd7999f1505a346598ea62ac3c212db7a2
> |
> > > arc | target-finalize | NOK |
> http://autobuild.buildroot.net/results/c905171b7a2beb768e23c7b834c50df0764500e1
> |
> >
> > I had a look at those 22 (18+4) failures, and all of them are caused
> either by
> > pysnmp or psycopg2 issues with Python 3.7.0. pysnmp was fixed today
> > (
> https://git.buildroot.org/buildroot/commit/?id=8122a1d85b6cc9f2adcb1243521c04ba4cae0510
> ).
> > So the only package remaining package to fix is psycopg2.
> >
> > Asaf, Yegor, Adam, could one of you take care of fixing psycopg2 soon ?
> >
> > Related to this, I find it a bit annoying that all those issues are
> > detected at the target-finalize step, since package maintainers are not
> > properly notified. Should we move the byte-compile step as the end of
> > each Python package installation, so that if it fails, it fails
> > earlier, and within the context of that package ? Is the
> > byte-compilation process smart enough to skip compiling when a .pyc
> > file already exists and is newer than the matching .py file ? It would
> > be interesting to do a time comparison between doing per-package
> > byte-compilation and one global byte-compilation at the end.
> >
> >
> > > arc | traceroute-2.1.0 | NOK |
> http://autobuild.buildroot.net/results/22855418dcb5bca4b6499991bc810b368a0cfcd5
> |
> >
> > make[3]: *** No rule to make target '-lm', needed by 'traceroute'. Stop.
> > make[3]: *** Waiting for unfinished jobs....
> >
> > Meh ?
> >
> > > powerpc64le | util-linux-2.32.1 | NOK |
> http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b
> |
> >
> >
> > checking for SELINUX... no
> > configure: error: SELinux selected but libselinux not found or too old
> >
> > We've been having this one for a while. Could some SELinux person
> > (Matt ? Adam ?) debug this ?
>
> I can take a look.
I worked on this one without finding how to fix it.
Here is my finding so I hope it could help you.
It seems that the issue is that libselinux is really not built before
util-linux. Indeed, we can see in
http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b/build-time.log,
that only libsepol is built.
I don't know why libselinux is not built perhaps because libselinux,
libsepol and all other selinux packages share the same archive (i.e.
https://raw.githubusercontent.com/wiki/SELinuxProject/selinux/files/releases/20180524
)?
> Before I dig to deep, I'd suggest applying the 2.8
> bump (http://patchwork.ozlabs.org/project/buildroot/list/?series=66983).
> I've finished runtime testing and it would be good to fix this and
> perform my testing on the latest.
>
> Note, this report doesn't have it, but there has been a standing
> host-libsemanage 2.7 failure I've been ignoring until the 2.8 is
> applied. (http://autobuild.buildroot.net/?reason=host-libsemanage-2.7)
>
> Matt
>
Best Regards,
Fabrice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20181010/fc61cf10/attachment-0001.html>
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-10 17:57 ` Fabrice Fontaine
@ 2018-10-10 19:14 ` Thomas Petazzoni
2018-10-10 21:25 ` Matthew Weber
0 siblings, 1 reply; 37+ messages in thread
From: Thomas Petazzoni @ 2018-10-10 19:14 UTC (permalink / raw)
To: buildroot
Hello Fabrice,
On Wed, 10 Oct 2018 19:57:58 +0200, Fabrice Fontaine wrote:
> > > libboost_chrono shouldn't have been installed: missing select in
> > boost/Config.in
> >
> Can be fixed by https://patchwork.ozlabs.org/patch/960723.
OK.
> > > > arm | boost-1.68.0 | NOK |
> > http://autobuild.buildroot.net/results/41054f876975214741dccd08eda999a425281b7f
> > |
> > >
> > > libboost_atomic shouldn't have been installed: missing select in
> > boost/Config.in
> >
> Can be fixed by https://patchwork.ozlabs.org/patch/966309.
> It should be noted that this patch has been merged upstream:
> https://github.com/boostorg/thread/commit/f7581a366294c6f5381e0371c242af327c6da655
OK, I was still not entirely convinced by this one, but if it has been
merged upstream, so be it :-)
> > > checking for SELINUX... no
> > > configure: error: SELinux selected but libselinux not found or too old
> > >
> > > We've been having this one for a while. Could some SELinux person
> > > (Matt ? Adam ?) debug this ?
> >
> > I can take a look.
>
> I worked on this one without finding how to fix it.
> Here is my finding so I hope it could help you.
> It seems that the issue is that libselinux is really not built before
> util-linux. Indeed, we can see in
> http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b/build-time.log,
> that only libsepol is built.
Aah, thanks for this hint. Then it becomes clear what the problem is:
we're facing the util-linux -> python3 -> util-linux circular
dependency. If you look at all the failures at
http://autobuild.buildroot.net/?reason=util-linux-2.32.1, all of them
have BR2_PACKAGE_PYTHON3_UUID=y, and this creates a python3 ->
util-linux dependency. When there is a circular dependency, make
automatically drops a dependency to avoid the circular loop.
We need to resolve this util-linux -> python3 -> util-linux circular
dependency. Arnout suggested that python3 can provide uuid
functionality without libuuid, and I did some tests about this, which I
reported on the mailing list at
http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html.
See the whole thread that starts at
http://lists.busybox.net/pipermail/buildroot/2018-September/229746.html.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-10 19:14 ` Thomas Petazzoni
@ 2018-10-10 21:25 ` Matthew Weber
2018-10-11 6:50 ` Thomas Petazzoni
0 siblings, 1 reply; 37+ messages in thread
From: Matthew Weber @ 2018-10-10 21:25 UTC (permalink / raw)
To: buildroot
Adam,
On Wed, Oct 10, 2018 at 2:14 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Fabrice,
>
> On Wed, 10 Oct 2018 19:57:58 +0200, Fabrice Fontaine wrote:
>
> > > > libboost_chrono shouldn't have been installed: missing select in
> > > boost/Config.in
> > >
> > Can be fixed by https://patchwork.ozlabs.org/patch/960723.
>
> OK.
>
> > > > > arm | boost-1.68.0 | NOK |
> > > http://autobuild.buildroot.net/results/41054f876975214741dccd08eda999a425281b7f
> > > |
> > > >
> > > > libboost_atomic shouldn't have been installed: missing select in
> > > boost/Config.in
> > >
> > Can be fixed by https://patchwork.ozlabs.org/patch/966309.
> > It should be noted that this patch has been merged upstream:
> > https://github.com/boostorg/thread/commit/f7581a366294c6f5381e0371c242af327c6da655
>
> OK, I was still not entirely convinced by this one, but if it has been
> merged upstream, so be it :-)
>
>
> > > > checking for SELINUX... no
> > > > configure: error: SELinux selected but libselinux not found or too old
> > > >
> > > > We've been having this one for a while. Could some SELinux person
> > > > (Matt ? Adam ?) debug this ?
> > >
> > > I can take a look.
> >
> > I worked on this one without finding how to fix it.
> > Here is my finding so I hope it could help you.
> > It seems that the issue is that libselinux is really not built before
> > util-linux. Indeed, we can see in
> > http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b/build-time.log,
> > that only libsepol is built.
>
> Aah, thanks for this hint. Then it becomes clear what the problem is:
> we're facing the util-linux -> python3 -> util-linux circular
> dependency. If you look at all the failures at
> http://autobuild.buildroot.net/?reason=util-linux-2.32.1, all of them
> have BR2_PACKAGE_PYTHON3_UUID=y, and this creates a python3 ->
> util-linux dependency. When there is a circular dependency, make
> automatically drops a dependency to avoid the circular loop.
>
> We need to resolve this util-linux -> python3 -> util-linux circular
> dependency. Arnout suggested that python3 can provide uuid
> functionality without libuuid, and I did some tests about this, which I
> reported on the mailing list at
> http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html.
> See the whole thread that starts at
> http://lists.busybox.net/pipermail/buildroot/2018-September/229746.html.
>
Adam, did you have something in the works for this one? I seem to
remember some discussion on the one "whole" thread above related to
breaking the dependency. I'd make the change but I don't have a valid
test case.
Matt
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-10 21:25 ` Matthew Weber
@ 2018-10-11 6:50 ` Thomas Petazzoni
2018-10-11 13:35 ` Matthew Weber
2018-10-12 3:57 ` Matthew Weber
0 siblings, 2 replies; 37+ messages in thread
From: Thomas Petazzoni @ 2018-10-11 6:50 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 10 Oct 2018 16:25:41 -0500, Matthew Weber wrote:
> Adam, did you have something in the works for this one? I seem to
> remember some discussion on the one "whole" thread above related to
> breaking the dependency. I'd make the change but I don't have a valid
> test case.
Well, Arnout statement was that the build dependency is not necessary
because python3 can dlopen() at runtime the libuuid.so library. Indeed
the code in Python3 is here to do that, but as I explained in
http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html,
it doesn't seem to work, at least in the Buildroot context.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-11 6:50 ` Thomas Petazzoni
@ 2018-10-11 13:35 ` Matthew Weber
2018-10-12 3:57 ` Matthew Weber
1 sibling, 0 replies; 37+ messages in thread
From: Matthew Weber @ 2018-10-11 13:35 UTC (permalink / raw)
To: buildroot
Thomas,
On Thu, Oct 11, 2018 at 1:50 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> On Wed, 10 Oct 2018 16:25:41 -0500, Matthew Weber wrote:
>
> > Adam, did you have something in the works for this one? I seem to
> > remember some discussion on the one "whole" thread above related to
> > breaking the dependency. I'd make the change but I don't have a valid
> > test case.
>
> Well, Arnout statement was that the build dependency is not necessary
> because python3 can dlopen() at runtime the libuuid.so library. Indeed
> the code in Python3 is here to do that, but as I explained in
> http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html,
> it doesn't seem to work, at least in the Buildroot context.
>
I reached out to Adam, this dependency on uuid was added as part of
the python upgrade and not for a specific product need. I'll see if I
can reproduce the python pkg build failure for its uuid support (Adam
mentioned this is why he added the buildroot dependency on util-linux)
. Then depending on that, submit a patch to disable uuid support in
python and remove the dependency we currently have on the util linux
uuid lib.
Matt
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-11 6:50 ` Thomas Petazzoni
2018-10-11 13:35 ` Matthew Weber
@ 2018-10-12 3:57 ` Matthew Weber
2018-10-12 14:16 ` Matthew Weber
1 sibling, 1 reply; 37+ messages in thread
From: Matthew Weber @ 2018-10-12 3:57 UTC (permalink / raw)
To: buildroot
Thomas,
On Thu, Oct 11, 2018 at 1:50 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> On Wed, 10 Oct 2018 16:25:41 -0500, Matthew Weber wrote:
>
> > Adam, did you have something in the works for this one? I seem to
> > remember some discussion on the one "whole" thread above related to
> > breaking the dependency. I'd make the change but I don't have a valid
> > test case.
>
> Well, Arnout statement was that the build dependency is not necessary
> because python3 can dlopen() at runtime the libuuid.so library. Indeed
> the code in Python3 is here to do that, but as I explained in
> http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html,
> it doesn't seem to work, at least in the Buildroot context.
>
I dug through this a bit more and found that the c library is
providing the implementation for uuid.uuid1() when uuid_generate_time*
is probed for in libraries using ctypes. I believe that the
util-linux libuuid would come into play if the extension module
approach worked (all the configure tests currently fail which disable
use of python3-3.7.0/Modules/_uuidmodule.c).
I believe the right fix for now is cleaning up the current approach
(removing the ability to enable/disable uuid and the util-linux
dependency) as it looks like python can support uuid by default with
the current glibc. My guess is we'll see build failures with the
other std libraries....
Matt
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-12 3:57 ` Matthew Weber
@ 2018-10-12 14:16 ` Matthew Weber
2018-10-20 14:10 ` Matthew Weber
0 siblings, 1 reply; 37+ messages in thread
From: Matthew Weber @ 2018-10-12 14:16 UTC (permalink / raw)
To: buildroot
Thomas,
On Thu, Oct 11, 2018 at 10:57 PM Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
>
> Thomas,
>
>
> On Thu, Oct 11, 2018 at 1:50 AM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> >
> > Hello,
> >
> > On Wed, 10 Oct 2018 16:25:41 -0500, Matthew Weber wrote:
> >
> > > Adam, did you have something in the works for this one? I seem to
> > > remember some discussion on the one "whole" thread above related to
> > > breaking the dependency. I'd make the change but I don't have a valid
> > > test case.
> >
> > Well, Arnout statement was that the build dependency is not necessary
> > because python3 can dlopen() at runtime the libuuid.so library. Indeed
> > the code in Python3 is here to do that, but as I explained in
> > http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html,
> > it doesn't seem to work, at least in the Buildroot context.
> >
>
> I dug through this a bit more and found that the c library is
> providing the implementation for uuid.uuid1() when uuid_generate_time*
> is probed for in libraries using ctypes. I believe that the
> util-linux libuuid would come into play if the extension module
> approach worked (all the configure tests currently fail which disable
> use of python3-3.7.0/Modules/_uuidmodule.c).
>
> I believe the right fix for now is cleaning up the current approach
> (removing the ability to enable/disable uuid and the util-linux
> dependency) as it looks like python can support uuid by default with
> the current glibc. My guess is we'll see build failures with the
> other std libraries....
>
http://patchwork.ozlabs.org/patch/983070/
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-12 14:16 ` Matthew Weber
@ 2018-10-20 14:10 ` Matthew Weber
0 siblings, 0 replies; 37+ messages in thread
From: Matthew Weber @ 2018-10-20 14:10 UTC (permalink / raw)
To: buildroot
Thomas, Arnout,
On Fri, Oct 12, 2018 at 3:16 PM Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
>
> Thomas,
>
> On Thu, Oct 11, 2018 at 10:57 PM Matthew Weber
> <matthew.weber@rockwellcollins.com> wrote:
> >
> > Thomas,
> >
> >
> > On Thu, Oct 11, 2018 at 1:50 AM Thomas Petazzoni
> > <thomas.petazzoni@bootlin.com> wrote:
> > >
> > > Hello,
> > >
> > > On Wed, 10 Oct 2018 16:25:41 -0500, Matthew Weber wrote:
> > >
> > > > Adam, did you have something in the works for this one? I seem to
> > > > remember some discussion on the one "whole" thread above related to
> > > > breaking the dependency. I'd make the change but I don't have a valid
> > > > test case.
> > >
> > > Well, Arnout statement was that the build dependency is not necessary
> > > because python3 can dlopen() at runtime the libuuid.so library. Indeed
> > > the code in Python3 is here to do that, but as I explained in
> > > http://lists.busybox.net/pipermail/buildroot/2018-September/231060.html,
> > > it doesn't seem to work, at least in the Buildroot context.
> > >
> >
> > I dug through this a bit more and found that the c library is
> > providing the implementation for uuid.uuid1() when uuid_generate_time*
> > is probed for in libraries using ctypes. I believe that the
> > util-linux libuuid would come into play if the extension module
> > approach worked (all the configure tests currently fail which disable
> > use of python3-3.7.0/Modules/_uuidmodule.c).
> >
> > I believe the right fix for now is cleaning up the current approach
> > (removing the ability to enable/disable uuid and the util-linux
> > dependency) as it looks like python can support uuid by default with
> > the current glibc. My guess is we'll see build failures with the
> > other std libraries....
> >
>
> http://patchwork.ozlabs.org/patch/983070/
Here's v3 Arnout and I reviewed this morning. v2 -> v3 improved the
commit description
https://patchwork.ozlabs.org/patch/987192/
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-10 16:28 ` Matthew Weber
2018-10-10 17:57 ` Fabrice Fontaine
@ 2018-10-10 19:05 ` Thomas Petazzoni
2018-10-12 16:00 ` Matthew Weber
2 siblings, 0 replies; 37+ messages in thread
From: Thomas Petazzoni @ 2018-10-10 19:05 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 10 Oct 2018 11:28:39 -0500, Matthew Weber wrote:
> > > powerpc64le | util-linux-2.32.1 | NOK | http://autobuild.buildroot.net/results/7b79a5fa265e2387cab421e42b3c946562e4781b |
> >
> >
> > checking for SELINUX... no
> > configure: error: SELinux selected but libselinux not found or too old
> >
> > We've been having this one for a while. Could some SELinux person
> > (Matt ? Adam ?) debug this ?
>
> I can take a look. Before I dig to deep, I'd suggest applying the 2.8
> bump (http://patchwork.ozlabs.org/project/buildroot/list/?series=66983).
> I've finished runtime testing and it would be good to fix this and
> perform my testing on the latest.
I will have a look at this series and merge it. I was waiting for you
to test it, but it's indeed done since September 28, so it's time to
merge the series.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-10 16:28 ` Matthew Weber
2018-10-10 17:57 ` Fabrice Fontaine
2018-10-10 19:05 ` Thomas Petazzoni
@ 2018-10-12 16:00 ` Matthew Weber
2 siblings, 0 replies; 37+ messages in thread
From: Matthew Weber @ 2018-10-12 16:00 UTC (permalink / raw)
To: buildroot
Thomas,
On Wed, Oct 10, 2018 at 11:28 AM Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
>
> Thomas,
>
>
> On Wed, Oct 10, 2018 at 10:48 AM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> >
> > Hello,
> >
> > Here is an analysis of yesterday build results. Johan, Frank,
> > Christian, Fabrice, Peter, Matt, Bernd, Giulio, Baruch, you are in Cc
> > because there are questions/issues for you below. Thanks! :-)
> >
> > On Wed, 10 Oct 2018 08:00:10 +0200 (CEST), Thomas Petazzoni wrote:
> >
> > > master | 187 | 68 | 0 | 255 |
> >
> > These results are not very good, let's have a look at what's going on,
> > and try to get everyone to help fixing those issues.
> >
> > > arm | boa-0.94.14rc21 | NOK | http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11 | ORPH
> >
> > (cd src && make - --no-print-directory - --jobserver-fds=6,7 -j)
> > make: unrecognized option '--jobserver-fds=6,7'
> >
> > This suddenly started happening on September 9, 2018. We have not
> > bumped boa. I'm not sure what caused this. It fails on different
> > autobuilder machines. Boa is calling submake with $(MFLAGS), which is
> > probably the issue, but why did this suddenly started to happen ?
> >
> > With a minimal configuration with just Boa, I cannot reproduce on my
> > machine here, neither on my autobuilder where the problem is reported
> > to occur.
> >
> > > i686 | boost-1.68.0 | NOK | http://autobuild.buildroot.net/results/1ceed7d91627711c12c4866fa6672a02fc6ddc8c |
> >
> > libboost_chrono shouldn't have been installed: missing select in boost/Config.in
> >
> > > arm | boost-1.68.0 | NOK | http://autobuild.buildroot.net/results/41054f876975214741dccd08eda999a425281b7f |
> >
> > libboost_atomic shouldn't have been installed: missing select in boost/Config.in
> >
> > Fabrice, these two are for you :)
> >
> > > mips64el | brltty-5.6 | NOK | http://autobuild.buildroot.net/results/7187e560e66f2bd6073b5510e2782ebdaccfb4a9 |
> > > mips64el | brltty-5.6 | NOK | http://autobuild.buildroot.net/results/5f8e8b8517fda50a2e98a456933260f08054356d |
> >
> > Those should be fixed by
> > https://git.buildroot.org/buildroot/commit/?id=9143c217213542574586c0e6a9f003e822633917.
> >
> > > aarch64 | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/24a280d6233b3284edd44c4528d8799c6894c11a | ORPH
> > > sh4 | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/63a4f980d7cdb4b0823840f747589803fcd0d69f | ORPH
> > > arc | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/1a6f2fcf1a88ecc5b598dd11c5914dcacf0e1e6b | ORPH
> > > arm | collectd-5.7.1 | NOK | http://autobuild.buildroot.net/results/b0829bc3343d6dc3065078e94896725b1c808bc1 | ORPH
> >
> > Fixed by
> > https://git.buildroot.org/buildroot/commit/package/collectd?id=d65ea85fddaf64a7762f958d1ce9fb33997648d3
> >
> > > x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/6c26ac3a8aa39abcb5eb390109891790610a759b |
> > > x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/10654bccc3d20ec6d29d371c48dd90cbddb8c4da |
> > > x86_64 | docker-containerd-v1.1.3 | NOK | http://autobuild.buildroot.net/results/56b564a27a06792c4854fe983da92d40c0c4708c |
> >
> > /home/naourr/work/instance-3/output/host/lib/go/pkg/tool/linux_amd64/link: running /home/naourr/work/instance-3/output/host/bin/x86_64-amd-linux-gnu-gcc failed: exit status 1
> > /tmp/go-build283204336/b001/exe/a.out: final close failed: Invalid operation
> >
> > Christian, what is happening here? Could you have a look?
> >
> > > x86_64 | erlang-21.0 | NOK | http://autobuild.buildroot.net/results/fc633f80c7c36a90e641487f5a888fbb767c2a54 |
> >
> > In file included from zlib/adler32.c:11:0:
> > zlib/zutil.h:172:39: error: "_LFS64_LARGEFILE" is not defined [-Werror=undef]
> > (!defined(_LARGEFILE64_SOURCE) || _LFS64_LARGEFILE-0 == 0)
> >
> > Seems like a musl/erlang issue. Johan, Frank, could you have a look ?
> >
> > > arc | glibc-legal-info | NOK | http://autobuild.buildroot.net/results/64c70d82c857c272df171ae6783629c1ba92d812 | ORPH
> >
> > Fixed by
> > https://git.buildroot.org/buildroot/commit/?id=b14ad0bd697038e4cf48ecf48830fb3369f1f25e.
> >
> > > mips64el | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/c00d22a6dcadb82a19afab6eacea654d3c41b4c5 | ORPH
> > > powerpc | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/18599ea12a35b9715a67c1f4e5c4e56906235c94 | ORPH
> > > arm | gpsd-3.18 | NOK | http://autobuild.buildroot.net/results/a13a5d852c83cd1fc9f2d1fc2b7302db515278b8 | ORPH
> >
> > Fixed by https://git.buildroot.org/buildroot/commit/package/gpsd?id=ae2a91322aeaa72d6f5354312056d16dc275470d
> >
> > > mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
> >
> >
> > gstspanplc.c:223:21: error: dereferencing pointer to incomplete type 'plc_state_t {aka struct plc_state_s}'
> > if (plc->plc_state->missing_samples != 0)
> >
> > Peter (Seiderer) ?
> >
> > > arm | host-go-1.11 | NOK | http://autobuild.buildroot.net/results/8d3af6f00bf34737faabc21bdccf7d025462fec7 |
> >
> > fatal error: unexpected signal during runtime execution
> > [signal SIGBUS: bus error code=0x2 addr=0xc000800010 pc=0x42098d]
> >
> > This particular issue seems to happen only on Matt autobuilder. Matt,
> > can you check if you can reproduce it reliably ?
Looks like known issue with kernel version 3.13. I'll see what I can
do about upgrading the kernel version or locally blacklist GO for now.
I've opened a new ticket to help them tie-off a theory they had about
the 3.13 that this confirms.
https://github.com/golang/go/issues/28180
Matt
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-10 15:48 ` [Buildroot] Analysis " Thomas Petazzoni
2018-10-10 16:28 ` Matthew Weber
@ 2018-10-10 21:30 ` Arnout Vandecappelle
2018-10-11 6:46 ` Thomas Petazzoni
2018-10-11 9:21 ` Peter Korsgaard
2018-10-10 21:35 ` Arnout Vandecappelle
` (6 subsequent siblings)
8 siblings, 2 replies; 37+ messages in thread
From: Arnout Vandecappelle @ 2018-10-10 21:30 UTC (permalink / raw)
To: buildroot
On 10/10/18 17:48, Thomas Petazzoni wrote:
>> mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
>
> gstspanplc.c:223:21: error: dereferencing pointer to incomplete type 'plc_state_t {aka struct plc_state_s}'
> if (plc->plc_state->missing_samples != 0)
Perhaps it's time to retire gstreamer-0.10? Is anybody still using it?
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-10 21:30 ` Arnout Vandecappelle
@ 2018-10-11 6:46 ` Thomas Petazzoni
2018-10-11 9:21 ` Peter Korsgaard
1 sibling, 0 replies; 37+ messages in thread
From: Thomas Petazzoni @ 2018-10-11 6:46 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 10 Oct 2018 23:30:39 +0200, Arnout Vandecappelle wrote:
> On 10/10/18 17:48, Thomas Petazzoni wrote:
> >> mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
> >
> > gstspanplc.c:223:21: error: dereferencing pointer to incomplete type 'plc_state_t {aka struct plc_state_s}'
> > if (plc->plc_state->missing_samples != 0)
>
> Perhaps it's time to retire gstreamer-0.10? Is anybody still using it?
I am certainly OK to retire gstreamer-0.10. Could someone send a patch
series doing this ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-10 21:30 ` Arnout Vandecappelle
2018-10-11 6:46 ` Thomas Petazzoni
@ 2018-10-11 9:21 ` Peter Korsgaard
2018-10-11 21:32 ` Arnout Vandecappelle
1 sibling, 1 reply; 37+ messages in thread
From: Peter Korsgaard @ 2018-10-11 9:21 UTC (permalink / raw)
To: buildroot
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
> On 10/10/18 17:48, Thomas Petazzoni wrote:
>>> mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
>>
>> gstspanplc.c:223:21: error: dereferencing pointer to incomplete type 'plc_state_t {aka struct plc_state_s}'
>> if (plc->plc_state->missing_samples != 0)
> Perhaps it's time to retire gstreamer-0.10? Is anybody still using it?
Agreed, 1.0 is from 2012 and 0.10.x is no longer maintained upstream.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-11 9:21 ` Peter Korsgaard
@ 2018-10-11 21:32 ` Arnout Vandecappelle
0 siblings, 0 replies; 37+ messages in thread
From: Arnout Vandecappelle @ 2018-10-11 21:32 UTC (permalink / raw)
To: buildroot
On 11/10/18 11:21, Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
>
> > On 10/10/18 17:48, Thomas Petazzoni wrote:
> >>> mips64el | gst-plugins-bad-0.10.23 | NOK | http://autobuild.buildroot.net/results/ab39280ceaf967e08abfd1f51efa4613495237f5 | ORPH
> >>
> >> gstspanplc.c:223:21: error: dereferencing pointer to incomplete type 'plc_state_t {aka struct plc_state_s}'
> >> if (plc->plc_state->missing_samples != 0)
>
> > Perhaps it's time to retire gstreamer-0.10? Is anybody still using it?
>
> Agreed, 1.0 is from 2012 and 0.10.x is no longer maintained upstream.
Note that qt4, nvidia-tegra23 and classpath only support GST 0.10. Those were
the only ones I could find. Of these, only qt4 is still a bit relevant I think.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-10 15:48 ` [Buildroot] Analysis " Thomas Petazzoni
2018-10-10 16:28 ` Matthew Weber
2018-10-10 21:30 ` Arnout Vandecappelle
@ 2018-10-10 21:35 ` Arnout Vandecappelle
2018-10-12 6:54 ` Jörg Krause
2018-10-10 21:52 ` Christian Stewart
` (5 subsequent siblings)
8 siblings, 1 reply; 37+ messages in thread
From: Arnout Vandecappelle @ 2018-10-10 21:35 UTC (permalink / raw)
To: buildroot
On 10/10/18 17:48, Thomas Petazzoni wrote:
>> arm | luvi-v2.8.0 | NOK | http://autobuild.buildroot.net/results/2bdbb93e6404943e59791773106d8b2680211886 |
> luvi 2.8.0 fails to build. Bernd, you bumped this package, and J?rg
> suggested to revert the bump. Could you discuss this, and provide a fix?
>
I think luv is missing a dependency on lua-compat53.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-10 21:35 ` Arnout Vandecappelle
@ 2018-10-12 6:54 ` Jörg Krause
0 siblings, 0 replies; 37+ messages in thread
From: Jörg Krause @ 2018-10-12 6:54 UTC (permalink / raw)
To: buildroot
Hi,
On Wed, 2018-10-10 at 23:35 +0200, Arnout Vandecappelle wrote:
>
> On 10/10/18 17:48, Thomas Petazzoni wrote:
> > > arm | luvi-v2.8.0 | NOK | http://autobuild.buildroot.net/results/2bdbb93e6404943e59791773106d8b2680211886 |
> > luvi 2.8.0 fails to build. Bernd, you bumped this package, and J?rg
> > suggested to revert the bump. Could you discuss this, and provide a fix?
> >
>
> I think luv is missing a dependency on lua-compat53.
That's right! Unfortunately, it does not fix the build issue for luvi
as lua-compat53 does not install the required header file c-api/compat-
5.3.h at all.
So, lua-compat53 needs to be fixed first to install the header file and
luv needs an optional dependency on lua-compat53 if
!BR2_PACKAGE_LUA_5_3.
Best regards,
J?rg Krause
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-10 15:48 ` [Buildroot] Analysis " Thomas Petazzoni
` (2 preceding siblings ...)
2018-10-10 21:35 ` Arnout Vandecappelle
@ 2018-10-10 21:52 ` Christian Stewart
2018-10-10 21:54 ` Arnout Vandecappelle
` (4 subsequent siblings)
8 siblings, 0 replies; 37+ messages in thread
From: Christian Stewart @ 2018-10-10 21:52 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Wed, Oct 10, 2018 at 8:48 AM Thomas Petazzoni <
thomas.petazzoni@bootlin.com> wrote:
> > x86_64 | docker-containerd-v1.1.3 | NOK |
> http://autobuild.buildroot.net/results/6c26ac3a8aa39abcb5eb390109891790610a759b
> |
> > x86_64 | docker-containerd-v1.1.3 | NOK |
> http://autobuild.buildroot.net/results/10654bccc3d20ec6d29d371c48dd90cbddb8c4da
> |
> > x86_64 | docker-containerd-v1.1.3 | NOK |
> http://autobuild.buildroot.net/results/56b564a27a06792c4854fe983da92d40c0c4708c
> |
>
> /home/naourr/work/instance-3/output/host/lib/go/pkg/tool/linux_amd64/link:
> running
> /home/naourr/work/instance-3/output/host/bin/x86_64-amd-linux-gnu-gcc
> failed: exit status 1
> /tmp/go-build283204336/b001/exe/a.out: final close failed: Invalid
> operation
>
> Christian, what is happening here? Could you have a look?
>
Geoff Levand and I started having a look at this breakage some time ago but
did not find an immediate fix. It's a very obscure error, but I did manage
to find some non-go references:
- https://lists.gnu.org/archive/html/bug-binutils/2016-04/msg00221.html
- https://sourceware.org/bugzilla/show_bug.cgi?id=20006
- http://lists.busybox.net/pipermail/buildroot/2017-August/200570.html
Buildroot Ruby bug # 20006 seems similar.
This is what we have so far on fixing this.
Best,
~ Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20181010/8857cfc6/attachment-0001.html>
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-10 15:48 ` [Buildroot] Analysis " Thomas Petazzoni
` (3 preceding siblings ...)
2018-10-10 21:52 ` Christian Stewart
@ 2018-10-10 21:54 ` Arnout Vandecappelle
2018-10-11 4:43 ` Baruch Siach
` (3 subsequent siblings)
8 siblings, 0 replies; 37+ messages in thread
From: Arnout Vandecappelle @ 2018-10-10 21:54 UTC (permalink / raw)
To: buildroot
On 10/10/18 17:48, Thomas Petazzoni wrote:
>> arm | php-7.2.10 | NOK | http://autobuild.buildroot.net/results/7b7e25bfd269f7c252d15ab4e9f1b68348823478 | ORPH
> multiple definition of `icu_60::MessageFormatAdapter::getArgTypeList(icu_60::MessageFormat const&, int&)'
>
> Long standing issue. Anyone brave enough to investigate ?
Maybe just make php !STATIC?
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-10 15:48 ` [Buildroot] Analysis " Thomas Petazzoni
` (4 preceding siblings ...)
2018-10-10 21:54 ` Arnout Vandecappelle
@ 2018-10-11 4:43 ` Baruch Siach
2018-10-11 6:53 ` Thomas Petazzoni
` (2 more replies)
2018-10-11 11:02 ` Giulio Benetti
` (2 subsequent siblings)
8 siblings, 3 replies; 37+ messages in thread
From: Baruch Siach @ 2018-10-11 4:43 UTC (permalink / raw)
To: buildroot
Thomas Petazzoni writes:
>> arm | boa-0.94.14rc21 | NOK | http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11 | ORPH
>
> (cd src && make - --no-print-directory - --jobserver-fds=6,7 -j)
> make: unrecognized option '--jobserver-fds=6,7'
>
> This suddenly started happening on September 9, 2018. We have not
> bumped boa. I'm not sure what caused this. It fails on different
> autobuilder machines. Boa is calling submake with $(MFLAGS), which is
> probably the issue, but why did this suddenly started to happen ?
>
> With a minimal configuration with just Boa, I cannot reproduce on my
> machine here, neither on my autobuilder where the problem is reported
> to occur.
I guess it is related to commit 05167a9ffa (package/make: add host
variant) which was applied on September 8, 23:36. Build seems to fail
only on hosts with make older than 4.0, so the host-make build is
triggered.
>> powerpc | squid-4.2 | NOK | http://autobuild.buildroot.net/results/e679ef90219c5e8f9c94ddcd7d3f9582f79ef751 | ORPH
>
> ../../src/StatHist.h:112:30: error: invalid pure specifier (only '= 0' is allowed) before ';' token
> ../../src/StatHist.h:113:31: error: invalid pure specifier (only '= 0' is allowed) before ';' token
>
> Not sure. Baruch, you recently bumped the squid package, could you have
> a look ?
This failure is from before my patch bumping squid to 4.3 (commit
419c47a2135). But I believe we'll see the same failure with 4.3.
The build only fails with the CT-NG PowerPC e500 toolchain. Is that the
only gcc 4.7 toolchain?
This is the failing code:
typedef double hbase_f(double);
class StatHist
{
...
hbase_f *val_in = nullptr; /* e.g., log() for log-based histogram */
hbase_f *val_out = nullptr; /* e.g., exp() for log based histogram */
}
For some reason this version of gcc considers val_in/val_out as
methods. But "fixing" the problem by changing the assignment to '= 0'
makes gcc segfault, not even ICE. So I think this is a compiler
bug. Should squid depend on gcc >= 4.8?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-11 4:43 ` Baruch Siach
@ 2018-10-11 6:53 ` Thomas Petazzoni
2018-10-11 9:48 ` Peter Korsgaard
2018-10-11 8:39 ` Thomas Petazzoni
2018-10-11 10:42 ` Peter Korsgaard
2 siblings, 1 reply; 37+ messages in thread
From: Thomas Petazzoni @ 2018-10-11 6:53 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 11 Oct 2018 07:43:32 +0300, Baruch Siach wrote:
> Thomas Petazzoni writes:
> >> arm | boa-0.94.14rc21 | NOK | http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11 | ORPH
> >
> > (cd src && make - --no-print-directory - --jobserver-fds=6,7 -j)
> > make: unrecognized option '--jobserver-fds=6,7'
> >
> > This suddenly started happening on September 9, 2018. We have not
> > bumped boa. I'm not sure what caused this. It fails on different
> > autobuilder machines. Boa is calling submake with $(MFLAGS), which is
> > probably the issue, but why did this suddenly started to happen ?
> >
> > With a minimal configuration with just Boa, I cannot reproduce on my
> > machine here, neither on my autobuilder where the problem is reported
> > to occur.
>
> I guess it is related to commit 05167a9ffa (package/make: add host
> variant) which was applied on September 8, 23:36. Build seems to fail
> only on hosts with make older than 4.0, so the host-make build is
> triggered.
Yes, I figured that out after sending my summary. I reproduced the
issue on my build server, which has an old make installed system-wide,
and this issue seems to appear only when host-make is built prior to
boa. There's a mixup of make being used, with a new "make" used at the
top-level, passing options unknown to the old "make" used at the
lower-level.
> This failure is from before my patch bumping squid to 4.3 (commit
> 419c47a2135). But I believe we'll see the same failure with 4.3.
>
> The build only fails with the CT-NG PowerPC e500 toolchain. Is that the
> only gcc 4.7 toolchain?
>
> This is the failing code:
>
> typedef double hbase_f(double);
>
> class StatHist
> {
> ...
> hbase_f *val_in = nullptr; /* e.g., log() for log-based histogram */
> hbase_f *val_out = nullptr; /* e.g., exp() for log based histogram */
> }
>
> For some reason this version of gcc considers val_in/val_out as
> methods. But "fixing" the problem by changing the assignment to '= 0'
> makes gcc segfault, not even ICE. So I think this is a compiler
> bug. Should squid depend on gcc >= 4.8?
It would be nice to find an actual gcc bug report for this. I very much
prefer to document such issues using BR2_TOOLCHAIN_HAS_GCC_BUG_xyz
dependencies rather than semi-random gcc version dependencies.
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-11 6:53 ` Thomas Petazzoni
@ 2018-10-11 9:48 ` Peter Korsgaard
2018-10-11 14:12 ` Thomas Petazzoni
0 siblings, 1 reply; 37+ messages in thread
From: Peter Korsgaard @ 2018-10-11 9:48 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:
> Hello,
> On Thu, 11 Oct 2018 07:43:32 +0300, Baruch Siach wrote:
>> Thomas Petazzoni writes:
>> >> arm | boa-0.94.14rc21 | NOK |
>> > http://autobuild.buildroot.net/results/e5ff4589243ce1f11248b5f9fab3cca614a48b11
>> > | ORPH
>> >
>> > (cd src && make - --no-print-directory - --jobserver-fds=6,7 -j)
>> > make: unrecognized option '--jobserver-fds=6,7'
>> >
>> > This suddenly started happening on September 9, 2018. We have not
>> > bumped boa. I'm not sure what caused this. It fails on different
>> > autobuilder machines. Boa is calling submake with $(MFLAGS), which is
>> > probably the issue, but why did this suddenly started to happen ?
>> >
>> > With a minimal configuration with just Boa, I cannot reproduce on my
>> > machine here, neither on my autobuilder where the problem is reported
>> > to occur.
>>
>> I guess it is related to commit 05167a9ffa (package/make: add host
>> variant) which was applied on September 8, 23:36. Build seems to fail
>> only on hosts with make older than 4.0, so the host-make build is
>> triggered.
> Yes, I figured that out after sending my summary. I reproduced the
> issue on my build server, which has an old make installed system-wide,
> and this issue seems to appear only when host-make is built prior to
> boa. There's a mixup of make being used, with a new "make" used at the
> top-level, passing options unknown to the old "make" used at the
> lower-level.
Ahh, yes. It looks to be the other way around though:
usr/bin/make -j6 -C /home/peko/autobuild/instance-0/output/build/boa-0.94.14rc21/
make[1]: Entering directory `/home/peko/autobuild/instance-0/output/build/boa-0.94.14rc21'
(cd src && make -w --jobserver-fds=5,6 -j)
make: unrecognized option '--jobserver-fds=5,6'
So the issue is that we expand the path to make on the host in
package/Makefile.in:HOSTMAKE but then host-make installs make into the
path and build systems just calling make instead of looking at the MAKE
variable (which boa does because of its gnumake check) ends up with
host-make rather than the system one.
A quick fix would be to set BOA_MAKE to $(BR2_MAKE), but that is a bit
of a hack.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-11 9:48 ` Peter Korsgaard
@ 2018-10-11 14:12 ` Thomas Petazzoni
2018-10-11 15:25 ` Peter Korsgaard
0 siblings, 1 reply; 37+ messages in thread
From: Thomas Petazzoni @ 2018-10-11 14:12 UTC (permalink / raw)
To: buildroot
Hello,
+Romain Naour in Cc, since he added host-make to fix the glibc build.
On Thu, 11 Oct 2018 11:48:22 +0200, Peter Korsgaard wrote:
> > Yes, I figured that out after sending my summary. I reproduced the
> > issue on my build server, which has an old make installed system-wide,
> > and this issue seems to appear only when host-make is built prior to
> > boa. There's a mixup of make being used, with a new "make" used at the
> > top-level, passing options unknown to the old "make" used at the
> > lower-level.
>
> Ahh, yes. It looks to be the other way around though:
Yeah, maybe, I didn't look closely, and I assumed the old version of
make is the one that didn't support the --jobserver-fds option.
Apparently, it's the opposite.
> usr/bin/make -j6 -C /home/peko/autobuild/instance-0/output/build/boa-0.94.14rc21/
> make[1]: Entering directory `/home/peko/autobuild/instance-0/output/build/boa-0.94.14rc21'
> (cd src && make -w --jobserver-fds=5,6 -j)
> make: unrecognized option '--jobserver-fds=5,6'
>
> So the issue is that we expand the path to make on the host in
> package/Makefile.in:HOSTMAKE but then host-make installs make into the
> path and build systems just calling make instead of looking at the MAKE
> variable (which boa does because of its gnumake check) ends up with
> host-make rather than the system one.
>
> A quick fix would be to set BOA_MAKE to $(BR2_MAKE), but that is a bit
> of a hack.
Perhaps we need to think about a more global solution. How do we want
to use host-make ? If it's compiled, should it be used to build all
packages ? Should it only be used for glibc ? In the latter case, how
do we "hide" it from all packages, and make it used only by glibc ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-11 14:12 ` Thomas Petazzoni
@ 2018-10-11 15:25 ` Peter Korsgaard
0 siblings, 0 replies; 37+ messages in thread
From: Peter Korsgaard @ 2018-10-11 15:25 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:
Hi,
>> A quick fix would be to set BOA_MAKE to $(BR2_MAKE), but that is a bit
>> of a hack.
> Perhaps we need to think about a more global solution. How do we want
> to use host-make ? If it's compiled, should it be used to build all
> packages ? Should it only be used for glibc ? In the latter case, how
> do we "hide" it from all packages, and make it used only by glibc ?
Using it for everything is probably the simplest solution / most similar
to other tools.
If we only use it for glibc (for now), then we need to install it as
something else than 'make' (glibc-make? make-4?).
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-11 4:43 ` Baruch Siach
2018-10-11 6:53 ` Thomas Petazzoni
@ 2018-10-11 8:39 ` Thomas Petazzoni
2018-10-11 10:42 ` Peter Korsgaard
2 siblings, 0 replies; 37+ messages in thread
From: Thomas Petazzoni @ 2018-10-11 8:39 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 11 Oct 2018 07:43:32 +0300, Baruch Siach wrote:
> The build only fails with the CT-NG PowerPC e500 toolchain. Is that the
> only gcc 4.7 toolchain?
>
> This is the failing code:
>
> typedef double hbase_f(double);
>
> class StatHist
> {
> ...
> hbase_f *val_in = nullptr; /* e.g., log() for log-based histogram */
> hbase_f *val_out = nullptr; /* e.g., exp() for log based histogram */
> }
>
> For some reason this version of gcc considers val_in/val_out as
> methods.
They are function pointers, since hbase_f is a typedef of a function
that takes a double as argument and returns a double.
Indeed, the following minimal program:
typedef double hbase_f(double);
class StatHist
{
hbase_f *val_in = nullptr;
};
fails to build with gcc 4.7, but builds fine with a more recent gcc. It
would be good to find another gcc 4.7 toolchain to see if the same
problem occurs.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-11 4:43 ` Baruch Siach
2018-10-11 6:53 ` Thomas Petazzoni
2018-10-11 8:39 ` Thomas Petazzoni
@ 2018-10-11 10:42 ` Peter Korsgaard
2018-10-11 11:08 ` Baruch Siach
2 siblings, 1 reply; 37+ messages in thread
From: Peter Korsgaard @ 2018-10-11 10:42 UTC (permalink / raw)
To: buildroot
>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
Hi,
>>> powerpc | squid-4.2 | NOK |
>>> http://autobuild.buildroot.net/results/e679ef90219c5e8f9c94ddcd7d3f9582f79ef751
>>> | ORPH
>>
>> ../../src/StatHist.h:112:30: error: invalid pure specifier (only '= 0' is allowed) before ';' token
>> ../../src/StatHist.h:113:31: error: invalid pure specifier (only '= 0' is allowed) before ';' token
>>
>> Not sure. Baruch, you recently bumped the squid package, could you have
>> a look ?
> This failure is from before my patch bumping squid to 4.3 (commit
> 419c47a2135). But I believe we'll see the same failure with 4.3.
> The build only fails with the CT-NG PowerPC e500 toolchain. Is that the
> only gcc 4.7 toolchain?
> This is the failing code:
> typedef double hbase_f(double);
Isn't there a * missing if this is a function pointer?
E.G.:
typedef double (*hbase_f)(double);
Unless this is something special in C++? Testing that on a 4.7.2
toolchain:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
g++ -std=c++11 -c t.cpp
t.cpp:5:27: error: invalid pure specifier (only ?= 0? is allowed) before ?;? token
g++ -std=c++11 -c t2.cpp
diff -u t.cpp t2.cpp
--- t.cpp 2018-10-11 12:35:32.122441311 +0200
+++ t2.cpp 2018-10-11 12:35:53.786261260 +0200
@@ -1,4 +1,4 @@
-typedef double hbase_f(double);
+typedef double (*hbase_f)(double);
class StatHist
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-11 10:42 ` Peter Korsgaard
@ 2018-10-11 11:08 ` Baruch Siach
2018-10-11 11:18 ` Peter Korsgaard
0 siblings, 1 reply; 37+ messages in thread
From: Baruch Siach @ 2018-10-11 11:08 UTC (permalink / raw)
To: buildroot
Hi Peter,
Peter Korsgaard writes:
>>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
> >>> powerpc | squid-4.2 | NOK |
> >>> http://autobuild.buildroot.net/results/e679ef90219c5e8f9c94ddcd7d3f9582f79ef751
> >>> | ORPH
> >>
> >> ../../src/StatHist.h:112:30: error: invalid pure specifier (only '= 0' is allowed) before ';' token
> >> ../../src/StatHist.h:113:31: error: invalid pure specifier (only '= 0' is allowed) before ';' token
> >>
> >> Not sure. Baruch, you recently bumped the squid package, could you have
> >> a look ?
>
> > This failure is from before my patch bumping squid to 4.3 (commit
> > 419c47a2135). But I believe we'll see the same failure with 4.3.
>
> > The build only fails with the CT-NG PowerPC e500 toolchain. Is that the
> > only gcc 4.7 toolchain?
>
> > This is the failing code:
>
> > typedef double hbase_f(double);
>
> Isn't there a * missing if this is a function pointer?
>
> E.G.:
>
> typedef double (*hbase_f)(double);
>
> Unless this is something special in C++? Testing that on a 4.7.2
> toolchain:
>
> g++ -v
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.7.2 (Debian 4.7.2-5)
>
> g++ -std=c++11 -c t.cpp
> t.cpp:5:27: error: invalid pure specifier (only ?= 0? is allowed) before ?;? token
> g++ -std=c++11 -c t2.cpp
> diff -u t.cpp t2.cpp
> --- t.cpp 2018-10-11 12:35:32.122441311 +0200
> +++ t2.cpp 2018-10-11 12:35:53.786261260 +0200
> @@ -1,4 +1,4 @@
> -typedef double hbase_f(double);
> +typedef double (*hbase_f)(double);
Wouldn't that make the definition 'hbase_f *val_in' a pointer to
function pointer?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-11 11:08 ` Baruch Siach
@ 2018-10-11 11:18 ` Peter Korsgaard
2018-10-11 11:45 ` Baruch Siach
0 siblings, 1 reply; 37+ messages in thread
From: Peter Korsgaard @ 2018-10-11 11:18 UTC (permalink / raw)
To: buildroot
>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
Hi,
>> -typedef double hbase_f(double);
>> +typedef double (*hbase_f)(double);
> Wouldn't that make the definition 'hbase_f *val_in' a pointer to
> function pointer?
Not in C at least. The syntax is:
typedef <returntype> (*name)(<arguments>)
https://stackoverflow.com/questions/1591361/understanding-typedefs-for-function-pointers-in-c
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-11 11:18 ` Peter Korsgaard
@ 2018-10-11 11:45 ` Baruch Siach
2018-10-11 12:46 ` Peter Korsgaard
0 siblings, 1 reply; 37+ messages in thread
From: Baruch Siach @ 2018-10-11 11:45 UTC (permalink / raw)
To: buildroot
Hi Peter,
Peter Korsgaard writes:
>>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
> >> -typedef double hbase_f(double);
> >> +typedef double (*hbase_f)(double);
>
> > Wouldn't that make the definition 'hbase_f *val_in' a pointer to
> > function pointer?
>
> Not in C at least. The syntax is:
>
> typedef <returntype> (*name)(<arguments>)
>
> https://stackoverflow.com/questions/1591361/understanding-typedefs-for-function-pointers-in-c
Correct. But consider the SO example code:
typedef void (*SignalHandler)(int signum);
extern SignalHandler signal(int signum, SignalHandler handler);
The 'handler' parameter of the signal() function is a pointer to a
function. However the definition
SignalHandler *handler;
would create a pointer to a pointer. As I understand, this is not the
intention of the 'hbase_f *val_in' definition in the original code.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-11 11:45 ` Baruch Siach
@ 2018-10-11 12:46 ` Peter Korsgaard
0 siblings, 0 replies; 37+ messages in thread
From: Peter Korsgaard @ 2018-10-11 12:46 UTC (permalink / raw)
To: buildroot
>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
> Hi Peter,
> Peter Korsgaard writes:
>>>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
>> >> -typedef double hbase_f(double);
>> >> +typedef double (*hbase_f)(double);
>>
>> > Wouldn't that make the definition 'hbase_f *val_in' a pointer to
>> > function pointer?
>>
>> Not in C at least. The syntax is:
>>
>> typedef <returntype> (*name)(<arguments>)
>>
>> https://stackoverflow.com/questions/1591361/understanding-typedefs-for-function-pointers-in-c
> Correct. But consider the SO example code:
> typedef void (*SignalHandler)(int signum);
> extern SignalHandler signal(int signum, SignalHandler handler);
> The 'handler' parameter of the signal() function is a pointer to a
> function. However the definition
> SignalHandler *handler;
> would create a pointer to a pointer. As I understand, this is not the
> intention of the 'hbase_f *val_in' definition in the original code.
Ehh, yes - But I was talking about the typedef line (as quoted
above). The * is needed for typedef but not for the val_in definition.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-10 15:48 ` [Buildroot] Analysis " Thomas Petazzoni
` (5 preceding siblings ...)
2018-10-11 4:43 ` Baruch Siach
@ 2018-10-11 11:02 ` Giulio Benetti
2018-10-20 15:22 ` Giulio Benetti
2018-10-11 14:31 ` Frank Hunleth
2018-10-11 19:24 ` Giulio Benetti
8 siblings, 1 reply; 37+ messages in thread
From: Giulio Benetti @ 2018-10-11 11:02 UTC (permalink / raw)
To: buildroot
Hello everybody,
Il 10/10/2018 17:48, Thomas Petazzoni ha scritto:
>> powerpc | motion-release-4.1.1 | NOK | http://autobuild.buildroot.net/results/78061b61cfe3f42554a475c048d54dacacfe11d5 |
>
>
> /home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/powerpc-buildroot-linux-uclibc/sysroot/usr/lib/libavutil.a(hwcontext_drm.o): In function `drm_device_create':
> /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:50: undefined reference to `drmGetVersion'
> /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:63: undefined reference to `drmFreeVersion'
>
> Giulio, I believe you worked on this static linking problem between
> ffmpeg and libdrm. What is the status of this ?
I still have to fix it and I'm currently illed(I think I need 1 week to
recover, I hope). Need also to ask something about solving it.
Going to do it on the e-mails regarding that patch.
Best regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-11 11:02 ` Giulio Benetti
@ 2018-10-20 15:22 ` Giulio Benetti
0 siblings, 0 replies; 37+ messages in thread
From: Giulio Benetti @ 2018-10-20 15:22 UTC (permalink / raw)
To: buildroot
Hello,
Il 11/10/2018 13:02, Giulio Benetti ha scritto:
> Hello everybody,
>
> Il 10/10/2018 17:48, Thomas Petazzoni ha scritto:
>>> powerpc | motion-release-4.1.1 | NOK | http://autobuild.buildroot.net/results/78061b61cfe3f42554a475c048d54dacacfe11d5 |
>>
>>
>> /home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/powerpc-buildroot-linux-uclibc/sysroot/usr/lib/libavutil.a(hwcontext_drm.o): In function `drm_device_create':
>> /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:50: undefined reference to `drmGetVersion'
>> /home/rclinux/rc-buildroot-test/scripts/instance-0/output/build/ffmpeg-3.4.4/libavutil/hwcontext_drm.c:63: undefined reference to `drmFreeVersion'
>>
>> Giulio, I believe you worked on this static linking problem between
>> ffmpeg and libdrm. What is the status of this ?
I've managed to fix it, I've submitted the patch:
https://patchwork.ozlabs.org/patch/985375/
Previous patch I've submitted was wrong, causing -ldrm to be linked both
in static and shared build, because of adding -ldrm to Libs: instead of
Libs.private in libavutil.pc.
But it's been upstreamed:
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/c50dc77ac708e98d02da7c422a6b9cbf9f565aa5
After that I've tried to send a Revert:
https://patchwork.ffmpeg.org/patch/10696/
and re-submit this new patch:
https://patchwork.ffmpeg.org/patch/10697/
but they don't accept it:
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-October/235283.html
I understand they only need a patch to improve the previous one, not the
entire patch I've submitted to Buildroot.
Anyway, is it correct I've submitted a unique patch(the first I've
listed) to Buildroot?
Otherwise I should submit 2 patches, the one already upstreamed:
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/c50dc77ac708e98d02da7c422a6b9cbf9f565aa5
and the correction of it that I still have to send them.
Which is the better choice?
1 patch specific for Buildroot
or
2 patches, 1 already upstreamed and another to be upstreamed?
Sorry for my ignorance
Thanks in advance
Best Regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Buildroot] Analysis results for 2018-10-09
2018-10-10 15:48 ` [Buildroot] Analysis " Thomas Petazzoni
` (6 preceding siblings ...)
2018-10-11 11:02 ` Giulio Benetti
@ 2018-10-11 14:31 ` Frank Hunleth
2018-10-11 14:32 ` Thomas Petazzoni
2018-10-11 19:24 ` Giulio Benetti
8 siblings, 1 reply; 37+ messages in thread
From: Frank Hunleth @ 2018-10-11 14:31 UTC (permalink / raw)
To: buildroot
On Wed, Oct 10, 2018 at 11:48 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> > x86_64 | erlang-21.0 | NOK | http://autobuild.buildroot.net/results/fc633f80c7c36a90e641487f5a888fbb767c2a54 |
>
> In file included from zlib/adler32.c:11:0:
> zlib/zutil.h:172:39: error: "_LFS64_LARGEFILE" is not defined [-Werror=undef]
> (!defined(_LARGEFILE64_SOURCE) || _LFS64_LARGEFILE-0 == 0)
>
> Seems like a musl/erlang issue. Johan, Frank, could you have a look ?
>
I sent the following patch for this upstream:
https://github.com/erlang/otp/pull/1981
I'll send a patch here next chance that I get.
-Frank
^ permalink raw reply [flat|nested] 37+ messages in thread* [Buildroot] Analysis results for 2018-10-09
2018-10-10 15:48 ` [Buildroot] Analysis " Thomas Petazzoni
` (7 preceding siblings ...)
2018-10-11 14:31 ` Frank Hunleth
@ 2018-10-11 19:24 ` Giulio Benetti
8 siblings, 0 replies; 37+ messages in thread
From: Giulio Benetti @ 2018-10-11 19:24 UTC (permalink / raw)
To: buildroot
Hello,
Il 10/10/2018 17:48, Thomas Petazzoni ha scritto:>> arm |
netsnmp-5.8 | NOK |
http://autobuild.buildroot.net/results/9f02e0f09ae2d2a66a8d33d73f1bdd45ea8b0f16
| ORPH
>
> configure: error: The DTLS based transports require the libssl library from OpenSSL to be available and support DTLS
>
> Bernd, you did the last version bump of netsnmp, could you have a look ?
I've submitted this patch for this:
https://patchwork.ozlabs.org/patch/970818/ that solves the build failure
above.
Bernd, please can you check it?
It works for me.
Is it formed ok that patch? (commit log, patches etc.)
I'm still waiting for 1 patch to be upstreamed.
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
^ permalink raw reply [flat|nested] 37+ messages in thread