Re: Segmentation fault in __uClibc_main on m68k
On July 31, 2015 9:59:48 AM GMT+02:00, Thorsten Glaser wrote: >On Thu, 30 Jul 2015, Bernhard Reutner-Fischer wrote: > >> We are happy to take tested patches to update stuff for sure! > >Hm, okay. All my patches go via Waldemar, who’s the one having >the hardware and tests anyway. They then end up in µClibc-ng. >Make out of that what you want… I’m not the user, just the low- >level hacker helping out. > >bye, >//mirabilos >-- >Yes, I hate users and I want them to suffer. > -- Marco d'Itri on gmane.linux.debian.devel.general Well, I don't. Choose your weapons. ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
On July 27, 2015 11:15:40 AM GMT+02:00, Thorsten Glaser wrote: >Rob Landley landley.net> writes: > >> support, a tangled mess of headers copied from random glibc >snapshots, > >Not to mention lack of later bugfixes from glibc. > >> was never a priority because glibc was inherently so much worse that >> just not being a gnu project made it smell like roses in comparison. >I >> complained about this crap over the course of many years. I didn't >stop > >glibc still stinks, but µClibc(-ng) stinks like an old glibc >in many parts. (I fixed several deep bugs and incompatibilities >with current compilers in it for wbx, despite telling him to just >use musl instead, so I know.) Lots of files claim they are part >of glibc, yet they have bugs glibc fixed, so, all the bad of it >without all the good of it. > >bye, >//mirabilos (who’s fixed bugs in all Linux libcs except musl, so far) We are happy to take tested patches to update stuff for sure! This is a community driven project since ages now. Send your patches and contribute or don't and just use it if it works fine for you, it's that simple. If you regularly contribute several good patches we remove the filter by giving you instamt write access, see http://uclibc.org/developing.html#contrib TIA and cheers, ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
Rob Landley landley.net> writes: > support, a tangled mess of headers copied from random glibc snapshots, Not to mention lack of later bugfixes from glibc. > was never a priority because glibc was inherently so much worse that > just not being a gnu project made it smell like roses in comparison. I > complained about this crap over the course of many years. I didn't stop glibc still stinks, but µClibc(-ng) stinks like an old glibc in many parts. (I fixed several deep bugs and incompatibilities with current compilers in it for wbx, despite telling him to just use musl instead, so I know.) Lots of files claim they are part of glibc, yet they have bugs glibc fixed, so, all the bad of it without all the good of it. bye, //mirabilos (who’s fixed bugs in all Linux libcs except musl, so far) ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
On 06/08/2015 10:35 AM, Thomas Petazzoni wrote: > Waldemar, Rob, > > On Sat, 30 May 2015 10:06:08 +0200, Waldemar Brodkorb wrote: > >>> Remember when buildroot announced they would switch their default libc >>> if the uClibc developers couldn't get a new release out? Remember how >>> that was over a year ago, ala >>> http://lists.busybox.net/pipermail/uclibc/2014-February/048252.html ? >>> Well instead what happened was >>> http://lists.busybox.net/pipermail/buildroot/2013-October/079661.html >>> became >>> http://git.buildroot.net/buildroot/commit/?id=c29799330464fb5d152f1b3d550fcbda69c58a3d >>> which became >>> https://www.phoronix.com/scan.php?page=news_item&px=Musl-Libc-GCC-Support >>> and at this point it's pretty much over except the cleanup. They >>> didn't _announce_ a migration, they just did it. At this point if >>> uClibc had a new release I expect they'd smile and nod and _continue_ >>> not to care because there are better alternatives now, once that >>> haven't established a pattern of chronic multi-year development >>> constipation. >> >> That is not correct. They did not silently migrate to musl. >> Musl is a choice like Gnu Libc in their buildsystem. >> >> They will migrate in the next release cycle, but they migrate to >> uClibc-ng as default C library for their system. > > Correct. Contrary to what Rob said, we (Buildroot) have only added > support for Musl, not switched to it as our default C library. Indeed. I wasn't trying to speak for the project, just saying that all the buildroot users I know moved over already. (Not all to musl, some went to glibc.) > We > actually discussed switching to glibc as the default C library, but > never to musl. We want to offer the option of using musl, but for the > moment not as the default. Also our musl support is still experimental, > and there are lots of packages in Buildroot that do not yet build with > musl. > > However, we are indeed quite desperate about the state of uClibc and > the lack of stable releases. Which is why I've personally encouraged > Waldemar to do the uClibc-ng project, Buildroot offers the option of > using uClibc-ng, and I will propose to make that the default C library > choice in the next Buildroot release. I see another uClibc fork as increasing fragmentation. Manuel Nova had a fork. S.J. Hill had a fork. Peter Mazinger had a fork. Mike Frysinger had a fork. The Code Sourcery guys had a fork. "Let's try to fix uclibc by forking it" was the approach people tried back in 2007. It didn't work then, I don't see why it would work better now. There are still _three_ threading implementations, incoherent locale support, a tangled mess of headers copied from random glibc snapshots, the kconfig in current git _still_ has "Manuel's Hidden Warnings", the root of the Kconfig tree is "extra/Configs" which you just have to _know_ (what does "extra" mean in this context, "cannot compile this without?"), there's still the HAS_MMU/USE_MMU nonsense (both showing up in "target architecture features and options" when it's just one choice: you've either enabled mmu support or you haven't)... People have been working at cross-purposes in uclibc for many years, abandoning half-finished projects that never got removed, and cleanup was never a priority because glibc was inherently so much worse that just not being a gnu project made it smell like roses in comparison. I complained about this crap over the course of many years. I didn't stop complaining because it got fixed, but because an alternative appeared that was neither a giant mass of scar tissue nor moribund. That said, I can see the appeal of uclibc-ng for buildroot: you've effectively already _been _maintaining your own uClibc fork for years, and migrating a major system component is painful and disruptive. Heck, a huge amount of your build plumbing is running sed against uclibc config symbols, just cleaning that _out_ for something like musl would be quite the chore. But the potential userbase of uclibc-ng is a subset of the historical userbase of uclibc. (Explaining to a newbie why after they select NPTL they can still select PTHREADS_DEBUG_SUPPORT in the giant forest of overcomplicated Kconfig plumbing is not a task for the weak of stomach.) It's maintenance of legacy code, bionic or musl make way more sense for new deployments. > At this point, I don't think there's any hope for uClibc to ever do a > release. Even if they did, one release would not solve a chronic problem going back almost a full decade. Rob ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
Waldemar, Rob, On Sat, 30 May 2015 10:06:08 +0200, Waldemar Brodkorb wrote: > > Remember when buildroot announced they would switch their default libc > > if the uClibc developers couldn't get a new release out? Remember how > > that was over a year ago, ala > > http://lists.busybox.net/pipermail/uclibc/2014-February/048252.html ? > > Well instead what happened was > > http://lists.busybox.net/pipermail/buildroot/2013-October/079661.html > > became > > http://git.buildroot.net/buildroot/commit/?id=c29799330464fb5d152f1b3d550fcbda69c58a3d > > which became > > https://www.phoronix.com/scan.php?page=news_item&px=Musl-Libc-GCC-Support > > and at this point it's pretty much over except the cleanup. They > > didn't _announce_ a migration, they just did it. At this point if > > uClibc had a new release I expect they'd smile and nod and _continue_ > > not to care because there are better alternatives now, once that > > haven't established a pattern of chronic multi-year development > > constipation. > > That is not correct. They did not silently migrate to musl. > Musl is a choice like Gnu Libc in their buildsystem. > > They will migrate in the next release cycle, but they migrate to > uClibc-ng as default C library for their system. Correct. Contrary to what Rob said, we (Buildroot) have only added support for Musl, not switched to it as our default C library. We actually discussed switching to glibc as the default C library, but never to musl. We want to offer the option of using musl, but for the moment not as the default. Also our musl support is still experimental, and there are lots of packages in Buildroot that do not yet build with musl. However, we are indeed quite desperate about the state of uClibc and the lack of stable releases. Which is why I've personally encouraged Waldemar to do the uClibc-ng project, Buildroot offers the option of using uClibc-ng, and I will propose to make that the default C library choice in the next Buildroot release. At this point, I don't think there's any hope for uClibc to ever do a release. Best regards, Thomas Petazzoni -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
On Sun, May 31, 2015 at 10:14 AM, Rich Felker wrote: > On Sat, May 30, 2015 at 01:28:42PM +0300, Max Filippov wrote: >> On Sat, May 30, 2015 at 1:12 PM, Rob Landley wrote: >> > I see a qemu-system-xtensa so might give that a try too. >> >> Please do. I'd be happy to answer any questions. >> I also hope to port musl to xtensa this year. > > Would you like to be involved in binfmt/toolchain discussions going on > now? I'm not sure how useful I may currently be as I've never used linux on noMMU xtensa systems, but I'd appreciate if you point me to these discussion threads so that I could follow. > My plan for nommu support with musl is to start with plain ELF, > ET_DYN (PIE) form only, with both static and dynamic linking > supported. This gives behavior identical to MMU-ful archs, but of > course with no text sharing. Then we can add FDPIC as needed to get > shared text; this requires both toolchain support and library/dynamic > linker runtime changes in musl. With musl being something of a clean > slate and aiming for minimal arch-specific code, I really don't want > to carry forward legacy binfmts and associated support code, but I do > want to understand if there are any particular properties of existing > binfmts/ABIs/etc. that are important to developers/users, and I'd > like to hear if you have any input on this from the Xtensa side. Ok, I'll try to find out and collect what we have. -- Thanks. -- Max ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
On Sun, May 31, 2015 at 2:14 AM, Rich Felker wrote: > On Sat, May 30, 2015 at 01:28:42PM +0300, Max Filippov wrote: >> On Sat, May 30, 2015 at 1:12 PM, Rob Landley wrote: >> > I see a qemu-system-xtensa so might give that a try too. >> >> Please do. I'd be happy to answer any questions. >> I also hope to port musl to xtensa this year. > > Would you like to be involved in binfmt/toolchain discussions going on > now? My plan for nommu support with musl is to start with plain ELF, > ET_DYN (PIE) form only, with both static and dynamic linking > supported. This gives behavior identical to MMU-ful archs, but of > course with no text sharing. Then we can add FDPIC as needed to get > shared text; this requires both toolchain support and library/dynamic > linker runtime changes in musl. With musl being something of a clean > slate and aiming for minimal arch-specific code, I really don't want > to carry forward legacy binfmts and associated support code, but I do > want to understand if there are any particular properties of existing > binfmts/ABIs/etc. that are important to developers/users, and I'd > like to hear if you have any input on this from the Xtensa side. > > Rich We have Jeff Dionne, founder of uclinux and developer of uc-libc (which Erik forked to make uClibc, do "git log | cat" and look at the next to last commit) contributing to the musl-sh2 discussion. I'm trying to get the thread restarted and the existing messages posted to the musl list so they're archived somewhere. Jeff's CEO of a tech start in Japan these days so _really_ busy, but still brilliant and the world's leading expert on a lot of nommu stuff if you can get his time. Not that I'm exactly unbiased here. He's my boss at $DAYJOB and I'm appearing on a panel with him and the original superh processor architect at linuxcon japan on thursday: http://lccojapan2015.sched.org/event/860288ccda595208a5d7337d31c6075c#.VWv3sR-1XVN Still, _that_ is the discussion you want to get in on... Rob ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
On Sat, May 30, 2015 at 01:28:42PM +0300, Max Filippov wrote: > On Sat, May 30, 2015 at 1:12 PM, Rob Landley wrote: > > I see a qemu-system-xtensa so might give that a try too. > > Please do. I'd be happy to answer any questions. > I also hope to port musl to xtensa this year. Would you like to be involved in binfmt/toolchain discussions going on now? My plan for nommu support with musl is to start with plain ELF, ET_DYN (PIE) form only, with both static and dynamic linking supported. This gives behavior identical to MMU-ful archs, but of course with no text sharing. Then we can add FDPIC as needed to get shared text; this requires both toolchain support and library/dynamic linker runtime changes in musl. With musl being something of a clean slate and aiming for minimal arch-specific code, I really don't want to carry forward legacy binfmts and associated support code, but I do want to understand if there are any particular properties of existing binfmts/ABIs/etc. that are important to developers/users, and I'd like to hear if you have any input on this from the Xtensa side. Rich ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
On Sat, May 30, 2015 at 05:12:13AM -0500, Rob Landley wrote: > On Sat, May 30, 2015 at 3:06 AM, Waldemar Brodkorb wrote: > > Hi, > > Rob Landley wrote, > > > >> Of course somebody did a uclibc-ng fork (bought the domain name and > >> everything), but I talked to him and his reason for doing it is there > >> are some obscure targets even glibc doesn't support, and I expect that > >> as musl grows support for those targets his reasons for doing it will > >> gradually fade away. *shrug* We'll see. > > > > We'll see. In the FPGA world there are four main architectures, > > NIOS2, ARC, Microblaze and Xtensa. Nios2 and Microblaze are > > supported by GNU libc. ARC and Xtensa are only supported by > > uClibc/uClibc-ng. There are nice developers and company's behind. > > > > For all the no-MMU architectures or systems there is only one option > > at the moment. uClibc/uClibc-ng! > > Actually I spent this morning walking Rich through setup of his new > sh2 nommu board this morning. Is there an easy way to get started testing nommu Microblaze Linux in qemu or another emulator? Since musl already has a microblaze target, it should be easy to support. Based on my introduction to this stuff so far, the big thing I think needs work in the nommu scene is getting rid of hackish toolchain cruft. Flat binary format is a hideous hack and the exact same thing (binaries built using the standard psABI calling/linking conventions, but without shareable text) can be achieved with plain (non-FDPIC) ELF, but the kernel refuses to enable binfmt_elf for nommu, despite the fact that binfmt_elf_fdpic exists and can do the exact work binfmt_elf should be doing on nommu when it detects that the ELF headers require a fixed displacement between LOAD segments. When we get musl working on nommu, I don't want to dredge back up all the horrible hacks that were done historically in uclinux. Plain ELF binaries for the same ISA should just work, albeit with fork() failing with ENOSYS and some combinations of mmap flags failing, etc., and with no sharing of text. Then we can gradually add FDPIC on an as-needed basis. I'm working out the proof-of-concept for this approach on sh2 right now. Rich ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
On Sat, May 30, 2015 at 1:12 PM, Rob Landley wrote: > I see a qemu-system-xtensa so might give that a try too. Please do. I'd be happy to answer any questions. I also hope to port musl to xtensa this year. -- Thanks. -- Max ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
On Sat, May 30, 2015 at 3:06 AM, Waldemar Brodkorb wrote: > Hi, > Rob Landley wrote, > >> Of course somebody did a uclibc-ng fork (bought the domain name and >> everything), but I talked to him and his reason for doing it is there >> are some obscure targets even glibc doesn't support, and I expect that >> as musl grows support for those targets his reasons for doing it will >> gradually fade away. *shrug* We'll see. > > We'll see. In the FPGA world there are four main architectures, > NIOS2, ARC, Microblaze and Xtensa. Nios2 and Microblaze are > supported by GNU libc. ARC and Xtensa are only supported by > uClibc/uClibc-ng. There are nice developers and company's behind. > > For all the no-MMU architectures or systems there is only one option > at the moment. uClibc/uClibc-ng! Actually I spent this morning walking Rich through setup of his new sh2 nommu board this morning. The company I'm working for (se-instruments.com) is producing a new sh2-compatible processor (the patents expired, clean room clone by engineers in canada), and I mailed Rich a little FPGA board with the bitstream that runs that, along with toolchain info and a kernel patch and so on so he can boot stuff and start adding musl support. Due to this, we've been talking about nommu support for musl for... 4 months? We talked about it at lunch at ELC in california month before last. (I also spoke to the buildroot maintainer and the openembedded maintainer, but I've been too swamped to follow up with them yet...) > I am maintaining an developing buildsystems for embedded devices > since more than 10 years, I don't think I will give up on uClibc-ng > so fast. Ok. Good luck. I'll be over here. Microblaze I have a todo item to set up a qemu based environment for and port aboriginal linux to, and generally once I do that Rich adds target support because it's then easy for him. I see a qemu-system-xtensa so might give that a try too. I don't see arc or nios in qemu, so probably won't bother worrying about either any time soon. >> Remember when buildroot announced they would switch their default libc >> if the uClibc developers couldn't get a new release out? Remember how >> that was over a year ago, ala >> http://lists.busybox.net/pipermail/uclibc/2014-February/048252.html ? >> Well instead what happened was >> http://lists.busybox.net/pipermail/buildroot/2013-October/079661.html >> became >> http://git.buildroot.net/buildroot/commit/?id=c29799330464fb5d152f1b3d550fcbda69c58a3d >> which became >> https://www.phoronix.com/scan.php?page=news_item&px=Musl-Libc-GCC-Support >> and at this point it's pretty much over except the cleanup. They >> didn't _announce_ a migration, they just did it. At this point if >> uClibc had a new release I expect they'd smile and nod and _continue_ >> not to care because there are better alternatives now, once that >> haven't established a pattern of chronic multi-year development >> constipation. > > That is not correct. They did not silently migrate to musl. > Musl is a choice like Gnu Libc in their buildsystem. They have not changed their default yet, true. > They will migrate in the next release cycle, but they migrate to > uClibc-ng as default C library for their system. Ok. > This will get a better code coverage, than my own embedded-test > project, which at the moment only running the uClibc-ng testsuite > regulary. > > But may be Rob comes up with nommu.org contents with a musl > libc for at least sh2 nommu, soon. Working on it as we speak, but also trying to clean up the sh2 kernel patch tos end upstream for 4.2 (probably not gonna make it), and get ready for our talk about this at linuxcon japan (panel slot approved at the last minute from the standby list, thursday the 4th at 11:30, woo! Gotta do slides!) We already did a dry run of this at the Linux Jamboree last month (http://elinux.org/Japan_Technical_Jamboree_52#Agenda 4pm slot, that has a link to youtube video of our talk) but I was hugely jetlagged and Kawasaki-san (the original SuperH architect, working with us on this as a consultant) did his part of the talk in japanese because of our audience. The most coherent third was Jeff Dionne (the founder of uclinux.org who handed it off when he moved to Japan in 2003), who is the CEO of the company doing all this. So you know... working on it. :) (I also submitted the same talk proposal to Plumber's, but it's still pending. Did I mention we're releasing the VHDL for this open source so you can build and modify your own processors as you like? The sh4 patents expire in 2016 and then we can add an mmu, but there are advantages to nommu systems so we aren't dropping that side then either...) > > Best choice for exotic architectures and hardware is OpenADK + uCLibc-ng ;) > We all do our own stuff. :) > best regards and happy hacking, > Waldemar Rob ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
Hello. "> > You mentioned a distro you boottrapped a couple of weeks > > ago. Do you have a working rootfs environment I could > > test? > > I did not submit the m68k patch to OE yet since i meant to get gmp > going first, no. > > Buildroot, Alpine-linux or gentoo come to mind, i'd try these with > current uClibc master. The m68k support in buildroot is disabled. I sent a patch to enable it for m68k targeting Aranym, but it needs some more work to be accepted. Alpine-Linux switched to musl libc and musl has no m68k support. Alpine-Linux never had support for m68k. Gentoo has some 2 years old stage3 images lying around. Dunno. The best option you have is to use OpenADK. OpenADK uses uClibc-ng (spinoff of uClibc master) and has support for targeting Aranym (68040 CPU) or Qemu-M68K with Coldfire no-MMU CPU. I am planning to add support for a coldfire board and an old m68k based laptop for real hardware testing. " Thanks for hints. I'm already building all the stuff using the system image from the uClibc homepage. It was a bit of challenge as it is based on bash 2.05 without completion and for some reason is doesn't support Backspace and you need to press Delete instead. The included busybox is also a bit obsolete and I couldn't even run the configure scripts due to incompatible awk. I resolved that with static build of bash 3.2 and gawk using glibc and injecting these to the image. I managed to build pacman and now I'm happily rebuilding the whole world. Several packages failed since that as the busybox stripped versions of tools often do not support switches used in the build scripts, but I think I can hack such cases. It looks much better now. So, thanks for the hints. Regards, Jaromir. -- --- Ing. Jaromír Cápík GSM : +420608817756, +420604322607 Jabber : [email protected] ICQ : 58381083 e-mail : [email protected], [email protected] ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
Hi, Rob Landley wrote, > Of course somebody did a uclibc-ng fork (bought the domain name and > everything), but I talked to him and his reason for doing it is there > are some obscure targets even glibc doesn't support, and I expect that > as musl grows support for those targets his reasons for doing it will > gradually fade away. *shrug* We'll see. We'll see. In the FPGA world there are four main architectures, NIOS2, ARC, Microblaze and Xtensa. Nios2 and Microblaze are supported by GNU libc. ARC and Xtensa are only supported by uClibc/uClibc-ng. There are nice developers and company's behind. For all the no-MMU architectures or systems there is only one option at the moment. uClibc/uClibc-ng! I am maintaining an developing buildsystems for embedded devices since more than 10 years, I don't think I will give up on uClibc-ng so fast. > Remember when buildroot announced they would switch their default libc > if the uClibc developers couldn't get a new release out? Remember how > that was over a year ago, ala > http://lists.busybox.net/pipermail/uclibc/2014-February/048252.html ? > Well instead what happened was > http://lists.busybox.net/pipermail/buildroot/2013-October/079661.html > became > http://git.buildroot.net/buildroot/commit/?id=c29799330464fb5d152f1b3d550fcbda69c58a3d > which became > https://www.phoronix.com/scan.php?page=news_item&px=Musl-Libc-GCC-Support > and at this point it's pretty much over except the cleanup. They > didn't _announce_ a migration, they just did it. At this point if > uClibc had a new release I expect they'd smile and nod and _continue_ > not to care because there are better alternatives now, once that > haven't established a pattern of chronic multi-year development > constipation. That is not correct. They did not silently migrate to musl. Musl is a choice like Gnu Libc in their buildsystem. They will migrate in the next release cycle, but they migrate to uClibc-ng as default C library for their system. This will get a better code coverage, than my own embedded-test project, which at the moment only running the uClibc-ng testsuite regulary. But may be Rob comes up with nommu.org contents with a musl libc for at least sh2 nommu, soon. Best choice for exotic architectures and hardware is OpenADK + uCLibc-ng ;) best regards and happy hacking, Waldemar ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
Hi, Bernhard Reutner-Fischer wrote, > On 29 May 2015 at 17:54, Jaromír Cápík wrote: > > > You mentioned a distro you boottrapped a couple of weeks > > ago. Do you have a working rootfs environment I could > > test? > > I did not submit the m68k patch to OE yet since i meant to get gmp > going first, no. > > Buildroot, Alpine-linux or gentoo come to mind, i'd try these with > current uClibc master. The m68k support in buildroot is disabled. I sent a patch to enable it for m68k targeting Aranym, but it needs some more work to be accepted. Alpine-Linux switched to musl libc and musl has no m68k support. Alpine-Linux never had support for m68k. Gentoo has some 2 years old stage3 images lying around. Dunno. The best option you have is to use OpenADK. OpenADK uses uClibc-ng (spinoff of uClibc master) and has support for targeting Aranym (68040 CPU) or Qemu-M68K with Coldfire no-MMU CPU. I am planning to add support for a coldfire board and an old m68k based laptop for real hardware testing. best regards Waldemar ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
On Fri, May 29, 2015 at 1:00 PM, Jaromír Cápík wrote: > > "On 29 May 2015 at 17:54, Jaromír Cápík wrote: > >> You mentioned a distro you boottrapped a couple of weeks >> ago. Do you have a working rootfs environment I could >> test? > > I did not submit the m68k patch to OE yet since i meant to get gmp > going first, no. > " > > > > I found a complete uclibc environment in the uclibc > > downloads. It's called system-image-m68k.tar.bz2 > > and it's based on version 0.9.30. That sounds like my aboriginal linux output. There should be newer ones at http://landley.net/aboriginal/downloads/binaries/ or http://landley.net/aboriginal/downloads/old/binaries/ based on the last-ever uClibc release from 2012 plus a pile of patches in http://landley.net/hg/aboriginal/file/tip/sources/patches That said, I've given up on uclibc development and am following musl-libc.org these days. At this point, I wouldn't care if uclinux _did_ have a new release. The 3+ year gap since the last release is AFTER I SENT TWO CAKES to get this unblocked last decade. I created a buildroot list and evicted the other project's traffic off this one. I appointed a new maintainer more or less by fiat. None of it helped, and I'm through playing sisyphos. The problem is _chronic_ and apparently unsolvable, which means this project is essentially already dead. It just hasn't noticed because it's _that_dead_. Remember how eglibc was created in response to the vacuum uClibc left. The reason eglibc went away is that vacuum got filled. Between musl and a slowly improving bionic sucking your developers away, I expect the number of people bothering the uClibc developers for a new release has dropped considerably. That's because the number of people who would care about a new uClibc release even if it happened at this point has dropped considerably, because they've moved on. Of course somebody did a uclibc-ng fork (bought the domain name and everything), but I talked to him and his reason for doing it is there are some obscure targets even glibc doesn't support, and I expect that as musl grows support for those targets his reasons for doing it will gradually fade away. *shrug* We'll see. Remember when buildroot announced they would switch their default libc if the uClibc developers couldn't get a new release out? Remember how that was over a year ago, ala http://lists.busybox.net/pipermail/uclibc/2014-February/048252.html ? Well instead what happened was http://lists.busybox.net/pipermail/buildroot/2013-October/079661.html became http://git.buildroot.net/buildroot/commit/?id=c29799330464fb5d152f1b3d550fcbda69c58a3d which became https://www.phoronix.com/scan.php?page=news_item&px=Musl-Libc-GCC-Support and at this point it's pretty much over except the cleanup. They didn't _announce_ a migration, they just did it. At this point if uClibc had a new release I expect they'd smile and nod and _continue_ not to care because there are better alternatives now, once that haven't established a pattern of chronic multi-year development constipation. The only reason I haven't switched aboriginal over yet (added support to build musl but didn't make it the default) is I'm busy with other things. The current blocker is I need to update my linux from scratch 6.8 native build, which is my big smoketest for each aboriginal linux release when I update the kernel and toybox and such. several packages in there have big #ifdef/else staircases with lists of known build environments and end with #error or doing something really stupid if they can't recognize your libc. Yes, even if nothing's wrong, they break just because they don't recognize the _name_ of the build environment. Mostly FSF crap. The way uclibc dealt with that was by lying and claiming to be glibc. Musl pushes fix patches upstream into the other packages instead, but that involves upgrading to package versions that have the fix or applying the fix yourself, and I've needed to upgrade my LFS build version anyway, so... Anyway, good luck with your m68k port.( I've poked the musl maintainer about adding that but he hasn't got a test environment and Laurent Vivier's qemu-q800 fork _still_ isn't merged. I should follow up and poke on that again, but my todo list runneth over...) Rob ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
"On 29 May 2015 at 17:54, Jaromír Cápík wrote: > You mentioned a distro you boottrapped a couple of weeks > ago. Do you have a working rootfs environment I could > test? I did not submit the m68k patch to OE yet since i meant to get gmp going first, no. " I found a complete uclibc environment in the uclibc downloads. It's called system-image-m68k.tar.bz2 and it's based on version 0.9.30. Let's see how it goes from there. J. -- --- Ing. Jaromír Cápík GSM : +420608817756, +420604322607 Jabber : [email protected] ICQ : 58381083 e-mail : [email protected], [email protected] " Buildroot, Alpine-linux or gentoo come to mind, i'd try these with current uClibc master. HTH," ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
On 29 May 2015 at 17:54, Jaromír Cápík wrote: > You mentioned a distro you boottrapped a couple of weeks > ago. Do you have a working rootfs environment I could > test? I did not submit the m68k patch to OE yet since i meant to get gmp going first, no. Buildroot, Alpine-linux or gentoo come to mind, i'd try these with current uClibc master. HTH, ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
"On 29 May 2015 at 13:11, Jaromír Cápík wrote: > Hello. > > I'm trying to port my uClibc based distro to m68k and experience > SIGSEGV in __uClibc_main even when linking binaries statically. > > I tried to crosscompile the m68k toolchain on i386 (uClibc based) > and m68k (glibc based) and in both cases the resulting binaries > segfault. > > My biggest sin is that I'm building version 0.9.28 and not the latest > one as the i386 version of my distro has that version and I didn't > want to be inconsistent. Anyway, I'm not against the idea of trying > the latest version, but before doing so I'd like to know whether > someone on this mailing list can confirm this is a known issue, > that has been fixed somewhere between 0.9.28 and 0.9.33.2. > I noticed changes in the libc/sysdeps/linux/m68 directory, but > I'm unsure whether that can play a role. At least the syscall is > redesigned completely (it was missing in 0.9.28 and I had to > hack it using a C source from Internet). > > I would appreciate your help / hints / anything. A m68k (cf) smallish distro bootstrapped fine with current master a couple of weeks ago. I did not run it through aranym though. Patches are of course welcome! " Hello Bernhard. I tried all versions from 0.9.28 tll 0.9.33.2 but except 0.9.28 each of them fails with different error during the build. The only buildable is 0.9.28, but it segfaults. It might be caused by component versions on the host system, but hard to guess. I'm slowly losing a hope. I'm thinking about backporting the __uclibc_main stuff to 0.9.28, but that's quite courageous plan. You mentioned a distro you boottrapped a couple of weeks ago. Do you have a working rootfs environment I could test? Thanks, Jaromir. ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segmentation fault in __uClibc_main on m68k
On 29 May 2015 at 13:11, Jaromír Cápík wrote: > Hello. > > I'm trying to port my uClibc based distro to m68k and experience > SIGSEGV in __uClibc_main even when linking binaries statically. > > I tried to crosscompile the m68k toolchain on i386 (uClibc based) > and m68k (glibc based) and in both cases the resulting binaries > segfault. > > My biggest sin is that I'm building version 0.9.28 and not the latest > one as the i386 version of my distro has that version and I didn't > want to be inconsistent. Anyway, I'm not against the idea of trying > the latest version, but before doing so I'd like to know whether > someone on this mailing list can confirm this is a known issue, > that has been fixed somewhere between 0.9.28 and 0.9.33.2. > I noticed changes in the libc/sysdeps/linux/m68 directory, but > I'm unsure whether that can play a role. At least the syscall is > redesigned completely (it was missing in 0.9.28 and I had to > hack it using a C source from Internet). > > I would appreciate your help / hints / anything. A m68k (cf) smallish distro bootstrapped fine with current master a couple of weeks ago. I did not run it through aranym though. Patches are of course welcome! cheers, ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
