* [Buildroot] Analysis of build results for 2017-02-26
2017-02-27 13:28 ` [Buildroot] Analysis of build " Thomas Petazzoni
@ 2017-02-27 15:54 ` Yann E. MORIN
2017-02-27 15:57 ` Thomas Petazzoni
2017-02-27 16:54 ` Frank Hunleth
` (4 subsequent siblings)
5 siblings, 1 reply; 18+ messages in thread
From: Yann E. MORIN @ 2017-02-27 15:54 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2017-02-27 14:28 +0100, Thomas Petazzoni spake thusly:
[--SNIP--]
> > arc | mpv-0.23.0 | NOK | http://autobuild.buildroot.net/results/fb677a917545adee321bdcd2c2519c81326448c4
>
> ../video/out/filter_kernels.c: In function 'jinc':
> ../video/out/filter_kernels.c:318:18: error: implicit declaration of function 'j1' [-Werror=implicit-function-declaration]
> return 2.0 * j1(x) / x;
>
> Vlad, this is only occurring on ARC, could you have a look?
That's again because of the Synopsys toolchain, whise uClibc has been
configured without the "Bessel functions of the first kind".
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 18+ messages in thread* [Buildroot] Analysis of build results for 2017-02-26
2017-02-27 15:54 ` Yann E. MORIN
@ 2017-02-27 15:57 ` Thomas Petazzoni
0 siblings, 0 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2017-02-27 15:57 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 27 Feb 2017 16:54:03 +0100, Yann E. MORIN wrote:
> Thomas, All,
>
> On 2017-02-27 14:28 +0100, Thomas Petazzoni spake thusly:
> [--SNIP--]
> > > arc | mpv-0.23.0 | NOK | http://autobuild.buildroot.net/results/fb677a917545adee321bdcd2c2519c81326448c4
> >
> > ../video/out/filter_kernels.c: In function 'jinc':
> > ../video/out/filter_kernels.c:318:18: error: implicit declaration of function 'j1' [-Werror=implicit-function-declaration]
> > return 2.0 * j1(x) / x;
> >
> > Vlad, this is only occurring on ARC, could you have a look?
>
> That's again because of the Synopsys toolchain, whise uClibc has been
> configured without the "Bessel functions of the first kind".
Let's add yet another "depends on !..." then.
Thanks for the investigation!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-26
2017-02-27 13:28 ` [Buildroot] Analysis of build " Thomas Petazzoni
2017-02-27 15:54 ` Yann E. MORIN
@ 2017-02-27 16:54 ` Frank Hunleth
2017-02-27 20:20 ` Thomas Petazzoni
2017-02-27 22:38 ` [Buildroot] Analysis of build results for 2017-02-26: libsidplay issue on PowerPC64 Thomas Petazzoni
` (3 subsequent siblings)
5 siblings, 1 reply; 18+ messages in thread
From: Frank Hunleth @ 2017-02-27 16:54 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, Feb 27, 2017 at 8:28 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
>> i686 | rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/92f9a6b804072a521ad0b25086a0a5ed33eaf53e
>> arc | rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/a04ba24c6cd61bf6f2128a0e869f679cb3f2eac3
>
> Static linking issues, with a CMake based package. Frank, Samuel, could
> you have a look?
>
I took a quick look. The issue is due to a transitive dependency on
zlib not being added to the linker invocation. The rabbitmq utilities
make calls to libcrypto.a which has calls to zlib. I don't use cmake
enough to know how this is normally fixed with that tool. If there's
another example somewhere that I can copy, I don't mind submitting a
fix.
Frank
p.s. Fwiw, rabbitmq-c is actually maintained by Joris Lijssens, so I'm
adding him to the cc list in case he has run into this. My rabbitmq
package is rabbitmq-server, but my project with rabbit also uses
rabbitmq-c.
^ permalink raw reply [flat|nested] 18+ messages in thread* [Buildroot] Analysis of build results for 2017-02-26
2017-02-27 16:54 ` Frank Hunleth
@ 2017-02-27 20:20 ` Thomas Petazzoni
0 siblings, 0 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2017-02-27 20:20 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 27 Feb 2017 11:54:19 -0500, Frank Hunleth wrote:
> >> i686 | rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/92f9a6b804072a521ad0b25086a0a5ed33eaf53e
> >> arc | rabbitmq-c-v0.8.0 | NOK | http://autobuild.buildroot.net/results/a04ba24c6cd61bf6f2128a0e869f679cb3f2eac3
> >
> > Static linking issues, with a CMake based package. Frank, Samuel, could
> > you have a look?
> >
>
> I took a quick look. The issue is due to a transitive dependency on
> zlib not being added to the linker invocation. The rabbitmq utilities
> make calls to libcrypto.a which has calls to zlib. I don't use cmake
> enough to know how this is normally fixed with that tool. If there's
> another example somewhere that I can copy, I don't mind submitting a
> fix.
The proper solution for this is to use pkg-config to discover the
libraries. pkg-config has the relevant information about transitive
dependencies that are needed for static linking to work properly.
It is worth noting that the problem does not occur only with
openssl->zlib, but also with libintl.
> p.s. Fwiw, rabbitmq-c is actually maintained by Joris Lijssens, so I'm
> adding him to the cc list in case he has run into this. My rabbitmq
> package is rabbitmq-server, but my project with rabbit also uses
> rabbitmq-c.
Ah, yes, indeed, my bad. Thanks for adding Joris in the loop then. He
should anyway have received notifications of the build failures.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-26: libsidplay issue on PowerPC64
2017-02-27 13:28 ` [Buildroot] Analysis of build " Thomas Petazzoni
2017-02-27 15:54 ` Yann E. MORIN
2017-02-27 16:54 ` Frank Hunleth
@ 2017-02-27 22:38 ` Thomas Petazzoni
2017-02-28 0:41 ` Sam Bobroff
2017-02-27 22:38 ` [Buildroot] Analysis of build results for 2017-02-26: classpath issue Thomas Petazzoni
` (2 subsequent siblings)
5 siblings, 1 reply; 18+ messages in thread
From: Thomas Petazzoni @ 2017-02-27 22:38 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 27 Feb 2017 14:28:54 +0100, Thomas Petazzoni wrote:
> > powerpc64le | libsidplay2-2.1.1 | NOK | http://autobuild.buildroot.net/results/caba78cc2706accc187a428364c0e0d10a1dcd60
>
> Missing -fPIC apparently. Sam?
I had a closer look at this one. What happens is:
1. libsidplay is autoreconf'ed due to <pkg>_AUTORECONF = YES
2. we apply the powerpc64le trick that patches the configure script,
thanks to this, during the configure step, the fact that shared
libraries are supported is properly detected.
3. for some reason, when the build starts, it auto-autoreconfs itself,
which rewrites the configure script, without the powerpc64le
trick. ./configure is re-executed, and this time doesn't detected
shared library support anymore.
So the issue is: why does the package decides to auto-autoreconf itself
at the beginning of the build step.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread* [Buildroot] Analysis of build results for 2017-02-26: libsidplay issue on PowerPC64
2017-02-27 22:38 ` [Buildroot] Analysis of build results for 2017-02-26: libsidplay issue on PowerPC64 Thomas Petazzoni
@ 2017-02-28 0:41 ` Sam Bobroff
0 siblings, 0 replies; 18+ messages in thread
From: Sam Bobroff @ 2017-02-28 0:41 UTC (permalink / raw)
To: buildroot
On Mon, Feb 27, 2017 at 11:38:18PM +0100, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 27 Feb 2017 14:28:54 +0100, Thomas Petazzoni wrote:
>
> > > powerpc64le | libsidplay2-2.1.1 | NOK | http://autobuild.buildroot.net/results/caba78cc2706accc187a428364c0e0d10a1dcd60
> >
> > Missing -fPIC apparently. Sam?
>
> I had a closer look at this one. What happens is:
>
> 1. libsidplay is autoreconf'ed due to <pkg>_AUTORECONF = YES
>
> 2. we apply the powerpc64le trick that patches the configure script,
> thanks to this, during the configure step, the fact that shared
> libraries are supported is properly detected.
>
> 3. for some reason, when the build starts, it auto-autoreconfs itself,
> which rewrites the configure script, without the powerpc64le
> trick. ./configure is re-executed, and this time doesn't detected
> shared library support anymore.
>
> So the issue is: why does the package decides to auto-autoreconf itself
> at the beginning of the build step.
Ah, thanks for the investigation, I'll take a look at it.
Sam.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-26: classpath issue
2017-02-27 13:28 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (2 preceding siblings ...)
2017-02-27 22:38 ` [Buildroot] Analysis of build results for 2017-02-26: libsidplay issue on PowerPC64 Thomas Petazzoni
@ 2017-02-27 22:38 ` Thomas Petazzoni
2017-02-27 23:01 ` [Buildroot] Analysis of build results for 2017-02-26: librsvg failure Thomas Petazzoni
2017-02-28 15:34 ` [Buildroot] Analysis of build results for 2017-02-26 Vlad Zakharov
5 siblings, 0 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2017-02-27 22:38 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 27 Feb 2017 14:28:54 +0100, Thomas Petazzoni wrote:
> > nios2 | classpath-0.98 | NOK | http://autobuild.buildroot.net/results/279dd731bd9ecf5f9d54bda3715caeaa7cbcdbb3
> > microblazeel | classpath-0.98 | NOK | http://autobuild.buildroot.net/results/55eb89f89e96b94a821778bc18ed844af08b7460
>
> Perhaps this needs a commit like
> https://git.buildroot.org/buildroot/commit/?id=f12a146f817c8ef07a7d41a31a5336b5ef6a96e8
> but for nios2 and microblaze ?
For this one, I submitted:
http://patchwork.ozlabs.org/patch/733183/
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread* [Buildroot] Analysis of build results for 2017-02-26: librsvg failure
2017-02-27 13:28 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (3 preceding siblings ...)
2017-02-27 22:38 ` [Buildroot] Analysis of build results for 2017-02-26: classpath issue Thomas Petazzoni
@ 2017-02-27 23:01 ` Thomas Petazzoni
2017-02-28 9:00 ` Peter Korsgaard
2017-02-28 15:34 ` [Buildroot] Analysis of build results for 2017-02-26 Vlad Zakharov
5 siblings, 1 reply; 18+ messages in thread
From: Thomas Petazzoni @ 2017-02-27 23:01 UTC (permalink / raw)
To: buildroot
Hello,
Adding Gustavo on this one, there is some gdk-pixbuf stuff involved.
On Mon, 27 Feb 2017 14:28:54 +0100, Thomas Petazzoni wrote:
> > x86_64 | librsvg-2.40.16 | NOK | http://autobuild.buildroot.net/results/393145bc9bcb93d6df55ec8c63725c3d9a299957
> > x86_64 | librsvg-2.40.16 | NOK | http://autobuild.buildroot.net/results/60af583e52d9ff8efff1bc455e4f842721c5807c
> > x86_64 | librsvg-2.40.16 | NOK | http://autobuild.buildroot.net/results/492aaf78f4d47d80bb813810a54121799a5c8d46
>
> Makefile:807: recipe for target 'gdk-pixbuf-loaders' failed
>
> at installation time. It only happens with that specific x86-64
> toolchain: http://autobuild.buildroot.net/?reason=librsvg-2.40.16.
>
> Could you be something like the host is x86-64/glibc and the target is
> x86-64/glibc, and it confuses something?
Adding Gustavo in Cc on this one. On my x86-64 machine, the following
defconfig reproduces the issue:
BR2_x86_64=y
BR2_x86_steamroller=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_LIBRSVG=y
# BR2_TARGET_ROOTFS_TAR is not set
The command that causes the installation failure is:
/home/thomas/projets/buildroot/output/host/usr/bin/gdk-pixbuf-query-loaders ./libpixbufloader-svg.la && /home/thomas/projets/buildroot/output/host/usr/bin/gdk-pixbuf-query-loaders
Interestingly, when run outside of the build process, it is successful
(echo $? says 0). However, when run by the package Makefile, it fails
with Error 132. It turns out that it's an "Illegal instruction" error:
( strace -o /tmp/pouet.log /home/thomas/projets/buildroot/output/host/usr/bin/gdk-pixbuf-query-loaders ./libpixbufloader-svg.la && /home/thomas/projets/buildroot/output/host/usr/bin/gdk-pixbuf-query-loaders)
/bin/bash: line 1: 31690 Illegal instruction strace -o /tmp/pouet.log /home/thomas/projets/buildroot/output/host/usr/bin/gdk-pixbuf-query-loaders ./libpixbufloader-svg.la
Makefile:807: recipe for target 'gdk-pixbuf-loaders' failed
make[4]: *** [gdk-pixbuf-loaders] Error 132
The strace (which was added by me), give:
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0V\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=1088952, ...}) = 0
mmap(NULL, 3178744, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8df2576000
mprotect(0x7f8df267e000, 2093056, PROT_NONE) = 0
mmap(0x7f8df287d000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x107000) = 0x7f8df287d000
close(3) = 0
mprotect(0x7f8df287d000, 4096, PROT_READ) = 0
mprotect(0x7f8df361b000, 4096, PROT_READ) = 0
mprotect(0x7f8df556d000, 4096, PROT_READ) = 0
--- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x7f8df3d26f02} ---
+++ killed by SIGILL +++
So very very early in the program execution, it aborts with an illegal
instruction. I dumped the environment from the Makefile right before
running this command, and couldn't see anything obviously wrong.
Any idea?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread* [Buildroot] Analysis of build results for 2017-02-26: librsvg failure
2017-02-27 23:01 ` [Buildroot] Analysis of build results for 2017-02-26: librsvg failure Thomas Petazzoni
@ 2017-02-28 9:00 ` Peter Korsgaard
2017-02-28 9:05 ` Thomas Petazzoni
0 siblings, 1 reply; 18+ messages in thread
From: Peter Korsgaard @ 2017-02-28 9:00 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
> The strace (which was added by me), give:
> read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0V\0\0\0\0\0\0"..., 832) = 832
> fstat(3, {st_mode=S_IFREG|0644, st_size=1088952, ...}) = 0
> mmap(NULL, 3178744, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8df2576000
> mprotect(0x7f8df267e000, 2093056, PROT_NONE) = 0
> mmap(0x7f8df287d000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x107000) = 0x7f8df287d000
> close(3) = 0
> mprotect(0x7f8df287d000, 4096, PROT_READ) = 0
> mprotect(0x7f8df361b000, 4096, PROT_READ) = 0
> mprotect(0x7f8df556d000, 4096, PROT_READ) = 0
> --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x7f8df3d26f02} ---
> +++ killed by SIGILL +++
Is that the complete strace output? Where is fd 3 getting opened? I
would imagine the problem is caused by some kind of host/target
libraries mixup.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 18+ messages in thread* [Buildroot] Analysis of build results for 2017-02-26: librsvg failure
2017-02-28 9:00 ` Peter Korsgaard
@ 2017-02-28 9:05 ` Thomas Petazzoni
2017-02-28 14:16 ` Thomas Petazzoni
2017-02-28 14:48 ` Peter Korsgaard
0 siblings, 2 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2017-02-28 9:05 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 28 Feb 2017 10:00:14 +0100, Peter Korsgaard wrote:
> Is that the complete strace output? Where is fd 3 getting opened? I
> would imagine the problem is caused by some kind of host/target
> libraries mixup.
No, that's only the end of the strace output. I've posted the full
strace output at:
http://code.bulix.org/elused-120071
File descriptor 3 is:
open("/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
Which looks correct to me, when running a host binary on the host machine.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread* [Buildroot] Analysis of build results for 2017-02-26: librsvg failure
2017-02-28 9:05 ` Thomas Petazzoni
@ 2017-02-28 14:16 ` Thomas Petazzoni
2017-02-28 14:48 ` Peter Korsgaard
1 sibling, 0 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2017-02-28 14:16 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 28 Feb 2017 10:05:42 +0100, Thomas Petazzoni wrote:
> No, that's only the end of the strace output. I've posted the full
> strace output at:
>
> http://code.bulix.org/elused-120071
>
> File descriptor 3 is:
>
> open("/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
>
> Which looks correct to me, when running a host binary on the host machine.
Ok, so I went through the next stage: running the program under gdb, so
now I know exactly the instruction that faulted, in which function, etc.
Program received signal SIGILL, Illegal instruction.
0x00007ffff4869f02 in have_feature ()
from target:/home/thomas/projets/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libpixman-1.so.0
(gdb) bt
#0 0x00007ffff4869f02 in have_feature ()
from target:/home/thomas/projets/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libpixman-1.so.0
So we're crashing in libpixman, in the have_feature() function, whose
goal is precisely to determine the capabilities of the CPU we are
running on.
The faulty instruction is:
(gdb) disassemble
Dump of assembler code for function have_feature:
0x00007ffff4869ee1 <+0>: push %r13
0x00007ffff4869ee3 <+2>: push %r12
0x00007ffff4869ee5 <+4>: mov %edi,%r12d
0x00007ffff4869ee8 <+7>: push %rbp
0x00007ffff4869ee9 <+8>: push %rbx
0x00007ffff4869eea <+9>: sub $0x18,%rsp
0x00007ffff4869eee <+13>: cmpl $0x0,0x25e85f(%rip) # 0x7ffff4ac8754 <initialized.4467>
0x00007ffff4869ef5 <+20>: jne 0x7ffff4869fc6 <have_feature+229>
0x00007ffff4869efb <+26>: mov $0x1,%eax
0x00007ffff4869f00 <+31>: cpuid
=> 0x00007ffff4869f02 <+33>: bextr $0x10f,%edx,%ebp
0x00007ffff4869f0b <+42>: shl $0x4,%ebp
0x00007ffff4869f0e <+45>: mov %ebp,%eax
0x00007ffff4869f10 <+47>: or $0x1,%eax
This bextr instruction is indeed a somewhat new instruction: it was
introduced in the Haswell micro-architecture, but my i7-4600U is a
Haswell one. I'm not a big expert in Intel architecture, but I believe
this instruction should therefore be valid on my CPU.
What is very weird is that if I run this program outside of the build
process, it runs fine. It's only when it's run within the overall build
process that it crashes on this instruction. To get the above gdb
stuff, I had to hack the package Makefile to run the program under
gdbserver, and connect to it.
Looking at the pixman code, I don't see any place where a bextr
instruction is explicitly used, so it seems like it's generated by gcc.
Another weird thing: this only happens if the target is x86-64, with a
specific toolchain. Now, the question is: why a host package crash can
be related to the target architecture/toolchain...
/me calling Mulder and Scully :)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread* [Buildroot] Analysis of build results for 2017-02-26: librsvg failure
2017-02-28 9:05 ` Thomas Petazzoni
2017-02-28 14:16 ` Thomas Petazzoni
@ 2017-02-28 14:48 ` Peter Korsgaard
2017-02-28 15:37 ` Thomas Petazzoni
1 sibling, 1 reply; 18+ messages in thread
From: Peter Korsgaard @ 2017-02-28 14:48 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hello,
> On Tue, 28 Feb 2017 10:00:14 +0100, Peter Korsgaard wrote:
>> Is that the complete strace output? Where is fd 3 getting opened? I
>> would imagine the problem is caused by some kind of host/target
>> libraries mixup.
> No, that's only the end of the strace output. I've posted the full
> strace output at:
> http://code.bulix.org/elused-120071
> File descriptor 3 is:
> open("/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
> Which looks correct to me, when running a host binary on the host machine.
Yes, but the part where it loads a library from the target-librsvg
doesn't:
stat("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader/./libpixbufloader-svg.la", {st_mode=S_IFREG|0644, st_size=3987, ...}) = 0
open("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader/./libpixbufloader-svg.la", O_RDONLY) = 3
read(3, "# libpixbufloader-svg.la - a lib"..., 4000) = 3987
futex(0x7fb04bc20488, FUTEX_WAKE_PRIVATE, 2147483647) = 0
read(3, "", 4000) = 0
close(3) = 0
futex(0x7fb04b3480a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader/./.libs/libpixbufloader-svg.so", O_RDONLY|O_CLOEXEC) = 3
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 18+ messages in thread* [Buildroot] Analysis of build results for 2017-02-26: librsvg failure
2017-02-28 14:48 ` Peter Korsgaard
@ 2017-02-28 15:37 ` Thomas Petazzoni
2017-02-28 16:10 ` Peter Korsgaard
0 siblings, 1 reply; 18+ messages in thread
From: Thomas Petazzoni @ 2017-02-28 15:37 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 28 Feb 2017 15:48:08 +0100, Peter Korsgaard wrote:
> > Which looks correct to me, when running a host binary on the host machine.
>
> Yes, but the part where it loads a library from the target-librsvg
> doesn't:
>
> stat("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> stat("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader/./libpixbufloader-svg.la", {st_mode=S_IFREG|0644, st_size=3987, ...}) = 0
> open("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader/./libpixbufloader-svg.la", O_RDONLY) = 3
> read(3, "# libpixbufloader-svg.la - a lib"..., 4000) = 3987
> futex(0x7fb04bc20488, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> read(3, "", 4000) = 0
> close(3) = 0
> futex(0x7fb04b3480a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> open("/home/thomas/projets/buildroot/output/build/librsvg-2.40.16/gdk-pixbuf-loader/./.libs/libpixbufloader-svg.so", O_RDONLY|O_CLOEXEC) = 3
Wow, indeed!
But how does this fit with my findings with gdb, which were pointing at
a faulty instruction in the host libpixman?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread* [Buildroot] Analysis of build results for 2017-02-26: librsvg failure
2017-02-28 15:37 ` Thomas Petazzoni
@ 2017-02-28 16:10 ` Peter Korsgaard
0 siblings, 0 replies; 18+ messages in thread
From: Peter Korsgaard @ 2017-02-28 16:10 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
> Wow, indeed!
> But how does this fit with my findings with gdb, which were pointing at
> a faulty instruction in the host libpixman?
Target libpixman, not host-pixman. From the log:
open("/home/thomas/projets/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libpixman-1.so.0", O_RDONLY|O_CLOEXEC) = 3
So I guess it is all caused by host/target mismatch and the specific
optimization options selected.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] Analysis of build results for 2017-02-26
2017-02-27 13:28 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (4 preceding siblings ...)
2017-02-27 23:01 ` [Buildroot] Analysis of build results for 2017-02-26: librsvg failure Thomas Petazzoni
@ 2017-02-28 15:34 ` Vlad Zakharov
2017-02-28 16:02 ` Thomas Petazzoni
5 siblings, 1 reply; 18+ messages in thread
From: Vlad Zakharov @ 2017-02-28 15:34 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Mon, 2017-02-27 at 14:28 +0100, Thomas Petazzoni wrote:
> >????????? arc |???????????????????? mpd-0.20.4 | NOK ?
>
> Lacks a -lpthread apparently:
>
> /home/peko/autobuild/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-snps-linux-
> uclibc/6.2.1/../../../../arc-snps-linux-uclibc/bin/ld: libthread.a(Thread.o): undefined reference to symbol
> 'pthread_create'
> /home/peko/autobuild/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/lib/libpthread.so.0: error adding
> symbols: DSO missing from command line
>
> but the configure script fails to detect thread support:
>
> checking for the pthreads library -lpthread... no
>
> Aah, they test if the compiler defines _REENTRANT:
>
> conftest.c:15:26: error: #error "_REENTRANT must be defined"
> ?#??????????????????????? error "_REENTRANT must be defined"
>
> and I know some architectures forget to do so.
>
> I already reported this bug to gcc upstream:
>
> ?https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71749?
>
> Vlad, could you have a look into this? We have
> package/gcc/6.3.0/895-bfin-define-REENTRANT.patch for Blackfin in the
> tree, but we don't have the corresponding patch for ARC.
The patch you have provided in gcc bugzilla solves the issue, thanks.
I am going to send it to Buildroot soon.
If you want to upstream your patch to gcc please send it to GCC mailing list. And please don't forget to include Claudiu
Zissulescu <claziss@synopsys.com>?in CC as he is co-maintainer of GCC port for ARC.
Thanks!
--
Best regards,
Vlad Zakharov <vzakhar@synopsys.com>
^ permalink raw reply [flat|nested] 18+ messages in thread* [Buildroot] Analysis of build results for 2017-02-26
2017-02-28 15:34 ` [Buildroot] Analysis of build results for 2017-02-26 Vlad Zakharov
@ 2017-02-28 16:02 ` Thomas Petazzoni
0 siblings, 0 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2017-02-28 16:02 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 28 Feb 2017 15:34:56 +0000, Vlad Zakharov wrote:
> > Vlad, could you have a look into this? We have
> > package/gcc/6.3.0/895-bfin-define-REENTRANT.patch for Blackfin in the
> > tree, but we don't have the corresponding patch for ARC.
>
> The patch you have provided in gcc bugzilla solves the issue, thanks.
> I am going to send it to Buildroot soon.
Great, thanks for checking!
> If you want to upstream your patch to gcc please send it to GCC mailing list. And please don't forget to include Claudiu
> Zissulescu <claziss@synopsys.com>?in CC as he is co-maintainer of GCC port for ARC.
I received some feedback from Claudio through the gcc bug tracker. I'll
try to get my gcc patch submitted upstream. Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread