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
