Am Sonntag, 30. Oktober 2011, 09:32:20 schrieb Andrew: > 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) > > > > 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.
Ok, we'll see what happens, if necessary I'll create x64 build machine with virtualbox. > > 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). Sorry, I just had not seen the new branch. > 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). Agree. 0.9.32 will break compatibility, that's why it should be the base for 5.x. Good time to change buildtool/toolchain as well. I've finished a chapter using LEAF Bering-uClibc 4.x within a VM as a proxy. Currently rebuilding with all the latest changes. If that works, I'll try to build the new toolchain. kp ------------------------------------------------------------------------------ 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
