A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could have a packaged arm cross-toolchain that was useful (with glibc, it cannot build anything in userspace). It worked for a while, but lately, all builds have been failing with this error:
/usr/bin/arm-linux-gnu-ld: skipping incompatible /usr/lib/gcc/arm-linux-gnueabi/8/libgcc_eh.a when searching for -lgcc_eh
I've looked at it and poked it quite a bit locally, but I can't seem to get around that. I could really use some help to get this building again, ideally, updated to 2.28.
All my work is committed to git, no help will be refused.
Thanks in advance,
~tom
On 11/7/18 11:00 AM, Tom Callaway wrote:
A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could have a packaged arm cross-toolchain that was useful (with glibc, it cannot build anything in userspace)
This should have read "without glibc, it cannot build anything in userspace".
~tom
Reviving this. I do not have the time nor the energy to attempt to keep this going, so I am going to disable the shared bits in cross-gcc and kill off glibc-arm-linux-gnu. It's been broken for a while, so I doubt anyone will be seriously impacted by this. If you are, I suggest using this copr instead: https://copr.fedorainfracloud.org/coprs/lantw44/arm-linux-gnueabi-toolchain/
~tom
On Wed, Nov 7, 2018 at 11:02 AM Tom Callaway tcallawa@redhat.com wrote:
On 11/7/18 11:00 AM, Tom Callaway wrote:
A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could have a packaged arm cross-toolchain that was useful (with glibc, it cannot build anything in userspace)
This should have read "without glibc, it cannot build anything in userspace".
~tom
On Mon, 10 Jun 2019 at 16:46, Tom Callaway tcallawa@redhat.com wrote:
Reviving this. I do not have the time nor the energy to attempt to keep this going, so I am going to disable the shared bits in cross-gcc and kill off glibc-arm-linux-gnu. It's been broken for a while, so I doubt anyone will be seriously impacted by this.
Ah that's unfortunate. I've been working on something that could possibly make use of this, but I haven't quite reached the stage of testing this out with it, and since it wasn't in Rawhide, I hadn't taken much look into it.
I see that Debian has pretty much every cross version of libc6: https://packages.debian.org/search?keywords=libc6&searchon=names&sui...
What makes it so easy for them? / What makes it difficult for us? How can we make cross toolchains easier?
If you are, I suggest using this copr instead: https://copr.fedorainfracloud.org/coprs/lantw44/arm-linux-gnueabi-toolchain/
~tom
On Wed, Nov 7, 2018 at 11:02 AM Tom Callaway tcallawa@redhat.com wrote:
On 11/7/18 11:00 AM, Tom Callaway wrote:
A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could have a packaged arm cross-toolchain that was useful (with glibc, it cannot build anything in userspace)
This should have read "without glibc, it cannot build anything in userspace".
~tom
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Le mer. 12 juin 2019 à 10:50, Elliott Sales de Andrade quantum.analyst@gmail.com a écrit :
On Mon, 10 Jun 2019 at 16:46, Tom Callaway tcallawa@redhat.com wrote:
Reviving this. I do not have the time nor the energy to attempt to keep this going, so I am going to disable the shared bits in cross-gcc and kill off glibc-arm-linux-gnu. It's been broken for a while, so I doubt anyone will be seriously impacted by this.
Ah that's unfortunate. I've been working on something that could possibly make use of this, but I haven't quite reached the stage of testing this out with it, and since it wasn't in Rawhide, I hadn't taken much look into it.
I see that Debian has pretty much every cross version of libc6: https://packages.debian.org/search?keywords=libc6&searchon=names&sui...
What makes it so easy for them? / What makes it difficult for us? How can we make cross toolchains easier?
Probably time/human ressources. I would be interested in having a working cross compilation toolchain also (specially for case where 32bit linking is an issue like chromium or else). I have tried to work on some patches (including kernel-headers), but not had time to fully qualify the changes.
FYI, I've tried to contact the maintainer of the copr repo pointed by Tom, so far no answer. Looking at some of his copr contributions, he haven't found the right step to contribute to fedora main repository yet (also others topics). This is unfortunate and I fear this situation is going to increase with users kept in their copr projects...
On Wed, 12 Jun 2019 at 08:33, Nicolas Chauvet kwizart@gmail.com wrote:
Le mer. 12 juin 2019 à 10:50, Elliott Sales de Andrade quantum.analyst@gmail.com a écrit :
On Mon, 10 Jun 2019 at 16:46, Tom Callaway tcallawa@redhat.com wrote:
Reviving this. I do not have the time nor the energy to attempt to keep this going, so I am going to disable the shared bits in cross-gcc and kill off glibc-arm-linux-gnu. It's been broken for a while, so I doubt anyone will be seriously impacted by this.
Ah that's unfortunate. I've been working on something that could possibly make use of this, but I haven't quite reached the stage of testing this out with it, and since it wasn't in Rawhide, I hadn't taken much look into it.
I see that Debian has pretty much every cross version of libc6: https://packages.debian.org/search?keywords=libc6&searchon=names&sui...
What makes it so easy for them? / What makes it difficult for us? How can we make cross toolchains easier?
Probably time/human ressources. I would be interested in having a working cross compilation toolchain also (specially for case where 32bit linking is an issue like chromium or else). I have tried to work on some patches (including kernel-headers), but not had time to fully qualify the changes.
FYI, I've tried to contact the maintainer of the copr repo pointed by Tom, so far no answer. Looking at some of his copr contributions, he haven't found the right step to contribute to fedora main repository yet (also others topics).
To follow up here, I think one of the main issues is the lack of documentation/guidelines for this case. I've tried to review a cross-compiler (mspgcc) package, but rpmlint complains about a bunch of stuff (using lib not lib64, headers in non-devel packages, etc.) which may or may not be relevant to compilers. I _think_ that the package is doing the right thing, because it emulates gcc, but I don't _know_ that it is. And it seems like the Embedded SIG never answered...
So I can't say that's the case for this copr maintainer, but the package review for compilers might just seem too much trouble to be worth it.
This is unfortunate and I fear this situation is going to increase with users kept in their copr projects...
--
Nicolas (kwizart)
* Elliott Sales de Andrade:
On Mon, 10 Jun 2019 at 16:46, Tom Callaway tcallawa@redhat.com wrote:
Reviving this. I do not have the time nor the energy to attempt to keep this going, so I am going to disable the shared bits in cross-gcc and kill off glibc-arm-linux-gnu. It's been broken for a while, so I doubt anyone will be seriously impacted by this.
Ah that's unfortunate. I've been working on something that could possibly make use of this, but I haven't quite reached the stage of testing this out with it, and since it wasn't in Rawhide, I hadn't taken much look into it.
I see that Debian has pretty much every cross version of libc6: https://packages.debian.org/search?keywords=libc6&searchon=names&sui...
What makes it so easy for them? / What makes it difficult for us? How can we make cross toolchains easier?
They just did the work, like Fedora did for Windows.
The benefits that GNU/Linux cross-toolchains provide to Debian is greater than it would be on Fedora because most of Debian's development packages install header files and libraries into directories with multi-arch tuples, and dpkg supports installation of such packages from foreign architectures, using their package repositories. This means that the Debian cross-toolchain can use all these development packages, and Debian developers are not stuck with glibc/libstdc++ only for cross-builds.
Thanks, Florian
-
Elliott Sales de Andrade -
Florian Weimer -
Nicolas Chauvet -
Tom Callaway