Openembedded and ld-linux-armhf.so.3

Openembedded and ld-linux-armhf.so.3

[Martin Ertsås]

Hi.

I'm working on a pandaboard with OMAP4460. Were trying to use the newest
PVR drivers, which conforms to the result that arose from
https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012

We have applied the patch at the bottom of that page gcc, and also a
patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf
instead of ld-linux. Problem is, this gives us a kernel panic when it
tries to run init. Linking ld-linux.so.3 to ld-linux-armhf.so.3 does not
work, and we're kind of in the dark as to what is missing.

We tried fixing this by renaming the toolchain to be
arm-none-linux-gnueabihf instead of arm-none-linux-gnueabi, as we heard
this might be a problem with hardfloats, but this needed a lot of extra
patches, and some patchwork on other packages like openssl and shadow.

My question is, are there any ongoing plans to fix this, and make sure
that if we have set hard float we make ld-linux-armhf in openembedded?

For the record we are using eglibc2.15 and gcc4.6 from openembedded-core.

Best regards
Martin Ertsaas

Re: Openembedded and ld-linux-armhf.so.3

[Mark Hatle]

On 4/27/12 7:38 AM, Martin Ertsås wrote:
> Hi.
>
> I'm working on a pandaboard with OMAP4460. Were trying to use the newest
> PVR drivers, which conforms to the result that arose from
> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>
> We have applied the patch at the bottom of that page gcc, and also a
> patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf
> instead of ld-linux. Problem is, this gives us a kernel panic when it
> tries to run init. Linking ld-linux.so.3 to ld-linux-armhf.so.3 does not
> work, and we're kind of in the dark as to what is missing.
>
> We tried fixing this by renaming the toolchain to be
> arm-none-linux-gnueabihf instead of arm-none-linux-gnueabi, as we heard
> this might be a problem with hardfloats, but this needed a lot of extra
> patches, and some patchwork on other packages like openssl and shadow.
>
> My question is, are there any ongoing plans to fix this, and make sure
> that if we have set hard float we make ld-linux-armhf in openembedded?
>
> For the record we are using eglibc2.15 and gcc4.6 from openembedded-core.

