30.10.2011 00:12, KP Kirchdoerfer пишет: > Am Samstag, 29. Oktober 2011, 22:37:10 schrieb Andrew: >> Hi all. >> Today I have enough free time to spent it for LEAF toolchain. >> Now I finished very basic rework on it, it looks like now it should >> successfully compile C applications and has working C++ compiler w/o c++ >> libraries (I planned to replace libstdc++ to uClibcpp). Now compiler has >> native architecture - so it'll be no pain with cross-compilation in >> future and it'll be easy to build all for new architectures that are >> binary-incompatible with x86. Also it reduces count of ugly tricks in >> toolchain. >> I updated dropbear package for compiling on new toolchain - it looks >> like all is OK, and executable is working (in chroot of course - I >> didn't build 'native' uClibc libraries that are working in toolchain >> place). >> >> So now if anybody will have time to fix packages - welcome, I'll be glad >> for help. It's preferred if building system will be x64 - it's much >> easier to check if package is built right. >> >> In other case - use ldd to verify if executable is linked with uClibc, >> not with system libs. It's output should look like: >> # ldd dbclient >> libgcc_s.so.1 => >> /path-to-old-LEAF-buildenv/staging/lib/libgcc_s.so.1 (0xf776c000) >> libc.so.0 => /path-to-old-LEAF-buildenv/staging/lib/libc.so.0 >> (0xf7723000) >> ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xf7784000) > Hi Andrew; > > great to hear! > > Though I'm currently working on other stuff (mainly using a leaf box in > virtual environment as anti-virus proxy), I think you are still a step > ahead. I'd really like to see support for new architectures. > > I currently have a buildhost based on x32 - future debian/ubuntu version > will support both with multilib (buggy implementation caused the error I've > reported some time ago). > > So, will it be a major pb with a x32 build host? No, it just adds a lot more chances to be confused in checking binaries for correct linking. > Where can I download a test env? Branch 'next'. Now only 3 packages are built - 'linux' (headers), 'toolchain' (replacement of buildenv - I renamed it to avoiding confusing with 'building' of non-updated packages that becomes built/linked with system compiler/libraries in that case) and 'dropbear' (just for test). It has a lot of work, today/tomorrow I'll do some modifications to makefile/directory structure (move staging dir to staging/$(ARCH) for example), and later it'll require buildtool/buildpacket modification for specifying arch at command line/separate 'installed' files/multitarget .lrp description for multiple subarchs in one template (ticket #15), and of course it requires reviewing of all packages - configure options/makefiles, library placement/looking paths, etc. But in any case, now toolchain seems to be working. > Will it be easier if we go with uclibc 0.9.32? I do have a 0.9.32 buildenv > on my system, which builds nearly all packages sucessfully and can be > committed to git if necessary. > > kp I already updated uClibc in this toolchain. In any case, uClibc IMHO shouldn't be upgraded in 4.x branch if it breaks binary compatibility (in other words - if packages linked to 0.9.30 shouldn't run on 0.9.32).
------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
