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) Regards, Yves ------------------------------------------------------------------------------ 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
