full rebuild and errors
Hello,
I successfully compiled buildroot for Raspberry Pi following this guide:
https://github.com/albertd/buildroot-rpi
I had a problem with some applications (btw it was: EGL Error : Could not create the egl surface: error = 0x300b) and I read some users were able to solve just rebuilding buildroot.
Thus, I issued:
make cleanall
as stated in the documentation. But this time I get the following errors:
/home/mark/dev/buildroot-rpi/output/host/usr/bin/ccache /usr/bin/gcc
-std=gnu99 -O2 -I/home/mark/dev/buildroot-rpi/output/host/usr/include
-L/home/mark/dev/buildroot-rpi/output/host/lib -L/home/mark/dev/buildroot-rpi/output/host/usr/lib -Wl,-rpath,/home/mark/dev/buildroot-rpi/output/host/usr/lib -o m4 m4.o builtin.o debug.o eval.o format.o freeze.o input.o macro.o output.o path.o symtab.o ../lib/libm4.a
m4.o: In function `main':
m4.c:(.text.startup+0x260): undefined reference to version_etc' m4.c:(.text.startup+0x3ef): undefined reference to emit_bug_reporting_address'
collect2: error: ld returned 1 exit status
make[3]: *** [m4] Error 1
make[3]: Leaving directory `/home/mark/dev/buildroot-rpi/output/build/host-m4-1.4.16/src' make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/mark/dev/buildroot-rpi/output/build/host-m4-1.4.16' make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/mark/dev/buildroot-rpi/output/build/host-m4-1.4.16'
make: *** [/home/mark/dev/buildroot-rpi/output/build/host-m4-1.4.16/.stamp_built] Error 2
Google doesn't help me on this.
Do you have any idea why this happens?
Thanks
Mark
Quoted 11 lines · Marco Trapanese
Hello,
I successfully compiled buildroot for Raspberry Pi following this guide:https://github.com/albertd/buildroot-rpi
I had a problem with some applications (btw it was: EGL Error : Could not create the egl surface: error =
0x300b) and I read some users were able to solve just rebuilding buildroot.
Thus, I issued:make cleanall
I guess you mean
make clean all
?
Quoted 8 lines
as stated in the documentation. But this time I get the following errors:
/home/mark/dev/buildroot-rpi/output/host/usr/bin/ccache/usr/bin/gcc(quoted diff) +0
-4-std=gnu99 -O2 -I/home/mark/dev/buildroot-rpi/output/host/usr/include -L/home/mark/dev/buildroot-rpi/output/host/lib -L/home/mark/dev/buildroot-rpi/output/host/usr/lib -Wl,-rpath,/home/mark/dev/buildroot-rpi/output/host/usr/lib -o m4 m4.o
Quoted 6 lines
builtin.o debug.o eval.o format.o freeze.o input.o macro.o output.o path.o symtab.o ../lib/libm4.a
m4.o: In function `main':
m4.c:(.text.startup+0x260): undefined reference toversion_etc' m4.c:(.text.startup+0x3ef): undefined reference toemit_bug_reporting_address'
This smells like it could be a ccache issue. Is it possible that you
had a major upgrade to your compiler since the first time you made a build?
Can you try with
make clean all BR2_CCACHE=
(or just edit your config to disable ccache).
Regards,
Arnout
Quoted 26 lines
collect2: error: ld returned 1 exit status
make[3]: *** [m4] Error 1
make[3]: Leaving directory `/home/mark/dev/buildroot-rpi/output/build/host-m4-1.4.16/src' make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/mark/dev/buildroot-rpi/output/build/host-m4-1.4.16' make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/mark/dev/buildroot-rpi/output/build/host-m4-1.4.16'
make: *** [/home/mark/dev/buildroot-rpi/output/build/host-m4-1.4.16/.stamp_built] Error 2Google doesn't help me on this.
Do you have any idea why this happens?Thanks
Mark_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
Il 27/01/2014 18:16, Arnout Vandecappelle ha scritto:
Quoted 3 lines
I guess you mean
make clean all
Yes of course, I apologize for the typo.
Quoted 3 lines
This smells like it could be a ccache issue. Is it possible that you had a major upgrade to your compiler since the first time you made a build?
It's very unlikely because I have a Debian shell and I didn't update anything during the day (just few hours between the two compilations).
Quoted 5 lines
Can you try with
make clean all BR2_CCACHE=
(or just edit your config to disable ccache).
Yeah! It did the trick!
I can't imagine it was a ccache problem because I deleted the whole directory and cloned again the repository from scratch - I thought it should reset anything to the initial state, my fault!
Thank you
Mark
Dear Marco Trapanese,
Quoted 4 lines · Marco Trapanese
Yeah! It did the trick!
I can't imagine it was a ccache problem because I deleted the whole directory and cloned again the repository from scratch - I thought it should reset anything to the initial state, my fault!
No, it doesn't. The cache of ccache is located in ~/.buildroot-ccache/, because the intent of ccache is precisely to be able to re-use the cache contents across complete rebuilds, and even across multiple clones of Buildroot.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Quoted 9 lines · Thomas Petazzoni
Dear Marco Trapanese,
Quoted 4 lines · Marco Trapanese
Yeah! It did the trick!
I can't imagine it was a ccache problem because I deleted the whole directory and cloned again the repository from scratch - I thought it should reset anything to the initial state, my fault!
Quoted 4 lines
No, it doesn't. The cache of ccache is located in ~/.buildroot-ccache/, because the intent of ccache is precisely to be able to re-use the cache contents across complete rebuilds, and even across multiple clones of Buildroot.
But this is yet another proof that it doesn't work very well. And this
one really worries me, because it's a host build that failed.
Marco, can you try to remember exactly what was different between the
first and second build? Was it the same buildroot source, the same buildroot config, etc.?
Regards,
Arnout
Signature · 6 lines
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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
Il 29/01/2014 08:14, Arnout Vandecappelle ha scritto:
Quoted 3 lines
Marco, can you try to remember exactly what was different between the
first and second build? Was it the same buildroot source, the same buildroot config, etc.?
Here what I did:
in the morning
1) cd ~
2) git clone git://github.com/albertd/buildroot-rpi
3) cd buildroot-rpi
4) make rpi_defconfig
5) make menuconfig (but I changed nothing)
6) make
7) burned the sd-card and play a while with the RPi
in the afternoon
after I discovered the error about eglfs which prevents any Qt application from running I tried to rebuild:
8) make clean all
9) make rpi_defconfig
10) make
*** here the error I described in the previous messages
11) rm -rf ~/buildroot-rpi
12) then I repeated the points 2-6 with the same errors during make
I'm sure I didn't upgraded any package of my Debian machine.
Maco
Dear Arnout Vandecappelle,
Quoted 7 lines · Arnout Vandecappelle
Quoted 4 lines
No, it doesn't. The cache of ccache is located in ~/.buildroot-ccache/, because the intent of ccache is precisely to be able to re-use the cache contents across complete rebuilds, and even across multiple clones of Buildroot.
But this is yet another proof that it doesn't work very well. And this
one really worries me, because it's a host build that failed.
And for what it worth just two days ago, one of my colleague also had a weird compilation problem while building host-gettext (the link step was complaining because one of the object file it was given was built for i386, while the host machine is x86-64, and therefore the link was failing). The problem was reproducible even after a complete 'make clean all' cycle. And it turned out that clearing the cache solved the problem, so it was indeed a mis re-use of an existing object file.
And it was also on the build of a host package, which is really weird. We know that our ccache handling is far from perfect in terms of detecting a change of the target compiler, but I wasn't aware of any theoretical problem regarding the build of host packages.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Quoted 20 lines · Thomas Petazzoni
Dear Arnout Vandecappelle,
Quoted 7 lines · Arnout Vandecappelle
Quoted 4 lines
No, it doesn't. The cache of ccache is located in ~/.buildroot-ccache/, because the intent of ccache is precisely to be able to re-use the cache contents across complete rebuilds, and even across multiple clones of Buildroot.
But this is yet another proof that it doesn't work very well. And this
one really worries me, because it's a host build that failed.And for what it worth just two days ago, one of my colleague also had a weird compilation problem while building host-gettext (the link step was complaining because one of the object file it was given was built for i386, while the host machine is x86-64, and therefore the link was failing). The problem was reproducible even after a complete 'make clean all' cycle. And it turned out that clearing the cache solved the problem, so it was indeed a mis re-use of an existing object file.
Quoted 4 lines
And it was also on the build of a host package, which is really weird. We know that our ccache handling is far from perfect in terms of detecting a change of the target compiler, but I wasn't aware of any theoretical problem regarding the build of host packages.
If you encounter this again, it would be worthwhile to save the object
file produced by ccache and then to try find where it was originally produced... CCACHE_LOGFILE can help.
Regards,
Arnout
Signature · 6 lines
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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
[Buildroot] udev and serial port
Hello,
in my buildroot environment I have udev enabled. I need to connect some UART-to-USB converter based upon FTDI chip (I added the libftdi in the config).
When I plug-in the converter to my target dmesg see the new hardware but I can't see any /dev/ttyUSB device.
Do I need to add something other in the configuration? Where should I search information about this "how-to"?
Thanks
Marco
[Buildroot] udev and serial port
Quoted 5 lines · Marco Trapanese
Hello,
in my buildroot environment I have udev enabled. I need to connect some UART-to-USB converter based upon FTDI chip (I added the libftdi in the config).
Quoted 8 lines
When I plug-in the converter to my target dmesg see the new hardware but I can't see any
/dev/ttyUSBdevice.Do I need to add something other in the configuration? Where should I search information about this "how-to"?
Thanks
Marco
Hi.
libftdi is for direct access to FTDI chips from applications. This is used for GPIO, bitbanging, SPI and other purposes. What you want is to enable the CONFIG_USB_SERIAL_FTDI_SIO knob in your linux kernel config.
Regards.
[Buildroot] udev and serial port
Il 30/01/2014 14:51, Gustavo Zacarias ha scritto:
Quoted 4 lines
Hi. libftdi is for direct access to FTDI chips from applications. This is used for GPIO, bitbanging, SPI and other purposes. What you want is to enable the
CONFIG_USB_SERIAL_FTDI_SIOknob in your linux kernel config. Regards.
My board/arm/rpi/linux.config have not such an item. I see:
# CONFIG_USB_SERIAL is not set
which I think I should turn on.
I can add by myself CONFIG_USB_SERIAL_FTDI_SIO=y?
Marco
[Buildroot] udev and serial port
Il 30/01/2014 15:16, Marco Trapanese ha scritto:
Quoted 4 lines
#
CONFIG_USB_SERIALis not setwhich I think I should turn on.
I can add by myselfCONFIG_USB_SERIAL_FTDI_SIO=y?
Don't worry, I found the entries using make linux-menuconfig (I had to disable again the ccache to show the menu).
Now it's compiling...
Thanks
Marco