The ARM EABI + HF isn't well tested (to my knowledge) of oe-core.  I was under 
the impressions a few people did use it, and it was working successfully for 
them.  (Generally speaking people seem to agree that there is a place for ARM 
EABI + HF, but the performance increase to the couple of items where it helps is 
generally not worth the pain of incompatibility with the core ARM EABI.  Thus 
it's not used very much in OE.)

Could you verify that the stock configuration (without any of the changes you 
described above) is working and will boot w/o a kernel panic at init?

If so then it'll be easier to help you track down the particulars of the ld.so 
name change and related items.

--Mark

> Best regards
> Martin Ertsaas
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Openembedded and ld-linux-armhf.so.3

[Martin Ertsås]

On 04/27/12 17:04, Mark Hatle wrote:
> On 4/27/12 7:38 AM, Martin Ertsås wrote:
>> Hi.
>>
>> I'm working on a pandaboard with OMAP4460. Were trying to use the newest
>> PVR drivers, which conforms to the result that arose from
>> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>
>> We have applied the patch at the bottom of that page gcc, and also a
>> patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf
>> instead of ld-linux. Problem is, this gives us a kernel panic when it
>> tries to run init. Linking ld-linux.so.3 to ld-linux-armhf.so.3 does not
>> work, and we're kind of in the dark as to what is missing.
>>
>> We tried fixing this by renaming the toolchain to be
>> arm-none-linux-gnueabihf instead of arm-none-linux-gnueabi, as we heard
>> this might be a problem with hardfloats, but this needed a lot of extra
>> patches, and some patchwork on other packages like openssl and shadow.
>>
>> My question is, are there any ongoing plans to fix this, and make sure
>> that if we have set hard float we make ld-linux-armhf in openembedded?
>>
>> For the record we are using eglibc2.15 and gcc4.6 from 
>> openembedded-core.
>
> The ARM EABI + HF isn't well tested (to my knowledge) of oe-core.  I 
> was under the impressions a few people did use it, and it was working 
> successfully for them.  (Generally speaking people seem to agree that 
> there is a place for ARM EABI + HF, but the performance increase to 
> the couple of items where it helps is generally not worth the pain of 
> incompatibility with the core ARM EABI.  Thus it's not used very much 
> in OE.)
>
> Could you verify that the stock configuration (without any of the 
> changes you described above) is working and will boot w/o a kernel 
> panic at init?
>
> If so then it'll be easier to help you track down the particulars of 
> the ld.so name change and related items.
>
> --Mark
It does work without the said changes, but did see an error in my patch, 
which resulted in gcc linking to /lib/lib/ld-linux-armhf.so.3. I'm 
currently compiling with the fixed patch, but at work so I won't be able 
to see if that was the issue before I get to work on monday.

The problem with calling the toolchain arm-none-linux-gnueabihf will not 
be resolved by this though, but first thing for me now is to be able to 
use the ld-linux-armhf.

-- Martin
>
>> Best regards
>> Martin Ertsaas
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Openembedded and ld-linux-armhf.so.3

[Khem Raj]

On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsås <martiert@gmail.com> wrote:
> Hi.
>
> I'm working on a pandaboard with OMAP4460. Were trying to use the newest
> PVR drivers, which conforms to the result that arose from
> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>
> We have applied the patch at the bottom of that page gcc, and also a
> patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf
> instead of ld-linux. Problem is, this gives us a kernel panic when it
> tries to run init. Linking ld-linux.so.3 to ld-linux-armhf.so.3 does not
> work, and we're kind of in the dark as to what is missing.
>
> We tried fixing this by renaming the toolchain to be
> arm-none-linux-gnueabihf instead of arm-none-linux-gnueabi, as we heard
> this might be a problem with hardfloats, but this needed a lot of extra
> patches, and some patchwork on other packages like openssl and shadow.
>
> My question is, are there any ongoing plans to fix this, and make sure
> that if we have set hard float we make ld-linux-armhf in openembedded?
>
> For the record we are using eglibc2.15 and gcc4.6 from openembedded-core.

would you show the patches so I can take a look what you did and whats going on
>
> Best regards
> Martin Ertsaas
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Openembedded and ld-linux-armhf.so.3

[Martin Ertsås]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]

On 04/29/12 04:40, Khem Raj wrote:
> On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsås <martiert@gmail.com> wrote:
>> Hi.
>>
>> I'm working on a pandaboard with OMAP4460. Were trying to use the newest
>> PVR drivers, which conforms to the result that arose from
>> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>
>> We have applied the patch at the bottom of that page gcc, and also a
>> patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf
>> instead of ld-linux. Problem is, this gives us a kernel panic when it
>> tries to run init. Linking ld-linux.so.3 to ld-linux-armhf.so.3 does not
>> work, and we're kind of in the dark as to what is missing.
>>
>> We tried fixing this by renaming the toolchain to be
>> arm-none-linux-gnueabihf instead of arm-none-linux-gnueabi, as we heard
>> this might be a problem with hardfloats, but this needed a lot of extra
>> patches, and some patchwork on other packages like openssl and shadow.
>>
>> My question is, are there any ongoing plans to fix this, and make sure
>> that if we have set hard float we make ld-linux-armhf in openembedded?
>>
>> For the record we are using eglibc2.15 and gcc4.6 from openembedded-core.
> would you show the patches so I can take a look what you did and whats going on
Sure, the patches are attached.
>> Best regards
>> Martin Ertsaas
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


