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 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
