On Tue, 31 Jul 2018 at 14:58, Waldemar Brodkorb wbx@uclibc-ng.org wrote:
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.
Too bad, It's taking ages to regenerate the gcc and linux tarballs from
the git trees I provide (I saw tar+xz taking ~30 minutes during a 50 minutes full run of the script)
I wish I could run: embedded-test.sh --libc=uclibc-ng --os=linux --arch=armv5 --gcc-source=XXX --binutils-source=YYY --kernel-source=ZZZ --test=libc embedded-test.sh --libc=uclibc-ng --os=linux --arch=armv5 --libc-source=UUU --libc-version=fdpic --gcc-source=XXX --binutils-source=YYY --kernel-source=ZZZ --verbose --test=libc where the 2nd step would only build the new version of uclibc-ng and run the corresponding tests.
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