| Message ID | 1348821796-28798-1-git-send-email-markos.chandras@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
>>>>> <markos.chandras@gmail.com> writes: > From: Markos Chandras <markos.chandras@imgtec.com> > This also fixes a compilation problem with kernel headers 3.5 > http://autobuild.buildroot.net/results/bb66a3a06d26f558e1c4c0593bb68e7af1d82398/build-end.log Committed, thanks.
>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes: >>>>> <markos.chandras@gmail.com> writes: >> From: Markos Chandras <markos.chandras@imgtec.com> >> This also fixes a compilation problem with kernel headers 3.5 >> http://autobuild.buildroot.net/results/bb66a3a06d26f558e1c4c0593bb68e7af1d82398/build-end.log Peter> Committed, thanks. It unfortunately seems to be broken on largefile configurations: http://autobuild.buildroot.net/results/db48ce61cdb53669958b8b301fd24d7ecc33b236/build-end.log Any idea how to fix?
On Fri, Oct 5, 2012 at 6:35 AM, Peter Korsgaard <jacmet@sunsite.dk> wrote: >>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes: > >>>>>> <markos.chandras@gmail.com> writes: > >> From: Markos Chandras <markos.chandras@imgtec.com> > >> This also fixes a compilation problem with kernel headers 3.5 > >> http://autobuild.buildroot.net/results/bb66a3a06d26f558e1c4c0593bb68e7af1d82398/build-end.log > > Peter> Committed, thanks. > > It unfortunately seems to be broken on largefile configurations: > > http://autobuild.buildroot.net/results/db48ce61cdb53669958b8b301fd24d7ecc33b236/build-end.log > > Any idea how to fix? > > -- > Bye, Peter Korsgaard Hi Peter, I will have a look and I will let you know.
On Fri, Oct 5, 2012 at 9:20 AM, Markos Chandras <markos.chandras@gmail.com> wrote: > On Fri, Oct 5, 2012 at 6:35 AM, Peter Korsgaard <jacmet@sunsite.dk> wrote: >>>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes: >> >>>>>>> <markos.chandras@gmail.com> writes: >> >> From: Markos Chandras <markos.chandras@imgtec.com> >> >> This also fixes a compilation problem with kernel headers 3.5 >> >> http://autobuild.buildroot.net/results/bb66a3a06d26f558e1c4c0593bb68e7af1d82398/build-end.log >> >> Peter> Committed, thanks. >> >> It unfortunately seems to be broken on largefile configurations: >> >> http://autobuild.buildroot.net/results/db48ce61cdb53669958b8b301fd24d7ecc33b236/build-end.log >> >> Any idea how to fix? >> >> -- >> Bye, Peter Korsgaard > > Hi Peter, > > I will have a look and I will let you know. > > -- > Regards, > Markos Hi Peter, This also happens with the latest strace git code. It seems like -D_FILE_OFFSET_BITS=64 is causing it. But there are also some other problems in the LFS support. I will see if I can write some patches and send them upstream.
>>>>> "Markos" == Markos Chandras <markos.chandras@gmail.com> writes:
Markos> Hi Peter,
Markos> This also happens with the latest strace git code. It seems like
Markos> -D_FILE_OFFSET_BITS=64 is causing it. But there are also some other
Markos> problems in the LFS support. I will see if I can write some patches
Markos> and send them upstream.
Great, thanks!
On 05/10/12 15:58, Peter Korsgaard wrote: >>>>>> "Markos" == Markos Chandras<markos.chandras@gmail.com> writes: > > Markos> Hi Peter, > > Markos> This also happens with the latest strace git code. It seems like > Markos> -D_FILE_OFFSET_BITS=64 is causing it. But there are also some other > Markos> problems in the LFS support. I will see if I can write some patches > Markos> and send them upstream. > > Great, thanks! Not sure if it is related, but the previous version was already broken for me on x86_64 builds. Hm, probably not related, because it failed with: file.c: In function 'printstat64': file.c:1073:16: error: storage size of 'statbuf' isn't known file.c:1073:16: warning: unused variable 'statbuf' [-Wunused-variable] Regards, Arnout
On Sat, Oct 6, 2012 at 12:18 AM, Arnout Vandecappelle <arnout@mind.be> wrote: > On 05/10/12 15:58, Peter Korsgaard wrote: >>>>>>> >>>>>>> "Markos" == Markos Chandras<markos.chandras@gmail.com> writes: >> >> >> Markos> Hi Peter, >> >> Markos> This also happens with the latest strace git code. It seems >> like >> Markos> -D_FILE_OFFSET_BITS=64 is causing it. But there are also some >> other >> Markos> problems in the LFS support. I will see if I can write some >> patches >> Markos> and send them upstream. >> >> Great, thanks! > > > Not sure if it is related, but the previous version was already broken for > me > on x86_64 builds. Hm, probably not related, because it failed with: > > file.c: In function 'printstat64': > file.c:1073:16: error: storage size of 'statbuf' isn't known > file.c:1073:16: warning: unused variable 'statbuf' [-Wunused-variable] > > > Regards, > Arnout > -- > Arnout Vandecappelle arnout at mind be > Senior Embedded Software Architect +32-16-286540 > 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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F Hi Arnout, I reported this problem upstream about an hour ago (with a proposed patch included) http://sourceforge.net/mailarchive/message.php?msg_id=29947462
On 10/10/12 14:49, Markos Chandras wrote: > On Sat, Oct 6, 2012 at 12:18 AM, Arnout Vandecappelle<arnout@mind.be> wrote: >> Not sure if it is related, but the previous version was already broken for me >> on x86_64 builds. Hm, probably not related, because it failed with: >> >> file.c: In function 'printstat64': >> file.c:1073:16: error: storage size of 'statbuf' isn't known >> file.c:1073:16: warning: unused variable 'statbuf' [-Wunused-variable] >> > I reported this problem upstream about an hour ago (with a proposed > patch included) > > http://sourceforge.net/mailarchive/message.php?msg_id=29947462 Is this only on x86_64 or also on other 64-bit platforms? Regards, Arnout
On Thu, Oct 11, 2012 at 10:26 PM, Arnout Vandecappelle <arnout@mind.be> wrote: > On 10/10/12 14:49, Markos Chandras wrote: >> >> On Sat, Oct 6, 2012 at 12:18 AM, Arnout Vandecappelle<arnout@mind.be> >> wrote: >>> >>> Not sure if it is related, but the previous version was already broken >>> for me >>> >>> on x86_64 builds. Hm, probably not related, because it failed with: >>> >>> file.c: In function 'printstat64': >>> file.c:1073:16: error: storage size of 'statbuf' isn't known >>> file.c:1073:16: warning: unused variable 'statbuf' [-Wunused-variable] >>> > >> I reported this problem upstream about an hour ago (with a proposed >> patch included) >> >> http://sourceforge.net/mailarchive/message.php?msg_id=29947462 > > > Is this only on x86_64 or also on other 64-bit platforms? > > I haven't tested it with other 64-bit platforms but I think the rest of them provide a struct stat64. But even with this patch, it does not go much further as it fails to build again due to undefined syscalls like Peter posted before http://autobuild.buildroot.net/results/db48ce61cdb53669958b8b301fd24d7ecc33b236/build-end.log Another way to workaround the stat64 problem on x86_64 is to ac_cv_have_long_long_off_t=yes on strace.mk when BR2_LARGEFILE is enabled.
2012/10/12 Markos Chandras <markos.chandras@gmail.com> > On Thu, Oct 11, 2012 at 10:26 PM, Arnout Vandecappelle <arnout@mind.be> > wrote: > > On 10/10/12 14:49, Markos Chandras wrote: > >> > >> On Sat, Oct 6, 2012 at 12:18 AM, Arnout Vandecappelle<arnout@mind.be> > >> wrote: > >>> > >>> Not sure if it is related, but the previous version was already > broken > >>> for me > >>> > >>> on x86_64 builds. Hm, probably not related, because it failed with: > >>> > >>> file.c: In function 'printstat64': > >>> file.c:1073:16: error: storage size of 'statbuf' isn't known > >>> file.c:1073:16: warning: unused variable 'statbuf' [-Wunused-variable] > >>> > > > >> I reported this problem upstream about an hour ago (with a proposed > >> patch included) > >> > >> http://sourceforge.net/mailarchive/message.php?msg_id=29947462 > > > > > > Is this only on x86_64 or also on other 64-bit platforms? > > > > > I haven't tested it with other 64-bit platforms but I think the rest > of them provide a struct stat64. But even with this patch, it does not > go much further as it fails to build again due to undefined syscalls > like Peter posted before > > > http://autobuild.buildroot.net/results/db48ce61cdb53669958b8b301fd24d7ecc33b236/build-end.log > > Another way to workaround the stat64 problem on x86_64 is to > ac_cv_have_long_long_off_t=yes on strace.mk when > BR2_LARGEFILE is enabled. > > -- > Regards, > Markos > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot > Hi! i'm trying to buiid strace See here http://pastie.org/5043151 syscall.o:(.rodata+0x128): undefined reference to `sys_oldstat' syscall.o:(.rodata+0x1c8): undefined reference to `sys_oldfstat' syscall.o:(.rodata+0x548): undefined reference to `sys_oldlstat' syscall.o:(.rodata+0x5a8): undefined reference to `sys_old_mmap' syscall.o:(.rodata+0xc18): undefined reference to `sys_truncate64' syscall.o:(.rodata+0xc28): undefined reference to `sys_ftruncate64' syscall.o:(.rodata+0xc38): undefined reference to `sys_stat64' syscall.o:(.rodata+0xc48): undefined reference to `sys_lstat64' syscall.o:(.rodata+0xc58): undefined reference to `sys_fstat64'
>>>>> "Markos" == Markos Chandras <markos.chandras@gmail.com> writes:
Markos> Hi Peter,
Markos> This also happens with the latest strace git code. It seems like
Markos> -D_FILE_OFFSET_BITS=64 is causing it. But there are also some other
Markos> problems in the LFS support. I will see if I can write some patches
Markos> and send them upstream.
Peter> Great, thanks!
Any progress on this? All the strace failures on the autobuilders are
not so nice. Alternatively I can revert until we have a fix.
On Tue, Oct 16, 2012 at 8:57 PM, Peter Korsgaard <jacmet@sunsite.dk> wrote: >>>>>> "Markos" == Markos Chandras <markos.chandras@gmail.com> writes: > Markos> Hi Peter, > > Markos> This also happens with the latest strace git code. It seems like > Markos> -D_FILE_OFFSET_BITS=64 is causing it. But there are also some other > Markos> problems in the LFS support. I will see if I can write some patches > Markos> and send them upstream. > > Peter> Great, thanks! > > Any progress on this? All the strace failures on the autobuilders are > not so nice. Alternatively I can revert until we have a fix. > > -- > Bye, Peter Korsgaard Hi Peter, I haven't managed to find a solution yet and I think all the LFS problems are buildroot specific. I don't have a native LFS toolchain so I can try an out-of-buildroot build. You can either revert the commit or disable the LFS support in the package for now.
>>>>> "Markos" == Markos Chandras <markos.chandras@gmail.com> writes:
Hi,
Markos> I haven't managed to find a solution yet and I think all the
Markos> LFS problems are buildroot specific. I don't have a native LFS
Markos> toolchain so I can try an out-of-buildroot build. You can
Markos> either revert the commit or disable the LFS support in the
Markos> package for now.
ok, thanks.
I'll try to take another look, and revert if I don't see an easy
solution.
>>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
Hi,
Markos> I haven't managed to find a solution yet and I think all the
Markos> LFS problems are buildroot specific. I don't have a native LFS
Markos> toolchain so I can try an out-of-buildroot build. You can
Markos> either revert the commit or disable the LFS support in the
Markos> package for now.
Peter> ok, thanks.
Peter> I'll try to take another look, and revert if I don't see an easy
Peter> solution.
I luckily found a solution (23f6455bff), which I've applied.
On Mon, Oct 29, 2012 at 8:55 PM, Peter Korsgaard <jacmet@sunsite.dk> wrote: >>>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes: > > Hi, > > Markos> I haven't managed to find a solution yet and I think all the > Markos> LFS problems are buildroot specific. I don't have a native LFS > Markos> toolchain so I can try an out-of-buildroot build. You can > Markos> either revert the commit or disable the LFS support in the > Markos> package for now. > > Peter> ok, thanks. > > Peter> I'll try to take another look, and revert if I don't see an easy > Peter> solution. > > I luckily found a solution (23f6455bff), which I've applied. > > -- > Bye, Peter Korsgaard Hi Peter, Hmm I thought that -D_FILE_OFFSET_BITS=64 was required when building with LFS. I guess I was wrong. Thanks for fixing it.
diff --git a/package/strace/strace.mk b/package/strace/strace.mk index 2d95137..5c2d33c 100644 --- a/package/strace/strace.mk +++ b/package/strace/strace.mk @@ -4,8 +4,8 @@ # ############################################################# -STRACE_VERSION = 4.5.20 -STRACE_SOURCE = strace-$(STRACE_VERSION).tar.bz2 +STRACE_VERSION = 4.7 +STRACE_SOURCE = strace-$(STRACE_VERSION).tar.xz STRACE_SITE = http://downloads.sourceforge.net/project/strace/strace/$(STRACE_VERSION) STRACE_CONF_ENV = ac_cv_header_linux_if_packet_h=yes \