[Buildroot] full rebuild and errors

[Buildroot] full rebuild and errors

[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

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

[Buildroot] full rebuild and errors

[Arnout Vandecappelle]

On 26/01/14 13:07, Marco Trapanese wrote:
> 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

?

>
> 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'

  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

> 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
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>


-- 
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] full rebuild and errors

[Marco Trapanese]

Il 27/01/2014 18:16, Arnout Vandecappelle ha scritto:
>  I guess you mean
>
> make clean all


Yes of course, I apologize for the typo.

> 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).

> 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

[Buildroot] full rebuild and errors

[Thomas Petazzoni]

Dear Marco Trapanese,

On Tue, 28 Jan 2014 21:24:47 +0100, Marco Trapanese wrote:

> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] full rebuild and errors

[Arnout Vandecappelle]

On 28/01/14 23:09, Thomas Petazzoni wrote:
> Dear Marco Trapanese,
>
> On Tue, 28 Jan 2014 21:24:47 +0100, Marco Trapanese wrote:
>
>> 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.

  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


-- 
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] full rebuild and errors

[Marco Trapanese]

Il 29/01/2014 08:14, Arnout Vandecappelle ha scritto:
>  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

[Buildroot] full rebuild and errors

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Wed, 29 Jan 2014 08:14:09 +0100, Arnout Vandecappelle wrote:

> > 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] full rebuild and errors

[Arnout Vandecappelle]

On 29/01/14 09:30, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Wed, 29 Jan 2014 08:14:09 +0100, Arnout Vandecappelle wrote:
>
>>> 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.

  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


-- 
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

[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).

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

[Gustavo Zacarias]

On 01/30/2014 10:45 AM, Marco Trapanese wrote:

> 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

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

[Marco Trapanese]

Il 30/01/2014 14:51, Gustavo Zacarias ha scritto:
> 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. 

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

[Marco Trapanese]

Il 30/01/2014 15:16, Marco Trapanese ha scritto:
> # CONFIG_USB_SERIAL is not set
>
> which I think I should turn on.
> I can add by myself CONFIG_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