Hi,

> Am 30.07.2018 um 15:50 schrieb Christophe Lyon <christophe.lyon@linaro.org>:
>
>> On Wed, 25 Jul 2018 at 07:20, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote:
>>
>> 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.
>
> It looks like tests are looping with getty error messages, is that what you saw?

Yes.

>> So there is still some regression for arm and ELF.
>>
>> Any idea?
> Not yet.
>
> How can I run embedded-test.sh twice with different uclibc-ng version?
> (the original one, and the one with my patches)
> Should I restart from a new directory?

exactly.

best regards
 Waldemar
>
>> best regards
>> Waldemar
>>
>>> Am 20.07.2018 um 10:25 schrieb Waldemar Brodkorb <wbx@uclibc-ng.org>:
>>>
>>> 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
>>>
>>>>> Am 20.07.2018 um 10:06 schrieb Christophe Lyon <christophe.lyon@linaro.org>:
>>>>>
>>>>> On Thu, 19 Jul 2018 at 20:15, Waldemar Brodkorb <wbx@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@linaro.org>:
>>>>>>
>>>>>> On Thu, 19 Jul 2018 at 14:33, Waldemar Brodkorb
>>>>>> <mail@waldemar-brodkorb.de> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>> Christophe Lyon wrote,
>>>>>>>
>>>>>>>>> On Wed, 18 Jul 2018 at 18:37, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> Christophe Lyon wrote,
>>>>>>>>>
>>>>>>>>>>> On Wed, 18 Jul 2018 at 09:37, Waldemar Brodkorb <wbx@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
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel@uclibc-ng.org
>>> https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
>>
>