[-- Attachment #2: add-armhf-so.patch --]
[-- Type: text/x-patch, Size: 350 bytes --]

--- a/ports/sysdeps/arm/shlib-versions  2011-05-10 09:49:03.000000000 -0600
+++ b/ports/sysdeps/arm/shlib-versions  2012-04-13 22:52:46.790815748 -0600
@@ -1,4 +1,4 @@
 arm.*-.*-linux-gnueabi.*	DEFAULT			GLIBC_2.4

-arm.*-.*-linux-gnueabi.*	ld=ld-linux.so.3
+arm.*-.*-linux-gnueabi.*	ld=ld-linux-armhf.so.3
 arm.*-.*-linux.*	ld=ld-linux.so.2

[-- Attachment #3: handle-ld-linux-armhf-name.patch --]
[-- Type: text/x-patch, Size: 570 bytes --]

--- a/elf/dl-load.c      2012-04-14 12:11:37.000000000 +0000
+++ b/elf/dl-load.c   2012-04-15 00:39:36.558765502 +0000
@@ -2086,10 +2086,13 @@
	  soname = ((const char *) D_PTR (l, l_info[DT_STRTAB])
		    + l->l_info[DT_SONAME]->d_un.d_val);
	  if (strcmp (name, soname) != 0)
+#ifdef __arm__
+	    if (strcmp(name, "ld-linux.so.3") || strcmp(soname, "ld-linux-armhf.so.3"))
+#endif
	    continue;

	  /* We have a match on a new name -- cache it.  */
-	  add_name_to_object (l, soname);
+	  add_name_to_object (l, name);
	  l->l_soname_added = 1;
	}


[-- Attachment #4: arm-dynamic-linker.patch --]
[-- Type: text/x-patch, Size: 922 bytes --]

# DP: For ARM hard float, set the dynamic linker to
# DP: /lib/ld-linux-armhf.so.3.

diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..8c9d2e7 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,11 @@
 /* Use ld-linux.so.3 so that it will be possible to run "classic"
    GNU/Linux binaries on an EABI system.  */
 #undef  GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER SYSTEMLIBS_DIR "ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT "/lib/ld-linux-armhf.so.3"
+#define GLIBC_DYNAMIC_LINKER \
+   "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+    %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"

 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
    use the GNU/Linux version, not the generic BPABI version.  */

Re: Openembedded and ld-linux-armhf.so.3

[Khem Raj]

On Sun, Apr 29, 2012 at 11:00 PM, Martin Ertsås <martiert@gmail.com> wrote:
> Sure, the patches are attached.

these patches are not right. Drop the eglibc patches completely they are bogus
gcc patch you can take a look here

http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/misc&id=7cc84a60662f9f2f5a1ad0264e94cea8a6954cec

eglibc patches are still work in progress. I am working on something
but its not final yet

Re: Openembedded and ld-linux-armhf.so.3

[Khem Raj]

On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsås <martiert@gmail.com> wrote:
> I'm working on a pandaboard with OMAP4460. Were trying to use the newest
> PVR drivers, which conforms to the result that arose from
> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>
> We have applied the patch at the bottom of that page gcc, and also a
> patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf
> instead of ld-linux. Problem is, this gives us a kernel panic when it
> tries to run init.

interesting bits are why kernel panics ?
what error do you get from kernel ?
is it some illegal instruction or something like that ?
Do you have VFP enabled

Re: Openembedded and ld-linux-armhf.so.3

[Martin Ertsås]

On 05/01/12 00:05, Khem Raj wrote:
> On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsås<martiert@gmail.com>  wrote:
>> I'm working on a pandaboard with OMAP4460. Were trying to use the newest
>> PVR drivers, which conforms to the result that arose from
>> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>
>> We have applied the patch at the bottom of that page gcc, and also a
>> patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf
>> instead of ld-linux. Problem is, this gives us a kernel panic when it
>> tries to run init.
> interesting bits are why kernel panics ?
> what error do you get from kernel ?
> is it some illegal instruction or something like that ?
> Do you have VFP enabled
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Found out the problem why kernel panics. The patches I posted were the 
correct ones, but before this I used

SYSLIB_PATH or something before "/lib/ld-linux-armhf.so.3", so the 
output actually was /lib/lib/ld-linux-armhf.so.3

Re: Openembedded and ld-linux-armhf.so.3

[Khem Raj]

On Mon, Apr 30, 2012 at 11:44 PM, Martin Ertsås <martiert@gmail.com> wrote:
> On 05/01/12 00:05, Khem Raj wrote:
>>
>> On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsås<martiert@gmail.com>  wrote:
>>>
>>> I'm working on a pandaboard with OMAP4460. Were trying to use the newest
>>> PVR drivers, which conforms to the result that arose from
>>> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>>
>>> We have applied the patch at the bottom of that page gcc, and also a
>>> patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf
>>> instead of ld-linux. Problem is, this gives us a kernel panic when it
>>> tries to run init.
>>
>> interesting bits are why kernel panics ?
>> what error do you get from kernel ?
>> is it some illegal instruction or something like that ?
>> Do you have VFP enabled
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> Found out the problem why kernel panics. The patches I posted were the
> correct ones, but before this I used
>
> SYSLIB_PATH or something before "/lib/ld-linux-armhf.so.3", so the output
> actually was /lib/lib/ld-linux-armhf.so.3
>

ok good. I would be interested if you test the patchset i posted
it will help a lot

Re: Openembedded and ld-linux-armhf.so.3

[Martin Ertsås]

On 05/01/12 14:32, Khem Raj wrote:
> On Mon, Apr 30, 2012 at 11:44 PM, Martin Ertsås<martiert@gmail.com>  wrote:
>> On 05/01/12 00:05, Khem Raj wrote:
>>> On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsås<martiert@gmail.com>    wrote:
>>>> I'm working on a pandaboard with OMAP4460. Were trying to use the newest
>>>> PVR drivers, which conforms to the result that arose from
>>>> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>>>
>>>> We have applied the patch at the bottom of that page gcc, and also a
>>>> patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf
>>>> instead of ld-linux. Problem is, this gives us a kernel panic when it
>>>> tries to run init.
>>> interesting bits are why kernel panics ?
>>> what error do you get from kernel ?
>>> is it some illegal instruction or something like that ?
>>> Do you have VFP enabled
>>>
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>> Found out the problem why kernel panics. The patches I posted were the
>> correct ones, but before this I used
>>
>> SYSLIB_PATH or something before "/lib/ld-linux-armhf.so.3", so the output
>> actually was /lib/lib/ld-linux-armhf.so.3
>>
> ok good. I would be interested if you test the patchset i posted
> it will help a lot
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
I'll try them tomorrow and send a mail telling the findings.

Re: Openembedded and ld-linux-armhf.so.3

[Martin Ertsås]

On 05/01/12 14:32, Khem Raj wrote:
> On Mon, Apr 30, 2012 at 11:44 PM, Martin Ertsås <martiert@gmail.com> wrote:
>> On 05/01/12 00:05, Khem Raj wrote:
>>> On Fri, Apr 27, 2012 at 5:38 AM, Martin Ertsås<martiert@gmail.com>  wrote:
>>>> I'm working on a pandaboard with OMAP4460. Were trying to use the newest
>>>> PVR drivers, which conforms to the result that arose from
>>>> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>>>
>>>> We have applied the patch at the bottom of that page gcc, and also a
>>>> patch for making eglibc make ld-linux-armhf, and load ld-linux-armhf
>>>> instead of ld-linux. Problem is, this gives us a kernel panic when it
>>>> tries to run init.
>>> interesting bits are why kernel panics ?
>>> what error do you get from kernel ?
>>> is it some illegal instruction or something like that ?
>>> Do you have VFP enabled
>>>
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>> Found out the problem why kernel panics. The patches I posted were the
>> correct ones, but before this I used
>>
>> SYSLIB_PATH or something before "/lib/ld-linux-armhf.so.3", so the output
>> actually was /lib/lib/ld-linux-armhf.so.3
>>
> ok good. I would be interested if you test the patchset i posted
> it will help a lot
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
The patches posted seems to be working fine. I at least didn't have any
problems with them.

Re: Openembedded and ld-linux-armhf.so.3

[Khem Raj]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/02/2012 02:35 AM, Martin Ertsås wrote:
> The patches posted seems to be working fine. I at least didn't have
> any problems with them.


thanks for trying them out. GCC patch is final but eglibc patch I
still got to improve that its not final version yet.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+hocgACgkQuwUzVZGdMxQqaACaAtP9rzr8vBvn/Q0MgbPvevdS
iz4AmweHf2JC/QUsBq8N5tYvHQ0a4oAG
=c3Tt
-----END PGP SIGNATURE-----

Re: Openembedded and ld-linux-armhf.so.3

[Martin Ertsås]

On 05/02/12 23:06, Khem Raj wrote:
> On 05/02/2012 02:35 AM, Martin Ertsås wrote:
> > The patches posted seems to be working fine. I at least didn't have
> > any problems with them.
>
>
> thanks for trying them out. GCC patch is final but eglibc patch I
> still got to improve that its not final version yet.

No problem. Is there also plans for renaming the toolchains created to
arm-none-linux-gnueabihf when using hardfloats? Tried doing that, but
gcc failed first. Then, after patching up gcc like a madman as well as
adding linux-gnueabihf to the package_qa_get_machine_dict dictionary in
insane.bbclass, several other projects failed. Among them were openssl
and shadow as far as I remember. Probably others as well, but that's
where I gave up.

Cool, so this will be put upstream with gcc 4.7 and eglibc 2.15? Btw, I
was trying your patches with 4.6, not 4.7, as we have not attempted to
migrate right now. Will do that soon though, but not right now.

- Martin

>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Openembedded and ld-linux-armhf.so.3

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 03-05-12 08:48, Martin Ertsås schreef:
> On 05/02/12 23:06, Khem Raj wrote:
>> On 05/02/2012 02:35 AM, Martin Ertsås wrote:
>>> The patches posted seems to be working fine. I at least didn't have 
>>> any problems with them.
>> 
>> 
>> thanks for trying them out. GCC patch is final but eglibc patch I still
>> got to improve that its not final version yet.
> 
> No problem. Is there also plans for renaming the toolchains created to 
> arm-none-linux-gnueabihf when using hardfloats?

What's the point in that? Renaming the toolchain won't grant it magical
powers and setting a targetvendor is perfectly valid.

I've seen too many presentations this year at ELC and Collab where someone
says "renaming the toolchain fixed it" when they actually mean "using a
bare-metal toolchain for userspace doesn't really work".
Just look at the building the kernel with LLVM talk, a third of Marks
presentation was about challenges with calling the right toolchain with the
right arguments.

</rant>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJPojhnAAoJEHZqAkdh1vT63s0P/2yoPsNlXRcLHGfeH7SCtEHP
2fxZMUmxRzZjPF/rwqWCBwyHEseGtL15AfetHK2Ylvi+Pzw0Z+d5GpNlzwj4pBNo
JguZ6+4xo6Kd0mKxk9PN99ebcPYsQo23Hqs6Bpk6roYJNoBtmqUusZ/M0VoS+k/E
7KwUwYUjL1mONDpKWjPkuC2apkjjI/XQ/a9r0RlQ8qzKaMJDg8rJkRFV8Yzzrlxu
0DRjs+EyTjM/VUGXTxdnjsQwV4lbZC0bw9rZhISsXwG5JFEJVjkZ9pMMexqkAX7C
pE6YBWxAZ8g3ZAWd9AVwne4xR99xCPtYyqVr3smeEi+mxu+SLkZFaZvyFLhHsaBj
uRM9sKinrnnUdpWxCZ4qoNJ4j0h2tT7/wqBXsNyK5+0XmfJba58ZfyY2t8xSi4qn
d89gQ/iYTHCDpW+7Rogp5WNzhS2Y8a+ecvbP1zQHZitEfaA4TXUxB1x9hsqWVuT8
2RbVAIMgytCrj9sshdlAaWkFReF7CKSp7zMwn3FLCKFPLSsS7P260MQRWqpGJXjS
yPTaFgFeWBRbSOMtg8l2LP5gDVuyg1BrdmiRVycX/gOgj4ZTfMPOooyAWttVMj95
4cZO1yiCU4de8Fd2+8QW4KrUJhnKcI+pHZn0pP4qHMuKUoh+o0dbCz/O7OCK9now
VqIPweynKVrQ5SF8ZhYa
=F3G4
-----END PGP SIGNATURE-----

Re: Openembedded and ld-linux-armhf.so.3

[Martin Ertsås]

On 05/03/12 09:48, Koen Kooi wrote:
> Op 03-05-12 08:48, Martin Ertsås schreef:
> > On 05/02/12 23:06, Khem Raj wrote:
> >> On 05/02/2012 02:35 AM, Martin Ertsås wrote:
> >>> The patches posted seems to be working fine. I at least didn't have
> >>> any problems with them.
> >>
> >>
> >> thanks for trying them out. GCC patch is final but eglibc patch I still
> >> got to improve that its not final version yet.
>
> > No problem. Is there also plans for renaming the toolchains created to
> > arm-none-linux-gnueabihf when using hardfloats?
>
> What's the point in that? Renaming the toolchain won't grant it magical
> powers and setting a targetvendor is perfectly valid.
>
> I've seen too many presentations this year at ELC and Collab where someone
> says "renaming the toolchain fixed it" when they actually mean "using a
> bare-metal toolchain for userspace doesn't really work".
> Just look at the building the kernel with LLVM talk, a third of Marks
> presentation was about challenges with calling the right toolchain
> with the
> right arguments.
>
> </rant>

Fair point, I was just told that some packages might look at the name of
the toolchain, and perhaps not give the optimal path for hard floats
with the name of linux-gnueabi. Clearly some packages do actually look
at the name of the toolchain, but for most cases at least, the only
difference will be the hardfloat flag given to the compiler. Also seen
quite a few toolchains using hardfloats which has the hf prefix, to show
that this is actually a hardfloat toolchain.

>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Openembedded and ld-linux-armhf.so.3

[Khem Raj]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/03/2012 12:51 AM, Martin Ertsås wrote:
> Fair point, I was just told that some packages might look at the
> name of the toolchain, and perhaps not give the optimal path for
> hard floats with the name of linux-gnueabi. Clearly some packages
> do actually look at the name of the toolchain, but for most cases
> at least, the only difference will be the hardfloat flag given to
> the compiler. Also seen quite a few toolchains using hardfloats
> which has the hf prefix, to show that this is actually a hardfloat
> toolchain.

some distros may rely on triplet and if it makes into gcc and gcc
starts relying on it we will have to reconsider but at present I dont
see a need to change triplet
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+ijYMACgkQuwUzVZGdMxQoGACfSjsIVwB+uPW/cDbtUbQR87oC
r/gAniC35ygSHDUIe0O1urrsO/w+gcEl
=ZLo8
-----END PGP SIGNATURE-----

Re: Openembedded and ld-linux-armhf.so.3

[Khem Raj]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/27/2012 05:38 AM, Martin Ertsås wrote:
> Hi.
> 
> I'm working on a pandaboard with OMAP4460. Were trying to use the
> newest PVR drivers, which conforms to the result that arose from 
> https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>
>  We have applied the patch at the bottom of that page gcc, and also
> a patch for making eglibc make ld-linux-armhf, and load
> ld-linux-armhf instead of ld-linux. Problem is, this gives us a
> kernel panic when it tries to run init. Linking ld-linux.so.3 to
> ld-linux-armhf.so.3 does not work, and we're kind of in the dark as
> to what is missing.
> 
> We tried fixing this by renaming the toolchain to be 
> arm-none-linux-gnueabihf instead of arm-none-linux-gnueabi, as we
> heard this might be a problem with hardfloats, but this needed a
> lot of extra patches, and some patchwork on other packages like
> openssl and shadow.
> 
> My question is, are there any ongoing plans to fix this, and make
> sure that if we have set hard float we make ld-linux-armhf in
> openembedded?
> 
> For the record we are using eglibc2.15 and gcc4.6 from
> openembedded-core.
> 

OK, I have cooked up something that you can try the top three patches on

http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc

is what you will need and make sure that you choose a tuning which asks
for callconvention-hard

- -Khem
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+fb1MACgkQuwUzVZGdMxR2GQCgije/XES//4BWCHk8tXvXqA84
ugAAn0nXozwW8mCpqlmEcy1XhPt3lyFF
=tC7M
-----END PGP SIGNATURE-----