[Buildroot] Open bug analysis

[Buildroot] Open bug analysis

[Thomas De Schampheleire]

Hi,

Here is again an overview of some open bugs. Hopefully we can resolve
them by looking at them collectively.

Doing a Buildroot build from /usr doesn't work
https://bugs.busybox.net/show_bug.cgi?id=5750
ThomasP, you are assigned to this bug. Have you done an analysis about
this in the past? What are the reasons for these problems?


Dbus and /var/run management
https://bugs.busybox.net/show_bug.cgi?id=5420
Here I don't see what the problem is. It is about the creation of
/var/run/dbus while /var/run is a symlink to /tmp. Looking at the
code, I don't see how it can be a problem (which I responded in the
bug report). Unless someone can explain what is going wrong exactly, I
would propose to close this (Resolved/Worksforme for example)


binutils-2.23.2/gas fails with undefined reference to `mbstowcs'
https://bugs.busybox.net/show_bug.cgi?id=6218
The submitter did not respond to questions from ThomasP. The bug
report hardly contains any info.
I tried building an internal toolchain for arm7tdmi, using
binutils-2.23.2, and binutils built fine.
My proposal is to close this bug to Resolved/Worksforme.


binutils-2.23.2/bfd fails with undefined reference to __fini_array_end
https://bugs.busybox.net/show_bug.cgi?id=6236
Same submitter as last patch, but about 10 days later. Logically, if
the first problem is reproducible, one couldn't get a second problem
unless the first one is fixed... So I have my doubts about this. As
said above, I tried building binutils in this configuration (with and
without MMU support) and this succeeded.


Cannot compile gcc without threads (uClibc-based)
https://bugs.busybox.net/show_bug.cgi?id=6230
I tried reproducing this problem, and the build indeed fails, but even
with the proposed modified uclibc config file. So my conclusion is
that this is a real bug that we need to look at.


Support for kernel signed modules
https://bugs.busybox.net/show_bug.cgi?id=6764
This bug report has a patch attached, and both Yann and me asked the
submitter to send it to the list, but without response. It's still
pretty recent though, so hopefully the submitter comes back to us. If
not, someone could adopt it and resend to the list.


procps Unknown HZ value! (XX) Assume 100.
https://bugs.busybox.net/show_bug.cgi?id=6626
ThomasP proposed to replace procps with procps-ng, the submitter
provided a patch, but did not send it to the list.
Note: this is the same submitted as the previous bug.


systemd error: static declaration of 'execvpe' follows non-static
declaration (uClibc)
https://bugs.busybox.net/show_bug.cgi?id=6776
ThomasP proposed a patch on the list yesterday to fix this problem in 2014.02.


toolchainfile.cmake has absolut path references
https://bugs.busybox.net/show_bug.cgi?id=6818
This bug contains a patch, and again the question was raised whether
the submitter could send it to the list instead. In the mean time it
was sent, so I closed the bug so the patch can follow the standard
patch review process. Is this ok? I marked it as Resolved/Fixed, which
is not the best state, but I couldn't find a better state...


Checking external toolchain for eabihf
https://bugs.busybox.net/show_bug.cgi?id=6842
ThomasP: the bug report refers to a small patch, could you have a look at it?



Runtime problems:

Running udhcpc on a system with NFS root kills NFS
https://bugs.busybox.net/show_bug.cgi?id=4790


Boot hangs when starting samba if BR2_ENABLE_LOCALE is enabled
https://bugs.busybox.net/show_bug.cgi?id=5396


Busybox compiled from buildroot hangs on pass from intiramfs to init
https://bugs.busybox.net/show_bug.cgi?id=6794
The submitter claims that stripping the busybox binary causes
incorrect runtime behavior. I asked for more info, but no response
yet.


Thanks all for your feedback,
Thomas

[Buildroot] Open bug analysis

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Thu, 13 Feb 2014 16:30:37 +0100, Thomas De Schampheleire wrote:

> Doing a Buildroot build from /usr doesn't work
> https://bugs.busybox.net/show_bug.cgi?id=5750
> ThomasP, you are assigned to this bug. Have you done an analysis about
> this in the past? What are the reasons for these problems?

The main problem I had identified was our logic to fixup the .la files.
To fix it, I had written:

-               $$(SED) "s:\(['= ]\)/usr:\\1$(STAGING_DIR)/usr:g" $$$$i; \
+               $$(SED) "\:['= ]$(STAGING_DIR)/usr:!s:\(['= ]\)/usr:\\1$(STAGING_DIR)/usr:g" $$$$i; \

but I believe it still wasn't working properly, because the staging
directory was being re-prefixed everytime this was executed on all .la
files. But I may not necessarily remember all the details.

> binutils-2.23.2/gas fails with undefined reference to `mbstowcs'
> https://bugs.busybox.net/show_bug.cgi?id=6218
> The submitter did not respond to questions from ThomasP. The bug
> report hardly contains any info.
> I tried building an internal toolchain for arm7tdmi, using
> binutils-2.23.2, and binutils built fine.
> My proposal is to close this bug to Resolved/Worksforme.

