20 Jul
2018
20 Jul
'18
8:06 a.m.
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:
OK... I use git trees for
binutils, gcc and linux ;(
Hi,
Christophe Lyon wrote,
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.
> 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. >> 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). You can do on a failure:
cd openadk
make v
best regards
Waldemar