Am 27.12.2012 20:59, schrieb KP Kirchdoerfer: > Am 27.12.2012 20:56, schrieb KP Kirchdoerfer: >> Am 27.12.2012 20:35, schrieb Yves Blusseau: >>> >>> Le 27 déc. 2012 à 19:06, KP Kirchdoerfer <kap...@users.sourceforge.net> a >>> écrit : >>> >>>> Am 27.12.2012 15:24, schrieb Yves Blusseau: >>>>> >>>>> Le 26 déc. 2012 à 00:01, KP Kirchdoerfer <kap...@users.sourceforge.net> a >>>>> écrit : >>>>> >>>>>> Hi; >>>>>> >>>>>> sorry for the delay - I started the discussion and then went offline :( >>>>>> >>>>>> Am 21.12.2012 10:21, schrieb Yves Blusseau: >>>>>>> >>>>>>> Le 19 déc. 2012 à 17:46, KP Kirchdoerfer <kap...@users.sourceforge.net> >>>>>>> a écrit : >>>>>>> >>>>>>>> Hi Gents; >>>>>>>> >>>>>>>> I'd like to make a proposal for the timeframe and features of the >>>>>>>> second >>>>>>>> alpha version of 5.0. >>>>>>>> >>>>>>>> First of all, I think it should still be an alpha version - so neither >>>>>>>> the kernel nor the uClibc are fixed. >>>>>>>> >>>>>>>> Also the major goal for 5.0 to support other cpu architectures misses >>>>>>>> at >>>>>>>> least one image/example. >>>>>>>> >>>>>>>> We saw over 100 downloads of alpha1 and received no complaints so far, >>>>>>>> so I consider for X86_32 even an alpha1 version was not bad. >>>>>>>> >>>>>>>> Along with usual Package updates and fixes, the new features for the >>>>>>>> second alpha could be a X86_64 image and to "enable" zram support at >>>>>>>> least, and eventually offering signed packages. >>>>>>>> >>>>>>>> As far as I'm aware a X86_64 version currently needs >>>>>>>> - a patch for vsftpd >>>>>>>> - a solution for the uClibc loader (lib/ld-uClibc-0.9.33.2.so vs >>>>>>>> lib/ld64-uClibc-0.9.33.2.so >>>>>>>> - and images (AFAIR it worked without changes) >>>>>>> >>>>>>> About the uClibc shared library, i've already start to discuss about >>>>>>> this with Andrew. Look at the messages with x86_64 toolchain subject. >>>>>>> Actually we are 2 solutions: >>>>>>> * Patch the toolchain so the library will always be: /lib/ld-uClibc.so >>>>>>> * Add a variable and put the right name for every toolchains >>>>>> >>>>>> Ouch, I missed that part in the thread, just read the stuff about the >>>>>> compilation with gcc. Reread, and my vote goes for option 2. >>>>> >>>>> Option 2 is: use a variable in every toolchain ? >>>> >>>> I thought this pointed to to your proposal about including >>>> $(toolchain).files in initrd/buildtool.cfg. Though it does not work yet, >>>> and it has a slight drawback, that we need a file which defines the >>>> loader for each architecture, even if only the X86_64-bit version is >>>> known to require that change, I prefer this option over patching uClibc… >>>> >>> >>> I have committed a simple solution (commit f0fac75c) >> >> Hi Yves, >> >> just give it a *very quick* test, see below. Haven't checked if the >> initrd built works. > > Sorry, just replaced buildtool.pl and overlooked initrd changes... > > will do another test
Hi Yves; now it's a lot better := no errors. Great! I'll rebuild everything from scratch and test via qemu, but this will take some time. kp ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
