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