I agree with this proposal.

> binutils-2.23.2/bfd fails with undefined reference to __fini_array_end
> https://bugs.busybox.net/show_bug.cgi?id=6236
> Same submitter as last patch, but about 10 days later. Logically, if
> the first problem is reproducible, one couldn't get a second problem
> unless the first one is fixed... So I have my doubts about this. As
> said above, I tried building binutils in this configuration (with and
> without MMU support) and this succeeded.
> 
> 
> Cannot compile gcc without threads (uClibc-based)
> https://bugs.busybox.net/show_bug.cgi?id=6230
> I tried reproducing this problem, and the build indeed fails, but even
> with the proposed modified uclibc config file. So my conclusion is
> that this is a real bug that we need to look at.

Then it should be investigated a bit more :)

> Support for kernel signed modules
> https://bugs.busybox.net/show_bug.cgi?id=6764
> This bug report has a patch attached, and both Yann and me asked the
> submitter to send it to the list, but without response. It's still
> pretty recent though, so hopefully the submitter comes back to us. If
> not, someone could adopt it and resend to the list.

Yes, I remember looking at this patch, and looking a bit inside the
kernel for some details about why signed modules cannot be stripped. If
I remember correctly, it is indeed true that they cannot be stripped.
It's a bit annoying if they are built with debugging symbols...

> procps Unknown HZ value! (XX) Assume 100.
> toolchainfile.cmake has absolut path references
> https://bugs.busybox.net/show_bug.cgi?id=6818
> This bug contains a patch, and again the question was raised whether
> the submitter could send it to the list instead. In the mean time it
> was sent, so I closed the bug so the patch can follow the standard
> patch review process. Is this ok? I marked it as Resolved/Fixed, which
> is not the best state, but I couldn't find a better state...

Yes, marked it as resolved, I'd say.

> Checking external toolchain for eabihf
> https://bugs.busybox.net/show_bug.cgi?id=6842
> ThomasP: the bug report refers to a small patch, could you have a look at it?

Will try to get to it.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Open bug analysis

[Thomas De Schampheleire]

Hi Thomas,

Thanks for your feedback...

On Thu, Feb 13, 2014 at 7:52 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Thu, 13 Feb 2014 16:30:37 +0100, Thomas De Schampheleire wrote:
>
>> Doing a Buildroot build from /usr doesn't work
>> https://bugs.busybox.net/show_bug.cgi?id=5750
>> ThomasP, you are assigned to this bug. Have you done an analysis about
>> this in the past? What are the reasons for these problems?
>
> The main problem I had identified was our logic to fixup the .la files.
> To fix it, I had written:
>
> -               $$(SED) "s:\(['= ]\)/usr:\\1$(STAGING_DIR)/usr:g" $$$$i; \
> +               $$(SED) "\:['= ]$(STAGING_DIR)/usr:!s:\(['= ]\)/usr:\\1$(STAGING_DIR)/usr:g" $$$$i; \
>
> but I believe it still wasn't working properly, because the staging
> directory was being re-prefixed everytime this was executed on all .la
> files. But I may not necessarily remember all the details.

