25 Jul
2018
25 Jul
'18
5:20 a.m.
Hi,
the toolchain tests are finished successfully, but the armv5 runtime tests showing some
problems with getty and argv handling.
Can be seen with --test=libc in embedded-test.sh.
So there is still some regression for arm and ELF.
Any idea?
best regards
Waldemar
Am 20.07.2018 um 10:25 schrieb Waldemar Brodkorb
<wbx(a)uclibc-ng.org>rg>:
Hi,
sorry for the confusion.
I take care about the last failure.
The build runs further so, I give you feedback once it is finished.
I can squash the patch before pushing,
best regards
Waldemar
_______________________________________________
devel mailing list
devel(a)uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
Am
20.07.2018 um 10:06 schrieb Christophe Lyon <christophe.lyon(a)linaro.org>rg>:
On Thu, 19 Jul 2018 at 20:15, Waldemar Brodkorb <wbx(a)uclibc-ng.org> wrote:
Hi,
okay, that was already the next test
armv5-nommu-arm, which OpenADK needs to learn, as the default is fdpic now.
I'm not sure to understand; if by "now" you mean with my uclibc-ng
patch series, then no. At least not yet.
As said in the cover letter this patch series supports only armv7. And
as noticed by Thomas, it doesn't yet support armv7m.
The plan is definitely to support armv7m.
So you probably want to create a new config armv7-nommu-arm in your script.
Since I'm not familiar with this script nor openadk, I don't know what
this implies.
I thought you wanted to first make sure my uclibc-ng patch series
didn't break existing configs.
If you want to try fdpic mode, you'll need a recent GCC trunk + my GCC
patches (see link in cover letter). You also need recent binutils. I
don't know if/how your script handles that since I noticed "7.3.0" in
the GCC error messages you shared, which seems to indicate you are not
using the most recent GCC.
And also note that the GCC/binutils target name is arm-uclinuxfdpiceabi.
This will configure GCC is the right mode, no need to use flags such as -mfdpic.
Will you sent a complete patch with sob for the
previous error?
Which previous error? If you mean the latest you reported
involving
-mfdpic, then I hope my answer just above clarifies.
If you mean the broken armv5 build, then yes, but the patch I sent
recently only needs to be squashed with patch 4/32 "rtld: Add FDPIC
code for arm"
What the practice on this list? Shall I send v2 of patch 4/32 asap, on
rather wait for feedback on other patches and then send a v2 of the
whole series?
Thanks,
Christophe
best regards
Waldemar
Am 19.07.2018 um 18:31 schrieb Christophe Lyon
<christophe.lyon(a)linaro.org>rg>:
On Thu, 19 Jul 2018 at 14:33, Waldemar Brodkorb
<mail(a)waldemar-brodkorb.de> wrote:
>
> Hi,
> Christophe Lyon wrote,
>
>>> On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <wbx(a)uclibc-ng.org>
wrote:
>>>
>>> Hi,
>>> Christophe Lyon wrote,
>>>
>>>>> On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb
<wbx(a)uclibc-ng.org> wrote:
>>>>>
>>>>> Hi Christophe,
>>>>> Waldemar Brodkorb wrote,
>>>>>
>>>>>> Hi Christophe,
>>>>>>
>>>>>> i am doing a large testrun for the global changes and hopefully
push on monday or at least have some news. i am afk atm with just little access to a
computer.
>>>>>>
>>>>>
>>>>> ARM v5 soft eabi arm mode fails to compile, see the attached error
>>>>> log. You can check with embedded-test.sh if you like.
>>>>>
>>>>> Any idea? All patches appliend on top of master,
>>>>
>>>> Thanks for testing this configuration.
>>>>
>>>> I left FDPIC-only code activated unconditionally.
>>>>
>>>> Can you try the attached small patch?
>>>
>>> Even fixing this small typo in #endf it errors out.
>>>
>> OK, here is an updated version of the previous patch.
>
> Works for the ldso, but I think we need a symbol to differentiate
> between ELF and FDPIC.
> See attached error.
Strange, the build succeeded for me. I don't understand where this
-mfdpic option comes from?
It is not part of the patches I sent, unless I'm mistaken: it would be
"embedded" in GCC if configured for FDPIC, which is not the case in
this build for armv5.
>
>>>> I have an embedded-test.sh build running now. Sorry, I didn't know
>>>> about this script, I have used armv5 as arch, is it the one you meant?
>>>
>>> somthing like this, uclibc-ng is a directory including all patches:
>>> mksh embedded-test.sh --libc=uclibc-ng --libc-source=uclibc-ng --arch=armv5
--verbose
>>
>> Is there a way to avoid (re)creating all the source tarballs? It's taking
ages
>
> It only recreates uclibc-ng tarball. (or any git ones).
OK... I use git trees for binutils, gcc and linux ;(
> You can do on a failure:
> cd openadk
> make v
>
> best regards
> Waldemar