I am trying to reproduce and fix this.
As mentioned on IRC, I'm currently using a slightly modified version
of the above .la fixing:

-               $$(SED) "s:\(['= ]\)/usr:\\1$(STAGING_DIR)/usr:g" $$$$i; \
+               $$(SED) "s:\(['=
]\)/usr/lib:\\1$(STAGING_DIR)/usr/lib:g" $$$$i; \
+               $$(SED) "s:\(['=
]\)/usr/local/lib:\\1$(STAGING_DIR)/usr/local/lib:g" $$$$i; \

I.e. instead of searching for /usr/something, only search for /usr/lib
as this is where all .la files are put.
I actually don't think we need the /usr/local/lib line.

I'm testing this with a randconfig, and it's been busy for a while
without any problem yet. I have good hopes.
It actually moves the problem, but I think that it is more acceptable
of not supporting buildroot inside /usr/lib then not supporting
buildroot in /usr entirely...

>
>> binutils-2.23.2/gas fails with undefined reference to `mbstowcs'
>> https://bugs.busybox.net/show_bug.cgi?id=6218
>> The submitter did not respond to questions from ThomasP. The bug
>> report hardly contains any info.
>> I tried building an internal toolchain for arm7tdmi, using
>> binutils-2.23.2, and binutils built fine.
>> My proposal is to close this bug to Resolved/Worksforme.
>
> I agree with this proposal.
>
>> binutils-2.23.2/bfd fails with undefined reference to __fini_array_end
>> https://bugs.busybox.net/show_bug.cgi?id=6236
>> Same submitter as last patch, but about 10 days later. Logically, if
>> the first problem is reproducible, one couldn't get a second problem
>> unless the first one is fixed... So I have my doubts about this. As
>> said above, I tried building binutils in this configuration (with and
>> without MMU support) and this succeeded.

Thanks, bugs closed.

>>
>>
>> Cannot compile gcc without threads (uClibc-based)
>> https://bugs.busybox.net/show_bug.cgi?id=6230
>> I tried reproducing this problem, and the build indeed fails, but even
>> with the proposed modified uclibc config file. So my conclusion is
>> that this is a real bug that we need to look at.
>
> Then it should be investigated a bit more :)

True :)

>
>> Support for kernel signed modules
>> https://bugs.busybox.net/show_bug.cgi?id=6764
>> This bug report has a patch attached, and both Yann and me asked the
>> submitter to send it to the list, but without response. It's still
>> pretty recent though, so hopefully the submitter comes back to us. If
>> not, someone could adopt it and resend to the list.
>
> Yes, I remember looking at this patch, and looking a bit inside the
> kernel for some details about why signed modules cannot be stripped. If
> I remember correctly, it is indeed true that they cannot be stripped.
> It's a bit annoying if they are built with debugging symbols...
>
>> procps Unknown HZ value! (XX) Assume 100.
>> toolchainfile.cmake has absolut path references
>> https://bugs.busybox.net/show_bug.cgi?id=6818
>> This bug contains a patch, and again the question was raised whether
>> the submitter could send it to the list instead. In the mean time it
>> was sent, so I closed the bug so the patch can follow the standard
>> patch review process. Is this ok? I marked it as Resolved/Fixed, which
>> is not the best state, but I couldn't find a better state...
>
> Yes, marked it as resolved, I'd say.
>
>> Checking external toolchain for eabihf
>> https://bugs.busybox.net/show_bug.cgi?id=6842
>> ThomasP: the bug report refers to a small patch, could you have a look at it?
>
> Will try to get to it.

Thanks!

Note to other developers: further feedback on the bug list I sent is
more than welcome!

Best regards,
Thomas

[Buildroot] Open bug analysis

[Arnout Vandecappelle]

On 13/02/14 19:52, Thomas Petazzoni wrote:
>> Support for kernel signed modules
>> > https://bugs.busybox.net/show_bug.cgi?id=6764
>> > This bug report has a patch attached, and both Yann and me asked the
>> > submitter to send it to the list, but without response. It's still
>> > pretty recent though, so hopefully the submitter comes back to us. If
>> > not, someone could adopt it and resend to the list.
> Yes, I remember looking at this patch, and looking a bit inside the
> kernel for some details about why signed modules cannot be stripped. If
> I remember correctly, it is indeed true that they cannot be stripped.
> It's a bit annoying if they are built with debugging symbols...
> 

 This is something that can only be solved on the kernel side, I think -
modules have to be stripped before signing. Up to now, the kernel didn't
need support for that because stripping was done by the packagers. But
now that module signing has been added, the kernel will have to do the
stripping.

 So I'd suggest to point the bug reporter to the maintainers of MODULES_SIG.

 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] Open bug analysis

[Arnout Vandecappelle]

On 14/02/14 21:39, Thomas De Schampheleire wrote:
> Hi Thomas,
> 
> Thanks for your feedback...
> 
> On Thu, Feb 13, 2014 at 7:52 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> > Dear Thomas De Schampheleire,
>> >
>> > On Thu, 13 Feb 2014 16:30:37 +0100, Thomas De Schampheleire wrote:
>> >
>>> >> Doing a Buildroot build from /usr doesn't work
>>> >> https://bugs.busybox.net/show_bug.cgi?id=5750
>>> >> ThomasP, you are assigned to this bug. Have you done an analysis about
>>> >> this in the past? What are the reasons for these problems?
>> >
>> > The main problem I had identified was our logic to fixup the .la files.
>> > To fix it, I had written:
>> >
>> > -               $$(SED) "s:\(['= ]\)/usr:\\1$(STAGING_DIR)/usr:g" $$$$i; \
>> > +               $$(SED) "\:['= ]$(STAGING_DIR)/usr:!s:\(['= ]\)/usr:\\1$(STAGING_DIR)/usr:g" $$$$i; \
>> >
>> > but I believe it still wasn't working properly, because the staging
>> > directory was being re-prefixed everytime this was executed on all .la
>> > files. But I may not necessarily remember all the details.
> I am trying to reproduce and fix this.
> As mentioned on IRC, I'm currently using a slightly modified version
> of the above .la fixing:
> 
> -               $$(SED) "s:\(['= ]\)/usr:\\1$(STAGING_DIR)/usr:g" $$$$i; \
> +               $$(SED) "s:\(['=
> ]\)/usr/lib:\\1$(STAGING_DIR)/usr/lib:g" $$$$i; \
> +               $$(SED) "s:\(['=
> ]\)/usr/local/lib:\\1$(STAGING_DIR)/usr/local/lib:g" $$$$i; \
> 
> I.e. instead of searching for /usr/something, only search for /usr/lib
> as this is where all .la files are put.
> I actually don't think we need the /usr/local/lib line.

 Just brainstorming here, but I think a more complete solution could be
something like:

$$(SED) -e "s:\(['= ]\)$(STAGING_DIR):\\1 at STAGING_DIR@:g" \
        -e "s:\(['= ]\)/usr:\\1$(STAGING_DIR)/usr:g" \
        -e "s:@STAGING_DIR@:$(STAGING_DIR):g" \
        $$$$i;



 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] Open bug analysis

[Thomas De Schampheleire]

Hi,

On Mon, Feb 17, 2014 at 6:46 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
[..]
>> As mentioned on IRC, I'm currently using a slightly modified version
>> of the above .la fixing:
>>
>> -               $$(SED) "s:\(['= ]\)/usr:\\1$(STAGING_DIR)/usr:g" $$$$i; \
>> +               $$(SED) "s:\(['=
>> ]\)/usr/lib:\\1$(STAGING_DIR)/usr/lib:g" $$$$i; \
>> +               $$(SED) "s:\(['=
>> ]\)/usr/local/lib:\\1$(STAGING_DIR)/usr/local/lib:g" $$$$i; \
>>
>> I.e. instead of searching for /usr/something, only search for /usr/lib
>> as this is where all .la files are put.
>> I actually don't think we need the /usr/local/lib line.
>
>  Just brainstorming here, but I think a more complete solution could be
> something like:
>
> $$(SED) -e "s:\(['= ]\)$(STAGING_DIR):\\1 at STAGING_DIR@:g" \
>         -e "s:\(['= ]\)/usr:\\1$(STAGING_DIR)/usr:g" \
>         -e "s:@STAGING_DIR@:$(STAGING_DIR):g" \
>         $$$$i;
>

I have yet to try this alternate proposal, but in the meantime I have
done several randpackage tests with the mentioned code, and this works
without problem apparently. I have changes in pkg-autotools.mk (fixup
of .la files), pkg-generic (fixup of .pc files), and qt5.

There is one wrong path that remains (but seems to cause no problem),
but this same problem is present in 'normal' buildroot builds outside
of /usr: several .la files contain strings of the form:
-L /path/to/buildroot/sysroot/path/to/buildroot/sysroot/usr/lib

I tracked down this issue: when asking pkgconf for the libs
corresponding to a certain dependency expression, it will add the
sysroot to those strings it thinks need it. This works fine when the
paths are /usr /usr/lib etc, but not in case the library dependency is
already a full path. For example, when gcrypt and gnutls are enabled,
libecore is compiled with: --with-libgcrypt-prefix=$(STAGING_DIR)/usr,
causing an absolute path to be present. This is later prefixed by
pkgconf with another instance of STAGING_DIR.

We could fix that by doing a SED on <staging>/<staging> too, and
replace it with just one <staging>. This would seem 'hacky' but
actually would fix incorrect paths.

Best regards,
Thomas

[Buildroot] Open bug analysis

[Arnout Vandecappelle]

On 19/02/14 17:02, Thomas De Schampheleire wrote:
> Hi,
> 
> On Mon, Feb 17, 2014 at 6:46 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> [..]
>>> As mentioned on IRC, I'm currently using a slightly modified version
>>> of the above .la fixing:
>>>
>>> -               $$(SED) "s:\(['= ]\)/usr:\\1$(STAGING_DIR)/usr:g" $$$$i; \
>>> +               $$(SED) "s:\(['=
>>> ]\)/usr/lib:\\1$(STAGING_DIR)/usr/lib:g" $$$$i; \
>>> +               $$(SED) "s:\(['=
>>> ]\)/usr/local/lib:\\1$(STAGING_DIR)/usr/local/lib:g" $$$$i; \
>>>
>>> I.e. instead of searching for /usr/something, only search for /usr/lib
>>> as this is where all .la files are put.
>>> I actually don't think we need the /usr/local/lib line.
>>
>>  Just brainstorming here, but I think a more complete solution could be
>> something like:
>>
>> $$(SED) -e "s:\(['= ]\)$(STAGING_DIR):\\1 at STAGING_DIR@:g" \
>>         -e "s:\(['= ]\)/usr:\\1$(STAGING_DIR)/usr:g" \
>>         -e "s:@STAGING_DIR@:$(STAGING_DIR):g" \
>>         $$$$i;
>>
> 
> I have yet to try this alternate proposal, but in the meantime I have
> done several randpackage tests with the mentioned code, and this works
> without problem apparently. I have changes in pkg-autotools.mk (fixup
> of .la files), pkg-generic (fixup of .pc files), and qt5.
> 
> There is one wrong path that remains (but seems to cause no problem),
> but this same problem is present in 'normal' buildroot builds outside
> of /usr: several .la files contain strings of the form:
> -L /path/to/buildroot/sysroot/path/to/buildroot/sysroot/usr/lib
> 
> I tracked down this issue: when asking pkgconf for the libs
> corresponding to a certain dependency expression, it will add the
> sysroot to those strings it thinks need it. This works fine when the
> paths are /usr /usr/lib etc, but not in case the library dependency is
> already a full path. For example, when gcrypt and gnutls are enabled,
> libecore is compiled with: --with-libgcrypt-prefix=$(STAGING_DIR)/usr,
> causing an absolute path to be present. This is later prefixed by
> pkgconf with another instance of STAGING_DIR.

 Seems to me that this should be solved in pkgconf itself, not by hacking
the .la files...

 Regards,
 Arnout

> 
> We could fix that by doing a SED on <staging>/<staging> too, and
> replace it with just one <staging>. This would seem 'hacky' but
> actually would fix incorrect paths.
> 
> Best regards,
> Thomas
> 
> 


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