Re: [leaf-devel] BuC-next: errors during build
On 11 Jun 2012, at 17:49, Andrew wrote: Hi all. I noticed that there are some packages that are built with errors. Some of them I fixed (for ex., shorewall6 - it installs init file as shorewall, not shorewall6, and so on), and some of them have unresolved dependencies (includes), among them - samba and librpcsecgss. Here are parts of logs: # tail librpcsecgss.build.txt from ./../include/rpcsecgss/rpc/rpc.h:50, from auth_gss.c:44: ./../include/rpcsecgss/rpc/auth_gss.h:41:27: fatal error: gssapi/gssapi.h: No such file or directory compilation terminated. make[2]: *** [librpcsecgss_la-auth_gss.lo] Error 1 make[2]: Leaving directory `/var/testpoint/LEAF-new/source/i486-unknown-linux-uclibc/librpcsecgss/librpcsecgss-0.19/src' make[1]: *** [all-recursive] Error 1 This needs fixing but isn't actually breaking anything important at the moment. I added this source package for Kerberos support in NFS and other server code but hit this problem so didn't try to enable Kerberos support anywhere in Git. # tail samba.build.txt Compiling ../lib/addns/dnsrecord.c In file included from ../lib/addns/dnsrecord.c:24:0: ../lib/addns/dns.h:53:23: fatal error: uuid/uuid.h: No such file or directory compilation terminated. The following command failed: i486-unknown-linux-uclibc-gcc -O2 -march=i486 -mtune=pentiumpro -I/var/testpoint/LEAF-new/staging/i486-unknown-linux-uclibc/usr/include -I. -I/var/testpoint/LEAF-new/source/i486-unknown-linux-uclibc/samba/samba-3.6.4/source3 -I/var/testpoint/LEAF-new/source/i486-unknown-linux-uclibc/samba/samba-3.6.4/source3/../lib/iniparser/src -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/talloc -I../lib/tdb/include -DHAVE_CONFIG_H -I/var/testpoint/LEAF-new/staging/i486-unknown-linux-uclibc/usr/include -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/popt -I/var/testpoint/LEAF-new/source/i486-unknown-linux-uclibc/samba/samba-3.6.4/source3/lib -I.. -D_SAMBA_BUILD_=3 -D_SAMBA_BUILD_=3 -fPIC -c ../lib/addns/dnsrecord.c -o ../lib/addns/dnsrecord.o make[1]: *** [../lib/addns/dnsrecord.o] Error 1 I didn't look deep, maybe these deps can be omitted, or we must add missed headers to staging and libs to required packages. I think I have a fix for this in my dev env - uuid.h comes from mdadm, IIRC. I will take care of applying the fix. david -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Successful build of ARM toolchain
Am 01.04.2012 00:14, schrieb davidMbrooke: Hi all, I *finally* got my ARM toolchain to compile! Seems there are some issues with NPTL on ARM (both for uClibc 0.9.32.1 and 0.9.33) so I have reverted to the new pthread implementation for now (only for armv6; i486 still uses NPTL). A couple of minor fixes were required in toolchain/buildtool.mk plus some configuration tweaks elsewhere. I have uploaded my kernel and uClibc config files to Git in case anyone else wants to try building an ARM toolchain intended for the Raspberry Pi. I have also updated the Wiki page. Should be a simple case of: buildtool.pl -t armv6-unknown-linux-uclibcgnueabi build toolchain I am still working on the ac_cv_* settings in make/MasterInclude.mk so there are some Package build failures because of that. Nonetheless it is encouraging to find that around 80% of the Packages build OK, just not the important ones... :-) Indeed it's more than encouraging - you and Andrew did an awesome job coming closer to cross-compiling. With your latest commits the amount of packages failing has shrinked again, and I think the most important ones are almost there to testdrive an image on a Raspberry pi - if this will be shipped. (Don't know if such a box/toy is something that can be used with Bering-uClibc - but then a 25$-toy to test cross-compiling is worth the money :) - though there is always qemu to test, but running LEAF on a real box is something different, I'm eager waiting to see the first pictures). The more I work with it, and accompanied by the comprehensive wiki page, the more I understand the changes - I can imagine building and releasing for other architectures is around the corner. It will require a few more steps building and testing packages, building releases, but at the end it's hopefully just a matter of time - and it will a big step for LEAF after all these years. Exciting times! Unfortunately I won't be a lot of help in the forthcoming future, I'm away until mid of April from the end of the week. Thanks to both of you! kp -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - automatic genration for package description files.
Am 30.03.2012 21:25, schrieb Andrew: Hi all. Today I realized my idea of automation of package definition for initrd and moddb for each arch. It looks for me tiny and clear for understanding/modifying. Now there are template file with ##ARCH## tag and other files except kernel modules, and list of regexps for module names that are required for that package. It seems that nothing was forgotten in that operation - just removed some rarely-used modules; and some modules that are prerequisites for currently present in moddb were added in that way, + added some iptables-related and IPVS modules. So it waits testing, and now it seems that all environment is prepared for experiments in cross-compilation. Hi Andrew; pls look into my previous mail, how much I enjoy the/your work for cross-compiling. While I'm convinced that your approach works and is tiny, I'm not shure if it's understandable. I looked a long time in to your changes and my impression is that you've over-simplified it. The logic to build the files for buildpacket.pl has been put into buildtool.mk, the file to declare the modules is really simple. Anyway it breaks the rules how to define the filelist for packages. So it's different compared to any other package. While the current approach is stupid, it just works and until today it's always the same for every package. I'm afraid that putting the logic into buildtool.mk , and to make a difference in package definitions requires more documentation, raises questions and is in fact not as easy to understand as we like. If it's really necessary for cross-compiling I'll swallow it, if not I'd like to go with the common approach, just to keep it as simple as possible over the whole buildtool setup. opinions? kp -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - automatic genration for package description files.
02.04.2012 19:56, KP Kirchdoerfer написал: Am 30.03.2012 21:25, schrieb Andrew: Hi all. Today I realized my idea of automation of package definition for initrd and moddb for each arch. It looks for me tiny and clear for understanding/modifying. Now there are template file with ##ARCH## tag and other files except kernel modules, and list of regexps for module names that are required for that package. It seems that nothing was forgotten in that operation - just removed some rarely-used modules; and some modules that are prerequisites for currently present in moddb were added in that way, + added some iptables-related and IPVS modules. So it waits testing, and now it seems that all environment is prepared for experiments in cross-compilation. Hi Andrew; pls look into my previous mail, how much I enjoy the/your work for cross-compiling. While I'm convinced that your approach works and is tiny, I'm not shure if it's understandable. I looked a long time in to your changes and my impression is that you've over-simplified it. The logic to build the files for buildpacket.pl has been put into buildtool.mk, the file to declare the modules is really simple. Anyway it breaks the rules how to define the filelist for packages. So it's different compared to any other package. While the current approach is stupid, it just works and until today it's always the same for every package. No, same behavior was used for initrd for a long time. I'm afraid that putting the logic into buildtool.mk , and to make a difference in package definitions requires more documentation, raises questions and is in fact not as easy to understand as we like. This is applicable only for 2 packages, and only for kernel modules included in that packages. If it's really necessary for cross-compiling I'll swallow it, if not I'd like to go with the common approach, just to keep it as simple as possible over the whole buildtool setup. opinions? kp Another variant for cross-compiling - to have common file that has some replaceable insertions, a lot of specific files for each arch (like one for geode), and a lot of changes into buildimage.pl. And, of course, a lot of work for dependency tracking for modules (for ex., even in 4.2 in moddb there are some modules that are dependent on modules missed in moddb). -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Successful build of ARM toolchain
On 2 Apr 2012, at 17:04, KP Kirchdoerfer wrote: Am 01.04.2012 00:14, schrieb davidMbrooke: Hi all, I *finally* got my ARM toolchain to compile! Seems there are some issues with NPTL on ARM (both for uClibc 0.9.32.1 and 0.9.33) so I have reverted to the new pthread implementation for now (only for armv6; i486 still uses NPTL). A couple of minor fixes were required in toolchain/buildtool.mk plus some configuration tweaks elsewhere. I have uploaded my kernel and uClibc config files to Git in case anyone else wants to try building an ARM toolchain intended for the Raspberry Pi. I have also updated the Wiki page. Should be a simple case of: buildtool.pl -t armv6-unknown-linux-uclibcgnueabi build toolchain I am still working on the ac_cv_* settings in make/MasterInclude.mk so there are some Package build failures because of that. Nonetheless it is encouraging to find that around 80% of the Packages build OK, just not the important ones... :-) Indeed it's more than encouraging - you and Andrew did an awesome job coming closer to cross-compiling. With your latest commits the amount of packages failing has shrinked again, and I think the most important ones are almost there to testdrive an image on a Raspberry pi - if this will be shipped. (Don't know if such a box/toy is something that can be used with Bering-uClibc - but then a 25$-toy to test cross-compiling is worth the money :) - though there is always qemu to test, but running LEAF on a real box is something different, I'm eager waiting to see the first pictures). The more I work with it, and accompanied by the comprehensive wiki page, the more I understand the changes - I can imagine building and releasing for other architectures is around the corner. It will require a few more steps building and testing packages, building releases, but at the end it's hopefully just a matter of time - and it will a big step for LEAF after all these years. Exciting times! Unfortunately I won't be a lot of help in the forthcoming future, I'm away until mid of April from the end of the week. Thanks to both of you! kp Thanks kp. Andrew did a great job leading the way to make this a success. I believe I have fixed all the simple ARM build failures and the few that remain are not in the core packages so are not top priority. I'm going to test an ARM build using qemu so I can iron out some more issues before I get a chance to order a Raspberry Pi. I do want to see Bering-uClibc running on that hardware and it may become an affordable, standard non-x86 testbed for us. There are other ARM devices (SheevaPlug, DockStar, Pogoplug etc.) which we could target too - and I already own a Pogoplug which could be fun to try. Toys are not only for kids :-) david -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
29.03.2012 19:33, davidMbrooke написал: On Wed, 2012-03-28 at 13:02 +0200, Yves Blusseau wrote: Hi david, i know i never happy perhaps we can change Logfile = log/buildtoollog to Logfile = log/$GNU_TARGET_NAME/buildtoollog in conf/buildtool.conf Hi Yves, I know you are right... I did consider making that change initially but it is slightly complex because buildtool.pl currently writes to the logfile *before* picking up the value for toolchainname, so more of a change to the structure is required. I will look at this at the weekend. david I think that it isn't too important change. In any case, log is just for debugging troubles, and trouble will appear at the end of log :) And no matters how much packages are built before. I can imagine only one case in which it'll be good to have separate logs - parallel building for different archs, but it's not so important thing IMHO. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
On Wed, 2012-03-28 at 13:02 +0200, Yves Blusseau wrote: Hi david, i know i never happy perhaps we can change Logfile = log/buildtoollog to Logfile = log/$GNU_TARGET_NAME/buildtoollog in conf/buildtool.conf Hi Yves, I know you are right... I did consider making that change initially but it is slightly complex because buildtool.pl currently writes to the logfile *before* picking up the value for toolchainname, so more of a change to the structure is required. I will look at this at the weekend. david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
Le 27/03/2012 22:04, davidMbrooke a écrit : Thanks Mike. I have now completed the document based on what was in my head. It now describes all the places where the build system has to be configured in order to add a custom toolchain (really only 3 places - some simple config settings in make/MasterInclude.mk, a custom patch for the Linux kernel .config and a custom uClibc .config). I have also started a Discussion page at the same location to track QA. david Thanks david for the documentation. Just some questions: i have a soekris net6501 board (with an Atom E6xx series processor). If i take the standard configuration (|i486-unknown-linux-uclibc) buildtoo.pl will use the parameters defined in ||make/MasterInclude.mk: | ARCH:=i386 KARCHS:=i686 i486 geode KARCHS_PCIE:=i686 ARCH_CFLAGS=-march=i486 -mtune=pentiumpro I think it's not optimal for my board (i don't have to compile for i486 and mtune can be more specific). So my question: what is the best changes i need to do to have optimisation for my board ? I think i need a specific triplet name like atom-net6501-linux-uclibc ? with in|make/MasterInclude.mk:| |else ifeq ($(GNU_TARGET_NAME),atom-net6501-linux-uclibc) # Primary kernel architecture export ARCH:=x86_64 # Space-separated list of kernel sub-archs to generate export KARCHS:=net6501| export KARCHS_PCIE:=net6501 |# Arch-specific CFLAGS export ARCH_CFLAGS=-march=atom -mtune=atom is it right (like the |KARCHS_PCIE) |? This is just a use case to understand how we can change things for a proper toolchain. Regards, Yves || | -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
Le 28/03/2012 12:14, Andrew a écrit : 28.03.2012 12:55, Yves Blusseau написал: Le 27/03/2012 22:04, davidMbrooke a écrit : Thanks Mike. I have now completed the document based on what was in my head. It now describes all the places where the build system has to be configured in order to add a custom toolchain (really only 3 places - some simple config settings in make/MasterInclude.mk, a custom patch for the Linux kernel .config and a custom uClibc .config). I have also started a Discussion page at the same location to track QA. david Thanks david for the documentation. Just some questions: i have a soekris net6501 board (with an Atom E6xx series processor). If i take the standard configuration (|i486-unknown-linux-uclibc) buildtoo.pl will use the parameters defined in ||make/MasterInclude.mk: | ARCH:=i386 KARCHS:=i686 i486 geode KARCHS_PCIE:=i686 ARCH_CFLAGS=-march=i486 -mtune=pentiumpro I think it's not optimal for my board (i don't have to compile for i486 and mtune can be more specific). So my question: what is the best changes i need to do to have optimisation for my board ? I think i need a specific triplet name like atom-net6501-linux-uclibc ? with in|make/MasterInclude.mk:| |else ifeq ($(GNU_TARGET_NAME),atom-net6501-linux-uclibc) # Primary kernel architecture export ARCH:=x86_64 # Space-separated list of kernel sub-archs to generate export KARCHS:=net6501| export KARCHS_PCIE:=net6501 |# Arch-specific CFLAGS export ARCH_CFLAGS=-march=atom -mtune=atom is it right (like the |KARCHS_PCIE) |? This is just a use case to understand how we can change things for a proper toolchain. Regards, Yves || | ARCH_CFLAGS involves only userland libraries, kernel is compiled for selected arch - so you bother for 2-3% speedup of userland that is negligible. Tuning for specific arch instead of generic (pentium4 vs i686, atom vs x86_64, etc) will give just some % of speed-up. Also switching from i686 to x86_64 may cause performance drop (larger code will cause more frequent cache misses), and no performance boost at least on IPv4 (it operates with 32bit or less data). Thanks andrew for the informations. And second, for host names there are standard names, you can't defune your own arch - libtool will not know it, and you'll have errors on compilation. You speak about the net6501 for the KARCHS variable or the GNU_TARGET_NAME ? So if you want to speed-up your box - it'll be enough to make kernel optimized for your box, and use it with generic userland for your architecture. So the best is to OVERRIDE the i486-unknown-linux-uclibc triplet in make/MasterInclude.mk with something like: ifeq ($(GNU_TARGET_NAME),i486-unknown-linux-uclibc) # Primary kernel architecture export ARCH:=i386 # Space-separated list of kernel sub-archs to generate export KARCHS:=net6501 # Available kernel archs with pci-express support export KARCHS_PCIE:=i686 # Arch-specific CFLAGS export ARCH_CFLAGS=-march=i486 -mtune=pentiumpro and create a dedicated kernel config file Bering-3.2.13.config-net6501.patch ? Yves -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
Le 21/03/2012 23:21, davidMbrooke a écrit : On Wed, 2012-03-21 at 13:08 +0200, Andrew wrote: On 21/03/12 12:47, Yves Blusseau wrote: One suggestion: it will be great to have a subdirectory in the /build/ directory with the name of the toolchain. For example: build/i486-unknown-linux-uclibc so we can build multiple versions of a package for different architecture. Yves Yes, and also it'll be good to have subdir in /source/ directory. You guys are never happy, are you? :-} I have now changed the buildtool scripts and config files so that: source/ - source/i486-unknown-linux-uclibc/ build/ - build/i486-unknown-linux-uclibc/ and also: conf/installed - conf/i486-unknown-linux-uclibc/installed since we need to track what has been built on a per-toolchain basis. Hi david, i know i never happy perhaps we can change Logfile = log/buildtoollog to Logfile = log/$GNU_TARGET_NAME/buildtoollog in conf/buildtool.conf -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
28.03.2012 13:57, Yves Blusseau написал: Le 28/03/2012 12:14, Andrew a écrit : 28.03.2012 12:55, Yves Blusseau написал: Le 27/03/2012 22:04, davidMbrooke a écrit : Thanks Mike. I have now completed the document based on what was in my head. It now describes all the places where the build system has to be configured in order to add a custom toolchain (really only 3 places - some simple config settings in make/MasterInclude.mk, a custom patch for the Linux kernel .config and a custom uClibc .config). I have also started a Discussion page at the same location to track QA. david Thanks david for the documentation. Just some questions: i have a soekris net6501 board (with an Atom E6xx series processor). If i take the standard configuration (|i486-unknown-linux-uclibc) buildtoo.pl will use the parameters defined in ||make/MasterInclude.mk: | ARCH:=i386 KARCHS:=i686 i486 geode KARCHS_PCIE:=i686 ARCH_CFLAGS=-march=i486 -mtune=pentiumpro I think it's not optimal for my board (i don't have to compile for i486 and mtune can be more specific). So my question: what is the best changes i need to do to have optimisation for my board ? I think i need a specific triplet name like atom-net6501-linux-uclibc ? with in|make/MasterInclude.mk:| |else ifeq ($(GNU_TARGET_NAME),atom-net6501-linux-uclibc) # Primary kernel architecture export ARCH:=x86_64 # Space-separated list of kernel sub-archs to generate export KARCHS:=net6501| export KARCHS_PCIE:=net6501 |# Arch-specific CFLAGS export ARCH_CFLAGS=-march=atom -mtune=atom is it right (like the |KARCHS_PCIE) |? This is just a use case to understand how we can change things for a proper toolchain. Regards, Yves || | ARCH_CFLAGS involves only userland libraries, kernel is compiled for selected arch - so you bother for 2-3% speedup of userland that is negligible. Tuning for specific arch instead of generic (pentium4 vs i686, atom vs x86_64, etc) will give just some % of speed-up. Also switching from i686 to x86_64 may cause performance drop (larger code will cause more frequent cache misses), and no performance boost at least on IPv4 (it operates with 32bit or less data). Thanks andrew for the informations. And second, for host names there are standard names, you can't defune your own arch - libtool will not know it, and you'll have errors on compilation. You speak about the net6501 for the KARCHS variable or the GNU_TARGET_NAME ? GNU_TARGET_NAME So if you want to speed-up your box - it'll be enough to make kernel optimized for your box, and use it with generic userland for your architecture. So the best is to OVERRIDE the i486-unknown-linux-uclibc triplet in make/MasterInclude.mk with something like: ifeq ($(GNU_TARGET_NAME),i486-unknown-linux-uclibc) # Primary kernel architecture export ARCH:=i386 # Space-separated list of kernel sub-archs to generate export KARCHS:=net6501 # Available kernel archs with pci-express support export KARCHS_PCIE:=i686 # Arch-specific CFLAGS export ARCH_CFLAGS=-march=i486 -mtune=pentiumpro and create a dedicated kernel config file Bering-3.2.13.config-net6501.patch ? Yves Not replace, just add new KARCH net6501 and add it in KARCHS_PCIE if you use pci-express devices. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
On Wed, 2012-03-21 at 12:50 -0700, Mike Noyes wrote: On 03/20/2012 01:57 PM, davidMbrooke wrote: -snip- I am also in the process of drafting some notes on building for other platforms here: http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_5.x_-_Developer_Guide_-_Adding_a_Hardware_Architecture_Variant David, Great start on this document. Everyone, Anyone with cross-complie experience please review and comment on the document. Thanks. Thanks Mike. I have now completed the document based on what was in my head. It now describes all the places where the build system has to be configured in order to add a custom toolchain (really only 3 places - some simple config settings in make/MasterInclude.mk, a custom patch for the Linux kernel .config and a custom uClibc .config). I have also started a Discussion page at the same location to track QA. david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - uClibc 0.9.33 is available - Should we upgrade?
25.03.2012 15:51, davidMbrooke написал: Hi all, I am getting build errors for my highly experimental ARM11 toolchain - a conflict between GCC and uClibc 0.9.32.1 NPTL code. Looks like there are some relevant fixes included in uClibc 0.9.33 which was released 01 Feb 2012. Could we upgrade uClibc? I have tried a quick test and I get a *different* error when using 0.9.33, but I'd prefer to work on a fix for the new error rather than the old error. I'm not sure which of our uClibc patches would need to be retained if we upgrade - is it simply that those with 0.9.32 in the name apply (only) to the .32 release and can be retired, whereas the others should be retained? Thanks, david Hi. From me, there are only needed 'resolv.patch' (DNS resolver functions). I can't remember now for which package it's actually needed, but it is used somewhere. AIO patch is unneeded. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - All building OK on x86_64
Le 25/03/2012 18:05, KP Kirchdoerfer a écrit : Am 25.03.2012 17:04, schrieb davidMbrooke: On Sun, 2012-03-25 at 13:41 +0100, davidMbrooke wrote: On Sun, 2012-03-25 at 10:42 +0200, KP Kirchdoerfer wrote: My fault - forgot to commit a common.cfg which points to the correct file. Can you sow the error for shorewall6? kp Hi kp, All is OK now - the same common.cfg error affected shorewall6. I am currently rebuilding everything. Hoping for all green :-) david Hi kp, So shorewall and shorewall6 are indeed OK, however not shorewall-lite and shorewall6-lite (those are the only two failures from a complete re-build). Looks like the same error affects both Packages: install -c init.leaf /home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall-lite/etc/init.d/shorewall-lite install: cannot create regular file `/home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall-lite/etc/init.d/shorewall-lite': No such file or directory make: *** [shorewall-lite-4.5.1.1/.build] Error 1 make: Leaving directory `/home/leaf/bering-uclibc-next/source/i486-unknown-linux-uclibc/shorewall-lite' install -c init.leaf /home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall6-lite/etc/init.d/shorewall6-lite install: cannot create regular file `/home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall6-lite/etc/init.d/shorewall6-lite': No such file or directory make: *** [shorewall6-lite-4.5.1.1/.build] Error 1 make: Leaving directory `/home/leaf/bering-uclibc-next/source/i486-unknown-linux-uclibc/shorewall6-lite' In both cases I also see Installing Redhat/Fedora-specific configuration... in the logfile. Thx for catching it; I've committed new buildtool files - you may try now. Compile and packaging of shorewall work without a flaw on my fedora 15 64Bits Yves -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - All building OK on x86_64
Am 25.03.2012 00:15, schrieb davidMbrooke: On Sat, 2012-03-24 at 20:37 +0100, KP Kirchdoerfer wrote: Another issue is shorewall. Latest version 4.5 improved install section for BUILD and HOST system. I'm not shure if I got it right. So can you pls do me a favour and chekc if works on a Fedora system? I tried with my latest commit to go without the the underlying build system. If it doesn't work for you, I have to rethink my approach. kp Hi kp, I'm seeing errors creating Packages for shorewall (and shorewall6) :-( Error from buildpacket.pl is: Generating package shorwall cp: cannot stat `/home/leaf/bering-uclibc-next/staging/i486-unknown-linux-uclibc/etc/init.d/shorewall-init': No such file or directory Output from the install step running buildtool.pl is: cp init.sh shorewall-4.5.1.1/init.sh mkdir -p /home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall (cd shorewall-4.5.1.1; env PREFIX=/home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall ./install.sh) Installing Redhat/Fedora-specific configuration... Not setting file owner/group permissions, not running as root. Installing Shorewall Version 4.5.1.1 My fault - forgot to commit a common.cfg which points to the correct file. I wonder if is possible / sensible to force a setting for $HOST when calling install.sh ? I would have thought we should select something which matches the Target rather than the Build host... In the case of shorewall the HOST environment variable describes the system where the installed package will run. Can you sow the error for shorewall6? kp -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - All building OK on x86_64
On Sun, 2012-03-25 at 10:42 +0200, KP Kirchdoerfer wrote: My fault - forgot to commit a common.cfg which points to the correct file. Can you sow the error for shorewall6? kp Hi kp, All is OK now - the same common.cfg error affected shorewall6. I am currently rebuilding everything. Hoping for all green :-) david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - uClibc 0.9.33 is available - Should we upgrade?
Am 25.03.2012 14:51, schrieb davidMbrooke: Hi all, I am getting build errors for my highly experimental ARM11 toolchain - a conflict between GCC and uClibc 0.9.32.1 NPTL code. Looks like there are some relevant fixes included in uClibc 0.9.33 which was released 01 Feb 2012. Could we upgrade uClibc? I have tried a quick test and I get a *different* error when using 0.9.33, but I'd prefer to work on a fix for the new error rather than the old error. Understandable... Have you tested a x86 build? kp -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - uClibc 0.9.33 is available - Should we upgrade?
On Sun, 2012-03-25 at 18:15 +0200, KP Kirchdoerfer wrote: Am 25.03.2012 14:51, schrieb davidMbrooke: Hi all, I am getting build errors for my highly experimental ARM11 toolchain - a conflict between GCC and uClibc 0.9.32.1 NPTL code. Looks like there are some relevant fixes included in uClibc 0.9.33 which was released 01 Feb 2012. Could we upgrade uClibc? I have tried a quick test and I get a *different* error when using 0.9.33, but I'd prefer to work on a fix for the new error rather than the old error. Understandable... Have you tested a x86 build? kp I had not tested that, but I have now. With all of our uClibc patches commented out the 0.9.33 uClibc builds OK as part of the x86 toolchain (i486-unknown-linux-uclibc) and a few sample Packages build OK too. I have yet to test a full build of all packages, or to test that it actually runs... david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
On Sat, 2012-03-24 at 00:40 +0100, KP Kirchdoerfer wrote: Yes I'm still on 32-bit. kp Hi kp, OK, so that explains why it works for you but not for me. I've realized that compiling for the build host rather than the target host is *exactly* what $(BUILD_CC) is for and I've had some success with mawk by editing the Makefile to use $(BUILD_CC) for the relevant step. Hopefully I can do the same for linux-atm and dhcpd. My current thinking is that the toolchain is working properly. Testing with a more different target (like ARM) will help prove that one way or the other. david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - All building OK on x86_64
Am 24.03.2012 18:36, schrieb davidMbrooke: Hi all, Following another batch of cross-compilation fixes (mawk, linux-atm, dhcpd and radius) I am again seeing an all green report from buildall.sh My build platform is Fedora 15 x86_64, so this is a *slightly* better test of cross-compilation than building on a 32-bit x86 platform. Hopefully I haven't broken anything for building on 32-bit. Hi David; good work - plus the new, helpful wiki page! Will check the latest commits tonight. I've compiled today against latest kernel (3.2.13), which I'd like to commit before. Another issue is shorewall. Latest version 4.5 improved install section for BUILD and HOST system. I'm not shure if I got it right. So can you pls do me a favour and chekc if works on a Fedora system? I tried with my latest commit to go without the the underlying build system. If it doesn't work for you, I have to rethink my approach. kp -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - All building OK on x86_64
On Sat, 2012-03-24 at 20:37 +0100, KP Kirchdoerfer wrote: Another issue is shorewall. Latest version 4.5 improved install section for BUILD and HOST system. I'm not shure if I got it right. So can you pls do me a favour and chekc if works on a Fedora system? I tried with my latest commit to go without the the underlying build system. If it doesn't work for you, I have to rethink my approach. kp Hi kp, I'm seeing errors creating Packages for shorewall (and shorewall6) :-( Error from buildpacket.pl is: Generating package shorwall cp: cannot stat `/home/leaf/bering-uclibc-next/staging/i486-unknown-linux-uclibc/etc/init.d/shorewall-init': No such file or directory Output from the install step running buildtool.pl is: cp init.sh shorewall-4.5.1.1/init.sh mkdir -p /home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall (cd shorewall-4.5.1.1; env PREFIX=/home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall ./install.sh) Installing Redhat/Fedora-specific configuration... Not setting file owner/group permissions, not running as root. Installing Shorewall Version 4.5.1.1 I wonder if is possible / sensible to force a setting for $HOST when calling install.sh ? I would have thought we should select something which matches the Target rather than the Build host... david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
Am 22.03.2012 21:36, schrieb davidMbrooke: On Wed, 2012-03-21 at 22:21 +, davidMbrooke wrote: By the way, I know that buildimage.pl is now broken because of these and my other changes. Maybe I can fix that tomorrow... david buildimage.pl should now be fixed too - at least for i486 builds - and also tools/buildall.sh which wasn't looking in the right place for source/*/buildtool.cfg files. The default behaviour of all the build utilities should therefore be back to where it was before but now there's an option to specify a different toolchain in (conf/buildtool.cfg or on the command line) and the toolchain name is reflected in all the generated directories as a basis for adding further toolchains for other platforms I do seem to have re-introduced a number of build failures (mawk, linux-atm, dhcpd) which is down to a *second* i486-unknown-linux-uclibc level in the directory structures in some places (specifically for the include files, which are therefore not being found, hence the build failures). I'm hunting the cause of that right now. Hi David; just rebuilded. I don't see any errors... Haven't tested buildpackage yet. kp -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
On Fri, 2012-03-23 at 19:02 +0100, KP Kirchdoerfer wrote: Am 22.03.2012 21:36, schrieb davidMbrooke: On Wed, 2012-03-21 at 22:21 +, davidMbrooke wrote: I do seem to have re-introduced a number of build failures (mawk, linux-atm, dhcpd) Hi David; just rebuilded. I don't see any errors... Haven't tested buildpackage yet. kp Hi kp, Thanks for checking. Are you building on 32-bit x86 by any chance, rather than 64-bit x86_64 like me? For mawk and linux-atm the problem seems to be that they are trying to run executables on the build host as part of the build process, but those executables are intended for the target host... A possible workaround is to run the executables manually, store the output in Git and insert the output into the source tree as part of make source. That will only work if the output is platform independent though. I'm starting to look at dhcpd (again!) now. david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
Am 23.03.2012 21:49, schrieb davidMbrooke: On Fri, 2012-03-23 at 19:02 +0100, KP Kirchdoerfer wrote: Am 22.03.2012 21:36, schrieb davidMbrooke: On Wed, 2012-03-21 at 22:21 +, davidMbrooke wrote: I do seem to have re-introduced a number of build failures (mawk, linux-atm, dhcpd) Hi David; just rebuilded. I don't see any errors... Haven't tested buildpackage yet. kp Hi kp, Thanks for checking. Are you building on 32-bit x86 by any chance, rather than 64-bit x86_64 like me? Yes I'm still on 32-bit. kp -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
On Wed, 2012-03-21 at 22:21 +, davidMbrooke wrote: By the way, I know that buildimage.pl is now broken because of these and my other changes. Maybe I can fix that tomorrow... david buildimage.pl should now be fixed too - at least for i486 builds - and also tools/buildall.sh which wasn't looking in the right place for source/*/buildtool.cfg files. The default behaviour of all the build utilities should therefore be back to where it was before but now there's an option to specify a different toolchain in (conf/buildtool.cfg or on the command line) and the toolchain name is reflected in all the generated directories as a basis for adding further toolchains for other platforms I do seem to have re-introduced a number of build failures (mawk, linux-atm, dhcpd) which is down to a *second* i486-unknown-linux-uclibc level in the directory structures in some places (specifically for the include files, which are therefore not being found, hence the build failures). I'm hunting the cause of that right now. david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
On Thu, 2012-03-22 at 20:36 +, davidMbrooke wrote: I do seem to have re-introduced a number of build failures (mawk, linux-atm, dhcpd) which is down to a *second* i486-unknown-linux-uclibc level in the directory structures in some places (specifically for the include files, which are therefore not being found, hence the build failures). I'm hunting the cause of that right now. david Struggling to spot what is wrong... Andrew: You are perhaps more familiar with toolchain/buildtool.mk Do the results of building the toolchain match what you expect? Seems like we have an extra GNU_TARGET_NAME level in some places... Thanks, david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
On 21/03/12 12:47, Yves Blusseau wrote: Le 20/03/2012 21:57, davidMbrooke a écrit : On Mon, 2012-03-19 at 22:56 +, davidMbrooke wrote: On Sun, 2012-03-18 at 23:59 +0200, Andrew wrote: 18.03.2012 19:44, davidMbrooke пишет: I'm also thinking about what the ARCH arguments to buildtool.pl and buildpacket.pl should look like. Maybe we just use the GCC target triplet syntax, so e.g. i486-pc-linux-uclibc for the Bering-uClibc 4.x platform armv6-unknown-linux-uclibcfor the Raspberry pi In other words, buildtool.pl --target=i486-pc-linux-uclibc build ... rather than buildtool.pl --arch=i386 build ... Thoughts? David AFAIK there is no difference between '-pc-linux-uclibc' and '-unknown-linux-uclibc' suffixes, and IMHO it'll be safe to use i486-unknown-linux-uclibc arch. Thanks Andrew. I therefore propose to identify the different toolchains with GNU_TARGET_NAME strings like i486-unknown-linux-uclibc, instead of ARCH strings like i386. I will add a -t toolchain argument to buildtool.pl and default this to i486-unknown-linux-uclibc so as to preserve the current behaviour. I have these changes working in my development environment now (plus a few other changes to prepare for non-x86 platforms) but I want to review those again before adding to Git (hopefully tomorrow). david OK, changes now pushed to the SourceForge Git. Hopefully I have preserved the existing behaviour by default but now buildtool.pl has a -t toolchainname argument and buildpacket.pl has a --toolchain toolchainname argument. Both default to the (new) toolchain setting in conf/buildtool.conf Since the name of the toolchain directory has changed (was i386, now i486-unknown-linux-uclibc) any 'next' developers will need to re-build their toolchain after they pull my latest changes. I am also in the process of drafting some notes on building for other platforms here: http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_5.x_-_Developer_Guide_-_Adding_a_Hardware_Architecture_Variant david Great doc david. Toolchain built without errors on my fedora 15. One suggestion: it will be great to have a subdirectory in the /build/ directory with the name of the toolchain. For example: build/i486-unknown-linux-uclibc so we can build multiple versions of a package for different architecture. Yves Yes, and also it'll be good to have subdir in /source/ directory. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
Am 20.03.2012 21:57, schrieb davidMbrooke: On Mon, 2012-03-19 at 22:56 +, davidMbrooke wrote: On Sun, 2012-03-18 at 23:59 +0200, Andrew wrote: 18.03.2012 19:44, davidMbrooke пишет: I'm also thinking about what the ARCH arguments to buildtool.pl and buildpacket.pl should look like. Maybe we just use the GCC target triplet syntax, so e.g. i486-pc-linux-uclibc for the Bering-uClibc 4.x platform armv6-unknown-linux-uclibcfor the Raspberry pi In other words, buildtool.pl --target=i486-pc-linux-uclibc build ... rather than buildtool.pl --arch=i386 build ... Thoughts? David AFAIK there is no difference between '-pc-linux-uclibc' and '-unknown-linux-uclibc' suffixes, and IMHO it'll be safe to use i486-unknown-linux-uclibc arch. Thanks Andrew. I therefore propose to identify the different toolchains with GNU_TARGET_NAME strings like i486-unknown-linux-uclibc, instead of ARCH strings like i386. I will add a -t toolchain argument to buildtool.pl and default this to i486-unknown-linux-uclibc so as to preserve the current behaviour. I have these changes working in my development environment now (plus a few other changes to prepare for non-x86 platforms) but I want to review those again before adding to Git (hopefully tomorrow). david OK, changes now pushed to the SourceForge Git. Hopefully I have preserved the existing behaviour by default but now buildtool.pl has a -t toolchainname argument and buildpacket.pl has a --toolchain toolchainname argument. Both default to the (new) toolchain setting in conf/buildtool.conf Since the name of the toolchain directory has changed (was i386, now i486-unknown-linux-uclibc) any 'next' developers will need to re-build their toolchain after they pull my latest changes. Good work! I've took the chance to rebuild with latest linux kernel 3.2.12 and (once again) without uClibc-pthread_initialize.patch. A first test on my router looks pretty well. buildall.sh shows only package with a pb - yate. Anyway I committed new linux kernel and refreshed uclibc buildtool setup to git. kp -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
On 03/20/2012 01:57 PM, davidMbrooke wrote: -snip- I am also in the process of drafting some notes on building for other platforms here: http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_5.x_-_Developer_Guide_-_Adding_a_Hardware_Architecture_Variant David, Great start on this document. Everyone, Anyone with cross-complie experience please review and comment on the document. Thanks. -- Mike Noyes http://sourceforge.net/users/mhnoyes https://profiles.google.com/mhnoyes -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
On Wed, 2012-03-21 at 13:08 +0200, Andrew wrote: On 21/03/12 12:47, Yves Blusseau wrote: One suggestion: it will be great to have a subdirectory in the /build/ directory with the name of the toolchain. For example: build/i486-unknown-linux-uclibc so we can build multiple versions of a package for different architecture. Yves Yes, and also it'll be good to have subdir in /source/ directory. You guys are never happy, are you? :-} I have now changed the buildtool scripts and config files so that: source/ - source/i486-unknown-linux-uclibc/ build/ - build/i486-unknown-linux-uclibc/ and also: conf/installed - conf/i486-unknown-linux-uclibc/installed since we need to track what has been built on a per-toolchain basis. Seems to work OK for me from limited testing but I suspect some buildtool operations will not work. Please check and report any problems. By the way, I know that buildimage.pl is now broken because of these and my other changes. Maybe I can fix that tomorrow... david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
On Mon, 2012-03-19 at 22:56 +, davidMbrooke wrote: On Sun, 2012-03-18 at 23:59 +0200, Andrew wrote: 18.03.2012 19:44, davidMbrooke пишет: I'm also thinking about what the ARCH arguments to buildtool.pl and buildpacket.pl should look like. Maybe we just use the GCC target triplet syntax, so e.g. i486-pc-linux-uclibc for the Bering-uClibc 4.x platform armv6-unknown-linux-uclibcfor the Raspberry pi In other words, buildtool.pl --target=i486-pc-linux-uclibc build ... rather than buildtool.pl --arch=i386 build ... Thoughts? David AFAIK there is no difference between '-pc-linux-uclibc' and '-unknown-linux-uclibc' suffixes, and IMHO it'll be safe to use i486-unknown-linux-uclibc arch. Thanks Andrew. I therefore propose to identify the different toolchains with GNU_TARGET_NAME strings like i486-unknown-linux-uclibc, instead of ARCH strings like i386. I will add a -t toolchain argument to buildtool.pl and default this to i486-unknown-linux-uclibc so as to preserve the current behaviour. I have these changes working in my development environment now (plus a few other changes to prepare for non-x86 platforms) but I want to review those again before adding to Git (hopefully tomorrow). david OK, changes now pushed to the SourceForge Git. Hopefully I have preserved the existing behaviour by default but now buildtool.pl has a -t toolchainname argument and buildpacket.pl has a --toolchain toolchainname argument. Both default to the (new) toolchain setting in conf/buildtool.conf Since the name of the toolchain directory has changed (was i386, now i486-unknown-linux-uclibc) any 'next' developers will need to re-build their toolchain after they pull my latest changes. I am also in the process of drafting some notes on building for other platforms here: http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_5.x_-_Developer_Guide_-_Adding_a_Hardware_Architecture_Variant david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - dhcpd build fixed
Am 18.03.2012 17:18, schrieb Yves Blusseau: Really good news ! Thanks a lot david an kp ! Don't forget Andrew! When do you think you will merge the 'next' branch onto 'master' ? Speaking for myself, support for other CPU's than x86 is one of our major targets for the 5.x series. So the kernel and uClibc updates should be seen as building steps to alleviate reaching the goal, though they are interesting and useful itself. While it's a good sign that a build from git branch runs well on a X86 processor, and we didn't break, what we have accomplished in the past, I'm not in hurry and willing to wait for toolchain improvements to support one or more architectures than only X86. Also the current 4.x series is in a good shape, and given a careful maintenance it gives us enough time to work a bit more on the next branch. With the two git branches around, it's easy to work on next and maintain master - I believe merging in the near future will raise more problems than it solves. YMMV kp -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Are we agreed that 'next' will be released as Bering-uClibc 5.x ?
Hi; just a few words about my reasons to talk about 5.x in trac. 'next' is always good for new branch to develop the forthcoming major version, but what will call the version after 'next', if next shoud be the stable name? Overnext? This is meaningless IMHO :) Another option is choose a completly new name, but I've been there before and it was pretty useless, there was no convincing idea, and spending a few evenings of our spare time just to find or not to find a new name is wasted time. Last but not least - we do have a small community, but that is used to the name after ten yrs. and we clearly outlined our version numbering on our webpage. 5.0 is still inline with both. Am 19.03.2012 19:36, schrieb davidMbrooke: Hi all, I plan to start making changes to the Wiki pages for 'next', adding info on cross-compiling and giving some more thought as to which pages are common to all Bering-uClibc versions (maybe the Hints and Tips on Git usage, for example?) and which are version-specific. Before I create more pages I'd like us to agree how we plan to identify 'next' when it finally gets released. I see that kp has started referring to 5.0 in Trac, which is OK by me. I presume that 'next' was only ever intended to be a working title. Should I change the existing 'next' Wiki pages to reflect a BuC 5.x naming convention (easily accomplished with the move facility in MediaWiki, which makes the old name redirect to the new name) and create new pages with 5.x names? You have my vote. kp -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
On Sun, 2012-03-18 at 23:59 +0200, Andrew wrote: 18.03.2012 19:44, davidMbrooke пишет: I'm also thinking about what the ARCH arguments to buildtool.pl and buildpacket.pl should look like. Maybe we just use the GCC target triplet syntax, so e.g. i486-pc-linux-uclibc for the Bering-uClibc 4.x platform armv6-unknown-linux-uclibcfor the Raspberry pi In other words, buildtool.pl --target=i486-pc-linux-uclibc build ... rather than buildtool.pl --arch=i386 build ... Thoughts? David AFAIK there is no difference between '-pc-linux-uclibc' and '-unknown-linux-uclibc' suffixes, and IMHO it'll be safe to use i486-unknown-linux-uclibc arch. Thanks Andrew. I therefore propose to identify the different toolchains with GNU_TARGET_NAME strings like i486-unknown-linux-uclibc, instead of ARCH strings like i386. I will add a -t toolchain argument to buildtool.pl and default this to i486-unknown-linux-uclibc so as to preserve the current behaviour. I have these changes working in my development environment now (plus a few other changes to prepare for non-x86 platforms) but I want to review those again before adding to Git (hopefully tomorrow). david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - dhcpd build fixed
Am 17.03.2012 22:04, schrieb davidMbrooke: Hi all, I believe I have fixed the build failure for dhcpcd on 'next'. It's the usual story - several hours' work for just a couple of lines in buildtool.mk :-) I managed to turn up a reference to setting CC for Solaris (in dhcp-4.2.2/README) which also works for us and enables the included copy of bind to be cross-compiled. There were also a lot of problems with #define macros being expanded inconsistently in the bind include files coming in from staging/usr/include/. I fixed those by forcing the ../bind/include/ files to be referenced first. I also fixed djbdns earlier by forcing make to run single-threaded. In theory that means that everything should build cleanly. I'm running a full rebuild now to check. Great! And after i fixed two packgaing errors all should be green now :) And it's running pretty smooth on my router - a solid alpha version. kp -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - dhcpd build fixed
Really good news ! Thanks a lot david an kp ! When do you think you will merge the 'next' branch onto 'master' ? Yves -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - dhcpd build fixed
On Sun, 2012-03-18 at 17:18 +0100, Yves Blusseau wrote: Really good news ! Thanks a lot david an kp ! When do you think you will merge the 'next' branch onto 'master' ? Yves Hi Yves, Personally I'd like to see us prove out cross-compiling for another platform before we take the brave step of merging the 'next' branch. As per my mail a few minutes ago we need think some more about about the most appropriate naming of directories and the changes to the build scripts. If we can all agree how to implement formal support for cross-compiling I should be able to make the necessary changes to buildtool / buildpacket in the next couple of weeks. David -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for ARCH
18.03.2012 19:44, davidMbrooke пишет: Hi all, I'm trying to understand the valid values for our various architecture variables in MasterInclude.mk (ARCH, KARCHS, GNU_ARCH, GNU_TUNE) in the context of cross-compiled builds. I'm OK with GNU_ARCH and GNU_TUNE because I can see those are driving the setting of -march and -mtune for GCC and they are covered in the GCC documentation (http://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html) For Bering-uClibc 4.x our make/MasterInclude.mk specifies: -march=$(GNU_ARCH) -mtune=$(GNU_TUNE) where: $(GNU_ARCH) = i486 $(GNU_TUNE) = pentiumpro Then there is KARCHS, where we have multiple variants (i686, i486, geode). This is effectively just a way to have different Kernels based on different Kernel .config settings, and hence different kernel Modules and different Initrd files. I'm OK with this since I understand how we added support for KARCHS in Bering-uClibc 4.x and how the Kernel .config patching works. In the Kernel .config we have settings like CONFIG_M686=y, for i686. The bit I don't understand (or at least didn't, until I started composing this mail, several hours ago) is ARCH, which is set to i386 for Bering-uClibc 4.x. Based on my investigations today it looks like ARCH is fundamentally a Kernel configuration setting and the value of ARCH must match the name of a directory under e.g. linux-3.2.11/arch/ - with a couple of special cases accommodated in linux-3.2.11/Makefile, for example i386 and x86_64 both relate to directory linux-3.2.11/arch/x86/. Within the Kernel .config for ARCH:=i386 we have CONFIG_X86=y and then some adjustments for i686, geode etc. as part of KARCHS. There is also an architecture selection for uClibc which we seem to match to the value of ARCH. For Bering-uClibc 4.x we configure uClibc with TARGET_ARCH=i386 but we also specify TARGET_SUBARCH=i486 and CONFIG_486=y. That means that our i386 toolchain is actually an *i486* toolchain, which I think we all understand and we accept that we only build one set of LRP executables for x86 devices. My primary motivation is to understand what all these variables should be set to for non-x86 platforms such as ARM. For example the Raspberry Pi has a Broadcom BCM2835 chip containing an ARM1176JZFS CPU. That is part of the ARM11 processor family built on the ARMv6 architecture, so for GCC we'd want to set -march=armv6 (or possibly -march=armv6zk) and then maybe -mtune=arm1176jzf-s. In terms of Kernel configuration we'd want to specify ARCH:=ARM (and hence CONFIG_ARM=y) and then CONFIG_ARCH_BCMRING=y (which looks to be the equivalent of e.g. CONFIG_M686=y or CONFIG_MGEODE_LX=y so would be configured via KARCHS). I'm therefore thinking, for the Raspberry Pi: ARCH = arm KARCHS= bcmring GNU_ARCH = armv6 GNU_TUNE = arm1176jzf-s In the uClibc .config I'd want to set TARGET_arm=y, TARGET_ARCH=arm and CONFIG_ARM1176JZF_S=y (which then compiles uClibc with -march=armv6 and -mtune=arm1176jzf-s based on the settings in Rules.mak). That means we'd have an armv6 toolchain rather than a generic arm toolchain. Hi. ARCH defines for what ARCH is cross-compiled kernel (ARCH=$(ARCH) make). It needs to be specified because in other case make oldconfig/make menuconfig will try to change settings for current host arch. KARCHS - list of kernel variants (and related modules). IMHO it should be unique for each embedded platform/family of very similar platforms. GNU_ARCH - CPU type for which userland is built, GNU_TUNE - for which CPU variant userland will be optimized (because userland will run on different CPU sub-archs). I'm also thinking about what the ARCH arguments to buildtool.pl and buildpacket.pl should look like. Maybe we just use the GCC target triplet syntax, so e.g. i486-pc-linux-uclibc for the Bering-uClibc 4.x platform armv6-unknown-linux-uclibcfor the Raspberry pi In other words, buildtool.pl --target=i486-pc-linux-uclibc build ... rather than buildtool.pl --arch=i386 build ... Thoughts? David AFAIK there is no difference between '-pc-linux-uclibc' and '-unknown-linux-uclibc' suffixes, and IMHO it'll be safe to use i486-unknown-linux-uclibc arch. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Confirmation of /lib/ld-uClibc.so.0 symlink requirements
On Wed, 2012-03-14 at 20:58 +0100, KP Kirchdoerfer wrote: Am 13.03.2012 23:33, schrieb davidMbrooke: Hi all, Now that Andrew and kp have done all the hard work on next I have finally found time to try to build it. I'm getting a few build errors (on Fedora 15, x86_64). From previous mails to this list I can see that some of these errors are expected but others are not. Some of the problems I am seeing have previously been discussed in the context of the /lib/ld-uClibc.so.0 symbolic link. For next I understand that link does not *need* to exist, but can the presence of the link still cause problems? I am getting build failures for: djbdns squid mawk linux-atm libdigest-sha1-perl dhcpd (expected) I will of course investigate and make corrections. In particular for dhcpd, since I am probably responsible for that build failure anyway :-) Thanks to everyone who has contributed to next so far. Like others I am really looking forward to running it on ARM. david Hi David; Andrew deserves the honour for the next branch, he did a really good job, so it was easy to install after a few hickups and testdrive, which is fun cause in my environment it's running smoother even in alpha state than 4.2 :) As Andrew said libdigest-sha1-perl should work today, at least it does for me. I haven't deleted the symbolic link for ld-uClibc.so.0 to compile the packages (which may explain djbdns build failure from time to time - will keep an eye on this one). I'll update dnsmasq to version 2.60 in next branch. It works as expected on my box - without further changes to my dnsmasq.conf. With 2.60 another player for DHCPv6 gets into the arena, you may look into it and compare it with dibbler etc.. It even has (limited(?)) support for router advertisements... (http://thekelleys.org.uk/dnsmasq/CHANGELOG) kp Thanks Andrew and kp, I rebuilt from scratch on Wednesday after deleting the link. It had no effect. libdigest-sha1-perl is indeed better now (I got a buildpacket failure but I will re-build today to confirm I am using the latest code from Git). The news of IPv6 support in dnsmasq is surprising to me but very encouraging for enhanced IPv6 support in a small footprint. kp: For djbdns I am getting an error that you also had on 28 Jan. Do you have a fix identified for this error: ./compile socket_accept6.c socket_connect6.c:9:21: fatal error: haveip6.h: No such file or directory Thanks, David -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Confirmation of /lib/ld-uClibc.so.0 symlink requirements
Am 16.03.2012 18:43, schrieb davidMbrooke: On Wed, 2012-03-14 at 20:58 +0100, KP Kirchdoerfer wrote: Am 13.03.2012 23:33, schrieb davidMbrooke: Hi all, Now that Andrew and kp have done all the hard work on next I have finally found time to try to build it. I'm getting a few build errors (on Fedora 15, x86_64). From previous mails to this list I can see that some of these errors are expected but others are not. Some of the problems I am seeing have previously been discussed in the context of the /lib/ld-uClibc.so.0 symbolic link. For next I understand that link does not *need* to exist, but can the presence of the link still cause problems? I am getting build failures for: djbdns squid mawk linux-atm libdigest-sha1-perl dhcpd (expected) I will of course investigate and make corrections. In particular for dhcpd, since I am probably responsible for that build failure anyway :-) Thanks to everyone who has contributed to next so far. Like others I am really looking forward to running it on ARM. david Hi David; Andrew deserves the honour for the next branch, he did a really good job, so it was easy to install after a few hickups and testdrive, which is fun cause in my environment it's running smoother even in alpha state than 4.2 :) As Andrew said libdigest-sha1-perl should work today, at least it does for me. I haven't deleted the symbolic link for ld-uClibc.so.0 to compile the packages (which may explain djbdns build failure from time to time - will keep an eye on this one). I'll update dnsmasq to version 2.60 in next branch. It works as expected on my box - without further changes to my dnsmasq.conf. With 2.60 another player for DHCPv6 gets into the arena, you may look into it and compare it with dibbler etc.. It even has (limited(?)) support for router advertisements... (http://thekelleys.org.uk/dnsmasq/CHANGELOG) kp Thanks Andrew and kp, Hi David; I rebuilt from scratch on Wednesday after deleting the link. It had no effect. libdigest-sha1-perl is indeed better now (I got a buildpacket failure but I will re-build today to confirm I am using the latest code from Git). Yes, that should have been fixed thursday morning. The news of IPv6 support in dnsmasq is surprising to me but very encouraging for enhanced IPv6 support in a small footprint. kp: For djbdns I am getting an error that you also had on 28 Jan. Do you have a fix identified for this error: ./compile socket_accept6.c socket_connect6.c:9:21: fatal error: haveip6.h: No such file or directory Unfortunately no - djbdns and dhcpd are the only packages failing currently on my build system. kp -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Confirmation of /lib/ld-uClibc.so.0 symlink requirements
On Fri, 2012-03-16 at 18:54 +0100, KP Kirchdoerfer wrote: Am 16.03.2012 18:43, schrieb davidMbrooke: kp: For djbdns I am getting an error that you also had on 28 Jan. Do you have a fix identified for this error: ./compile socket_accept6.c socket_connect6.c:9:21: fatal error: haveip6.h: No such file or directory Unfortunately no - djbdns and dhcpd are the only packages failing currently on my build system. kp Hi kp, OK, I thought it was worth a try... :-) I will investigate djbdns tomorrow. I have found and fixed the error I was getting with linux-atm (bug in upstream qgen/Makefile.in). I have also tracked down the error I was getting with squid - missing libtool-ltdl-devel RPM on my build host. Have added a note to the Wiki. I think that means I am now seeing the same build behaviour as you and Andrew. David -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Confirmation of /lib/ld-uClibc.so.0 symlink requirements
14.03.2012 00:33, davidMbrooke пишет: Hi all, Now that Andrew and kp have done all the hard work on next I have finally found time to try to build it. I'm getting a few build errors (on Fedora 15, x86_64). From previous mails to this list I can see that some of these errors are expected but others are not. Some of the problems I am seeing have previously been discussed in the context of the /lib/ld-uClibc.so.0 symbolic link. For next I understand that link does not *need* to exist, but can the presence of the link still cause problems? I am getting build failures for: djbdns squid mawk linux-atm libdigest-sha1-perl dhcpd (expected) I will of course investigate and make corrections. In particular for dhcpd, since I am probably responsible for that build failure anyway :-) Thanks to everyone who has contributed to next so far. Like others I am really looking forward to running it on ARM. david Link isn't required. If link is present and points somewhere on working (partially) uClibc - it may cause failure if configure detects that it isn't cross-compiling, but just compiling. For failed packages it's needed to specify --build for configure. libdigest-sha1-perl may be failed for different reasons - if you rebuilded all from scratch today (after last repo modifications), show buildtool log. And dhcpd is failed due to very poor compiling rules (it builds piece of bind that is included in dhcpd package, for host arch, and then links it with dhcpd sources). I tried to do some fixes - but with negative result. It requires a lot of time and black magic to make it cross-compiled. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Confirmation of /lib/ld-uClibc.so.0 symlink requirements
Am 13.03.2012 23:33, schrieb davidMbrooke: Hi all, Now that Andrew and kp have done all the hard work on next I have finally found time to try to build it. I'm getting a few build errors (on Fedora 15, x86_64). From previous mails to this list I can see that some of these errors are expected but others are not. Some of the problems I am seeing have previously been discussed in the context of the /lib/ld-uClibc.so.0 symbolic link. For next I understand that link does not *need* to exist, but can the presence of the link still cause problems? I am getting build failures for: djbdns squid mawk linux-atm libdigest-sha1-perl dhcpd (expected) I will of course investigate and make corrections. In particular for dhcpd, since I am probably responsible for that build failure anyway :-) Thanks to everyone who has contributed to next so far. Like others I am really looking forward to running it on ARM. david Hi David; Andrew deserves the honour for the next branch, he did a really good job, so it was easy to install after a few hickups and testdrive, which is fun cause in my environment it's running smoother even in alpha state than 4.2 :) As Andrew said libdigest-sha1-perl should work today, at least it does for me. I haven't deleted the symbolic link for ld-uClibc.so.0 to compile the packages (which may explain djbdns build failure from time to time - will keep an eye on this one). I'll update dnsmasq to version 2.60 in next branch. It works as expected on my box - without further changes to my dnsmasq.conf. With 2.60 another player for DHCPv6 gets into the arena, you may look into it and compare it with dibbler etc.. It even has (limited(?)) support for router advertisements... (http://thekelleys.org.uk/dnsmasq/CHANGELOG) kp -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next
On 03/10/2012 08:46 AM, Mike Noyes wrote: On 03/06/2012 10:59 AM, Mike Noyes wrote: On 03/06/2012 09:55 AM, Andrew wrote: 06.03.2012 19:32, Mike Noyes пишет: On 11/26/2011 11:04 AM, Andrew wrote: -snip- Cross-compiling should work IMHO in right way (maybe except some buggy packages that'll require patching). Now toolchain is built for host arch, and it creates executables for target arch (in my case - x86_64 - x86). But I haven't hw to check how sources will be ran; also cross-compilation to non-x86 will require kernel config modification to target platform; also buildtool.pl/buildpacket.pl waits till they'll have 'arch' key specified; + MasterInclude.mk also will require small modification for conditional setting cflags/target name and so on. Andrew, With the release of Raspberry Pi and Cotton Candy, does cross-compiling work yet? These devices are generating considerable community interest. They're not ideal for our usual user base, but should provide a good way to test cross-compile at little expense to our developers. With Raspberry Pi and Cotton Candy, Linux Launches a Revolution https://www.pcworld.com/businesscenter/article/251088/with_raspberry_pi_and_cotton_candy_linux_launches_a_revolution.html IMHO there is no problem to compile something for ARM, so just look in distro for Raspberry Pi, esp. in kernel (patches, config). Now just buildtool/buildpacket requires modification to specify target arch, and all building process should be moved from from 'source' to 'source/arch'. I'll do automatic kernel-related package generation for each sub-arch on this or next week - now I think that I know in what way it can be done with minimal toolchain modifications. Andrew, Good to hear. :-) Time to place an order. Raspberry Pi Fedora Remix, our recommended distro, is ready for download! http://www.raspberrypi.org/archives/805 Other systems (Python script – packages for other platforms welcome): http://files.velocix.com/c1410/fedora/installer/source/faii-1.0.0.tar.gz Raspberry Pi - three distributions and media centre http://flosslinuxblog.blogspot.com/2012/03/raspberry-pi-three-distributions-and.html -- Mike Noyes http://sourceforge.net/users/mhnoyes https://profiles.google.com/mhnoyes -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next
On 03/06/2012 10:59 AM, Mike Noyes wrote: On 03/06/2012 09:55 AM, Andrew wrote: 06.03.2012 19:32, Mike Noyes пишет: On 11/26/2011 11:04 AM, Andrew wrote: -snip- Cross-compiling should work IMHO in right way (maybe except some buggy packages that'll require patching). Now toolchain is built for host arch, and it creates executables for target arch (in my case - x86_64 - x86). But I haven't hw to check how sources will be ran; also cross-compilation to non-x86 will require kernel config modification to target platform; also buildtool.pl/buildpacket.pl waits till they'll have 'arch' key specified; + MasterInclude.mk also will require small modification for conditional setting cflags/target name and so on. Andrew, With the release of Raspberry Pi and Cotton Candy, does cross-compiling work yet? These devices are generating considerable community interest. They're not ideal for our usual user base, but should provide a good way to test cross-compile at little expense to our developers. With Raspberry Pi and Cotton Candy, Linux Launches a Revolution https://www.pcworld.com/businesscenter/article/251088/with_raspberry_pi_and_cotton_candy_linux_launches_a_revolution.html IMHO there is no problem to compile something for ARM, so just look in distro for Raspberry Pi, esp. in kernel (patches, config). Now just buildtool/buildpacket requires modification to specify target arch, and all building process should be moved from from 'source' to 'source/arch'. I'll do automatic kernel-related package generation for each sub-arch on this or next week - now I think that I know in what way it can be done with minimal toolchain modifications. Andrew, Good to hear. :-) Time to place an order. Raspberry Pi Fedora Remix, our recommended distro, is ready for download! http://www.raspberrypi.org/archives/805 Other systems (Python script – packages for other platforms welcome): http://files.velocix.com/c1410/fedora/installer/source/faii-1.0.0.tar.gz -- Mike Noyes http://sourceforge.net/users/mhnoyes https://profiles.google.com/mhnoyes -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next
On 11/26/2011 11:04 AM, Andrew wrote: -snip- Cross-compiling should work IMHO in right way (maybe except some buggy packages that'll require patching). Now toolchain is built for host arch, and it creates executables for target arch (in my case - x86_64 - x86). But I haven't hw to check how sources will be ran; also cross-compilation to non-x86 will require kernel config modification to target platform; also buildtool.pl/buildpacket.pl waits till they'll have 'arch' key specified; + MasterInclude.mk also will require small modification for conditional setting cflags/target name and so on. Andrew, With the release of Raspberry Pi and Cotton Candy, does cross-compiling work yet? These devices are generating considerable community interest. They're not ideal for our usual user base, but should provide a good way to test cross-compile at little expense to our developers. With Raspberry Pi and Cotton Candy, Linux Launches a Revolution https://www.pcworld.com/businesscenter/article/251088/with_raspberry_pi_and_cotton_candy_linux_launches_a_revolution.html -- Mike Noyes http://sourceforge.net/users/mhnoyes https://profiles.google.com/mhnoyes -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next
On 03/06/2012 09:55 AM, Andrew wrote: 06.03.2012 19:32, Mike Noyes пишет: On 11/26/2011 11:04 AM, Andrew wrote: -snip- Cross-compiling should work IMHO in right way (maybe except some buggy packages that'll require patching). Now toolchain is built for host arch, and it creates executables for target arch (in my case - x86_64 - x86). But I haven't hw to check how sources will be ran; also cross-compilation to non-x86 will require kernel config modification to target platform; also buildtool.pl/buildpacket.pl waits till they'll have 'arch' key specified; + MasterInclude.mk also will require small modification for conditional setting cflags/target name and so on. Andrew, With the release of Raspberry Pi and Cotton Candy, does cross-compiling work yet? These devices are generating considerable community interest. They're not ideal for our usual user base, but should provide a good way to test cross-compile at little expense to our developers. With Raspberry Pi and Cotton Candy, Linux Launches a Revolution https://www.pcworld.com/businesscenter/article/251088/with_raspberry_pi_and_cotton_candy_linux_launches_a_revolution.html IMHO there is no problem to compile something for ARM, so just look in distro for Raspberry Pi, esp. in kernel (patches, config). Now just buildtool/buildpacket requires modification to specify target arch, and all building process should be moved from from 'source' to 'source/arch'. I'll do automatic kernel-related package generation for each sub-arch on this or next week - now I think that I know in what way it can be done with minimal toolchain modifications. Andrew, Good to hear. :-) Time to place an order. -- Mike Noyes http://sourceforge.net/users/mhnoyes https://profiles.google.com/mhnoyes -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] buc-next build from git
28.01.2012 21:04, KP Kirchdoerfer пишет:
Hi;
just completed a rebuild of the next-branch.
xtables-addon build without any problem.
Only a three packages fail to build: djbdns, openssh and dhcpd (which is
a know issue).
The buildtool log snippets below...
kp
djbdns:
make -j4 -C djbdns-1.05
make[1]: Entering directory `/opt/buildtool-next/source/djbdns/djbdns-1.05'
( cat warn-auto.sh; \
echo 'main=$1; shift'; \
echo exec `head -1 conf-ld` \
'-o $main $main.o ${1+$@}' \
) load
( cat warn-auto.sh; \
echo exec `head -1 conf-cc` '-c ${1+$@}' \
) compile
( cat warn-auto.sh; \
echo CC=\'`head -1 conf-cc`\'; \
echo LD=\'`head -1 conf-ld`\'; \
cat find-systype.sh; \
) | sh systype
chmod 755 compile
gcc -o auto-str auto-str.c buffer_put.c buffer_write.c byte_copy.c
str_len.c error.c
chmod 755 load
cat warn-auto.sh choose.sh \
| sed s}HOME}`head -1 conf-home`}g \
choose
./compile socket_connect6.c
auto-str.c:7:6: warning: conflicting types for built-in function 'puts'
[enabled by default]
chmod 755 choose
./compile socket_accept6.c
socket_connect6.c:9:21: fatal error: haveip6.h: No such file or directory
compilation terminated.
make[1]: *** [socket_connect6.o] Error 1
make[1]: *** Waiting for unfinished jobs
socket_accept6.c:7:21: fatal error: haveip6.h: No such file or directory
compilation terminated.
make[1]: *** [socket_accept6.o] Error 1
make[1]: Leaving directory `/opt/buildtool-next/source/djbdns/djbdns-1.05'
openssh:
checking if openpty correctly handles controlling tty... yes
checking whether getpgrp requires zero arguments... yes
checking OpenSSL header version... 105f (OpenSSL 1.0.0e 6 Sep 2011)
checking OpenSSL library version... 107f (OpenSSL 1.0.0g 18 Jan 2012)
checking whether OpenSSL's headers match the library... no
configure: error: Your OpenSSL headers do not match your
library. Check config.log for details.
If you are sure your installation is consistent, you can disable the check
by running ./configure --without-openssl-header-check.
Also see contrib/findssl.sh for help identifying header/library mismatches.
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
You ran rebuild with symlink for old ld-uClibc.so? This can be the
source of problem - configure script decides that used native
compilation. This can be fixed by specifying build host. I'll try to fix
it.
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] buc-next build from git
Am 28.01.2012 20:14, schrieb Andrew:
28.01.2012 21:04, KP Kirchdoerfer пишет:
Hi;
just completed a rebuild of the next-branch.
xtables-addon build without any problem.
Only a three packages fail to build: djbdns, openssh and dhcpd (which is
a know issue).
The buildtool log snippets below...
kp
djbdns:
make -j4 -C djbdns-1.05
make[1]: Entering directory `/opt/buildtool-next/source/djbdns/djbdns-1.05'
( cat warn-auto.sh; \
echo 'main=$1; shift'; \
echo exec `head -1 conf-ld` \
'-o $main $main.o ${1+$@}' \
) load
( cat warn-auto.sh; \
echo exec `head -1 conf-cc` '-c ${1+$@}' \
) compile
( cat warn-auto.sh; \
echo CC=\'`head -1 conf-cc`\'; \
echo LD=\'`head -1 conf-ld`\'; \
cat find-systype.sh; \
) | sh systype
chmod 755 compile
gcc -o auto-str auto-str.c buffer_put.c buffer_write.c byte_copy.c
str_len.c error.c
chmod 755 load
cat warn-auto.sh choose.sh \
| sed s}HOME}`head -1 conf-home`}g \
choose
./compile socket_connect6.c
auto-str.c:7:6: warning: conflicting types for built-in function 'puts'
[enabled by default]
chmod 755 choose
./compile socket_accept6.c
socket_connect6.c:9:21: fatal error: haveip6.h: No such file or directory
compilation terminated.
make[1]: *** [socket_connect6.o] Error 1
make[1]: *** Waiting for unfinished jobs
socket_accept6.c:7:21: fatal error: haveip6.h: No such file or directory
compilation terminated.
make[1]: *** [socket_accept6.o] Error 1
make[1]: Leaving directory `/opt/buildtool-next/source/djbdns/djbdns-1.05'
openssh:
checking if openpty correctly handles controlling tty... yes
checking whether getpgrp requires zero arguments... yes
checking OpenSSL header version... 105f (OpenSSL 1.0.0e 6 Sep 2011)
checking OpenSSL library version... 107f (OpenSSL 1.0.0g 18 Jan 2012)
checking whether OpenSSL's headers match the library... no
configure: error: Your OpenSSL headers do not match your
library. Check config.log for details.
If you are sure your installation is consistent, you can disable the check
by running ./configure --without-openssl-header-check.
Also see contrib/findssl.sh for help identifying header/library mismatches.
You ran rebuild with symlink for old ld-uClibc.so? This can be the
source of problem - configure script decides that used native
compilation. This can be fixed by specifying build host. I'll try to fix
it.
Yes, I did.
I always wondered why the next-branch does not check the symlink as the
the current version does? It works well for the 3x and 4.x version and
allows to compile different versions as long as one let the buildtool.pl
set the symlink at the start.
Has there been significant changes in that area?
BTW: Any ideas for xtables-addons?
I think it may be solved running the configure in 4.x - but why does it
work in the next branch?
kp
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] buc-next build from git
28.01.2012 22:03, KP Kirchdoerfer пишет:
Am 28.01.2012 20:14, schrieb Andrew:
28.01.2012 21:04, KP Kirchdoerfer пишет:
Hi;
just completed a rebuild of the next-branch.
xtables-addon build without any problem.
Only a three packages fail to build: djbdns, openssh and dhcpd (which is
a know issue).
The buildtool log snippets below...
kp
djbdns:
make -j4 -C djbdns-1.05
make[1]: Entering directory `/opt/buildtool-next/source/djbdns/djbdns-1.05'
( cat warn-auto.sh; \
echo 'main=$1; shift'; \
echo exec `head -1 conf-ld` \
'-o $main $main.o ${1+$@}' \
) load
( cat warn-auto.sh; \
echo exec `head -1 conf-cc` '-c ${1+$@}' \
) compile
( cat warn-auto.sh; \
echo CC=\'`head -1 conf-cc`\'; \
echo LD=\'`head -1 conf-ld`\'; \
cat find-systype.sh; \
) | sh systype
chmod 755 compile
gcc -o auto-str auto-str.c buffer_put.c buffer_write.c byte_copy.c
str_len.c error.c
chmod 755 load
cat warn-auto.sh choose.sh \
| sed s}HOME}`head -1 conf-home`}g \
choose
./compile socket_connect6.c
auto-str.c:7:6: warning: conflicting types for built-in function 'puts'
[enabled by default]
chmod 755 choose
./compile socket_accept6.c
socket_connect6.c:9:21: fatal error: haveip6.h: No such file or directory
compilation terminated.
make[1]: *** [socket_connect6.o] Error 1
make[1]: *** Waiting for unfinished jobs
socket_accept6.c:7:21: fatal error: haveip6.h: No such file or directory
compilation terminated.
make[1]: *** [socket_accept6.o] Error 1
make[1]: Leaving directory `/opt/buildtool-next/source/djbdns/djbdns-1.05'
openssh:
checking if openpty correctly handles controlling tty... yes
checking whether getpgrp requires zero arguments... yes
checking OpenSSL header version... 105f (OpenSSL 1.0.0e 6 Sep 2011)
checking OpenSSL library version... 107f (OpenSSL 1.0.0g 18 Jan 2012)
checking whether OpenSSL's headers match the library... no
configure: error: Your OpenSSL headers do not match your
library. Check config.log for details.
If you are sure your installation is consistent, you can disable the check
by running ./configure --without-openssl-header-check.
Also see contrib/findssl.sh for help identifying header/library mismatches.
You ran rebuild with symlink for old ld-uClibc.so? This can be the
source of problem - configure script decides that used native
compilation. This can be fixed by specifying build host. I'll try to fix
it.
Yes, I did.
I always wondered why the next-branch does not check the symlink as the
the current version does? It works well for the 3x and 4.x version and
allows to compile different versions as long as one let the buildtool.pl
set the symlink at the start.
Has there been significant changes in that area?
It doesn't need a symlink. It's a true cross-compilation. I added
'--build' option to configure cmdlines to force cross-compiling even if
exists working ld-uClibc.so, now I rebuilding all from scratch.
BTW: Any ideas for xtables-addons?
I think it may be solved running the configure in 4.x - but why does it
work in the next branch?
kp
In 4.x it looks like it looking on versions by linking libraries, and it
founds include in /usr/include and lib in staging dir. Try to add
'--without-openssl-header-check' and look if it help.
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] buc next build errors
27.11.2011 14:15, KP Kirchdoerfer пишет: initrd can not packaged because: Could not open file /opt/buildtool-next/source/initrd/files.i686 Hm, for me all is OK. During building 'getdep.sh' produces errors? In any case, I some updated getdep.sh script; it should work faster due to moving work mostly to AWK, and it should be more compatible with different versions of utils. pppoe-server can not be build: In file included from pppoe-server.c:29:0: pppoe-server.h:31:5: error: unknown type name 'EventHandler' pppoe-server.h:140:1: error: unknown type name 'EventSelector' pppoe-server.c:79:30: error: unknown type name 'EventSelector' pppoe-server.c:130:1: error: unknown type name 'EventSelector' pppoe-server.c: In function 'processPADR': pppoe-server.c:938:2: warning: implicit declaration of function 'Event_HandleChildExit' [-Wimplicit-function-declaration] pppoe-server.c: In function 'main': pppoe-server.c:1471:5: warning: implicit declaration of function 'Event_CreateSelector' [-Wimplicit-function-declaration] pppoe-server.c:1471:20: warning: assignment makes pointer from integer without a cast [enabled by default] pppoe-server.c:1477:5: warning: implicit declaration of function 'Event_HandleSignal' [-Wimplicit-function-declaration] pppoe-server.c:1491:2: warning: implicit declaration of function 'Event_AddHandler' [-Wimplicit-function-declaration] pppoe-server.c:1493:10: error: 'EVENT_FLAG_READABLE' undeclared (first use in this function) pppoe-server.c:1493:10: note: each undeclared identifier is reported only once for each function it appears in pppoe-server.c:1494:10: error: 'InterfaceHandler' undeclared (first use in this function) pppoe-server.c:1561:2: warning: implicit declaration of function 'Event_HandleEvent' [-Wimplicit-function-declaration] pppoe-server.c: At top level: pppoe-server.c:1874:18: error: unknown type name 'EventSelector' Can't reproduce - possible because I have installed libevent with headers in system. I committed patch, try it now. net-snmp also fails: /opt/buildtool-next/source/net-snmp/net-snmp-5.7.1/snmplib/.libs/libnetsnmp.so: warning: gethostbyaddr is obsolescent, use getaddrinfo() instead. /opt/buildtool-next/source/net-snmp/net-snmp-5.7.1/snmplib/.libs/libnetsnmp.so: warning: gethostbyname is obsolescent, use getnameinfo() instead. ./.libs/libnetsnmpmibs.so: undefined reference to `ipCidrRouteTable_dirty_set' ./.libs/libnetsnmpmibs.so: undefined reference to `ipCidrRouteTable_index_to_oid' ./.libs/libnetsnmpmibs.so: undefined reference to `ipCidrRouteTable_dirty_get' ./.libs/libnetsnmpmibs.so: undefined reference to `_ipCidrRouteTable_initialize_interface' ./.libs/libnetsnmpmibs.so: undefined reference to `_ipCidrRouteTable_shutdown_interface' collect2: ld returned 1 exit status Can't reproduce. Possible there is race condition in makefile. P.S. Please, post all errors/warnings with command that produces it. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next
Hi Andrew; You've done an oustanding job; thx very much! I've just updated my machine to ubuntu 11.10 and the pb's I've had (and reported) are gone - it's possible to build the packages again on the host, without the need for an older VM guest, very convenient. I'm currently in the process to release rc1 for 4.1.1, so not much time and cpu ressources to help you yet... My roadmap for Bering-uClibc is to have a release of 4.1.1 early next month and a 4.2 version with a reviewed kernel (see trac ticket #46) early next year. But hopefully enough time to build and test BuC next during that changes. Am 26.11.2011 18:37, schrieb Andrew: Hi all. I almost finished packages revision; it seems to be built OK except gnupg (I just didn't ported it), dhcpd (I spent much time for it but I can't force it to be built), libecap (it is needed somewhere?), and I commented some packages that are unneeded/obsolete. gnupg is needed, if we add signed packages, so no pb yet, libecap can used if we want to enhance squid, but today it is not used. Now it should be built OK, and I need help in testing - for broken dependencies, new bugs and so on, to be sure that new toolchain is working OK. Does tools/buildall.sh work today? The last time I tried it failed, cause it did not find a the buildenv target (for obvious reason). To do real world test on a real machine, I will need a geode kernel, the last time I looked into BuC next only a i686 kernel has been build. kp -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next
26.11.2011 20:32, KP Kirchdoerfer пишет: Hi Andrew; You've done an oustanding job; thx very much! I've just updated my machine to ubuntu 11.10 and the pb's I've had (and reported) are gone - it's possible to build the packages again on the host, without the need for an older VM guest, very convenient. I'm currently in the process to release rc1 for 4.1.1, so not much time and cpu ressources to help you yet... My roadmap for Bering-uClibc is to have a release of 4.1.1 early next month and a 4.2 version with a reviewed kernel (see trac ticket #46) early next year. But hopefully enough time to build and test BuC next during that changes. Am 26.11.2011 18:37, schrieb Andrew: Hi all. I almost finished packages revision; it seems to be built OK except gnupg (I just didn't ported it), dhcpd (I spent much time for it but I can't force it to be built), libecap (it is needed somewhere?), and I commented some packages that are unneeded/obsolete. gnupg is needed, if we add signed packages, so no pb yet, libecap can used if we want to enhance squid, but today it is not used. Now it should be built OK, and I need help in testing - for broken dependencies, new bugs and so on, to be sure that new toolchain is working OK. Does tools/buildall.sh work today? The last time I tried it failed, cause it did not find a the buildenv target (for obvious reason). To do real world test on a real machine, I will need a geode kernel, the last time I looked into BuC next only a i686 kernel has been build. kp I rebuilding all from scratch now and fixing small errors/default options conflicts that I made in scripts. I'll finish this today. gpg isn't a big trouble - I think i'll port all remain packages in Monday. Or somebody else will do it faster - if package configure was built with recent libtoolize/autoconf (newer than 2006-2007 year release), and if it hasn't dirty ugly hacls like dhcpd has, it's a trivial task :) I didn't look at buildall.sh; I'll look on it today. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next
Am 26.11.2011 19:40, schrieb Andrew: 26.11.2011 20:32, KP Kirchdoerfer пишет: Hi Andrew; You've done an oustanding job; thx very much! I've just updated my machine to ubuntu 11.10 and the pb's I've had (and reported) are gone - it's possible to build the packages again on the host, without the need for an older VM guest, very convenient. I'm currently in the process to release rc1 for 4.1.1, so not much time and cpu ressources to help you yet... My roadmap for Bering-uClibc is to have a release of 4.1.1 early next month and a 4.2 version with a reviewed kernel (see trac ticket #46) early next year. But hopefully enough time to build and test BuC next during that changes. Am 26.11.2011 18:37, schrieb Andrew: Hi all. I almost finished packages revision; it seems to be built OK except gnupg (I just didn't ported it), dhcpd (I spent much time for it but I can't force it to be built), libecap (it is needed somewhere?), and I commented some packages that are unneeded/obsolete. gnupg is needed, if we add signed packages, so no pb yet, libecap can used if we want to enhance squid, but today it is not used. Now it should be built OK, and I need help in testing - for broken dependencies, new bugs and so on, to be sure that new toolchain is working OK. Does tools/buildall.sh work today? The last time I tried it failed, cause it did not find a the buildenv target (for obvious reason). To do real world test on a real machine, I will need a geode kernel, the last time I looked into BuC next only a i686 kernel has been build. kp I rebuilding all from scratch now and fixing small errors/default options conflicts that I made in scripts. I'll finish this today. gpg isn't a big trouble - I think i'll port all remain packages in Monday. Or somebody else will do it faster - if package configure was built with recent libtoolize/autoconf (newer than 2006-2007 year release), and if it hasn't dirty ugly hacls like dhcpd has, it's a trivial task :) I'm pretty shure the requirements will be met. I didn't look at buildall.sh; I'll look on it today. Haven't looked into it, but I guess if sources.conf is cleaned, it should work. What about enabling the 486 and geode kernel again? Do you plan to test cross-compiling (and if, when)? It is my understanding that whole work has been done to build the packages for other processors than x86 - am I wrong? kp -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next
26.11.2011 20:53, KP Kirchdoerfer пишет: Am 26.11.2011 19:40, schrieb Andrew: 26.11.2011 20:32, KP Kirchdoerfer пишет: Hi Andrew; You've done an oustanding job; thx very much! I've just updated my machine to ubuntu 11.10 and the pb's I've had (and reported) are gone - it's possible to build the packages again on the host, without the need for an older VM guest, very convenient. I'm currently in the process to release rc1 for 4.1.1, so not much time and cpu ressources to help you yet... My roadmap for Bering-uClibc is to have a release of 4.1.1 early next month and a 4.2 version with a reviewed kernel (see trac ticket #46) early next year. But hopefully enough time to build and test BuC next during that changes. Am 26.11.2011 18:37, schrieb Andrew: Hi all. I almost finished packages revision; it seems to be built OK except gnupg (I just didn't ported it), dhcpd (I spent much time for it but I can't force it to be built), libecap (it is needed somewhere?), and I commented some packages that are unneeded/obsolete. gnupg is needed, if we add signed packages, so no pb yet, libecap can used if we want to enhance squid, but today it is not used. Now it should be built OK, and I need help in testing - for broken dependencies, new bugs and so on, to be sure that new toolchain is working OK. Does tools/buildall.sh work today? The last time I tried it failed, cause it did not find a the buildenv target (for obvious reason). To do real world test on a real machine, I will need a geode kernel, the last time I looked into BuC next only a i686 kernel has been build. kp I rebuilding all from scratch now and fixing small errors/default options conflicts that I made in scripts. I'll finish this today. gpg isn't a big trouble - I think i'll port all remain packages in Monday. Or somebody else will do it faster - if package configure was built with recent libtoolize/autoconf (newer than 2006-2007 year release), and if it hasn't dirty ugly hacls like dhcpd has, it's a trivial task :) I'm pretty shure the requirements will be met. I didn't look at buildall.sh; I'll look on it today. Haven't looked into it, but I guess if sources.conf is cleaned, it should work. I also think thai it'll be enough. I commented non-ported packages. I'll commit all changes when I finished rebuilding (1-2 hours). What about enabling the 486 and geode kernel again? They are enabled :) Do you plan to test cross-compiling (and if, when)? It is my understanding that whole work has been done to build the packages for other processors than x86 - am I wrong? kp Right. Cross-compiling should work IMHO in right way (maybe except some buggy packages that'll require patching). Now toolchain is built for host arch, and it creates executables for target arch (in my case - x86_64 - x86). But I haven't hw to check how sources will be ran; also cross-compilation to non-x86 will require kernel config modification to target platform; also buildtool.pl/buildpacket.pl waits till they'll have 'arch' key specified; + MasterInclude.mk also will require small modification for conditional setting cflags/target name and so on. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch
Andrew at 02.11.2011 23:19, Andrew wrote: Hi all again. Today I finished porting of all basic set of packages that are included by default into leaf.cfg, + some more. I did this mostly for comparision of RAM usage; -O2 + some busybox features + some updated software versions gives ~23M memory usage for i686 iso; 4.1.1 version eats ~20M in that case - IMHO not significant difference. So I think that we can use -O2 for userland. Hey, I'd go for 15% anytime Most of my target systems have 64M memory so this increase is significant. Even though we dropped the requirement for floopies we should still target small embedded systems. Did anyone check the size of OpenWRT packages/footprint? They have cross compilation tools too. cheers Erich smime.p7s Description: S/MIME Kryptografische Unterschrift -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch
03.11.2011 09:12, Erich Titl пишет: Andrew at 02.11.2011 23:19, Andrew wrote: Hi all again. Today I finished porting of all basic set of packages that are included by default into leaf.cfg, + some more. I did this mostly for comparision of RAM usage; -O2 + some busybox features + some updated software versions gives ~23M memory usage for i686 iso; 4.1.1 version eats ~20M in that case - IMHO not significant difference. So I think that we can use -O2 for userland. Hey, I'd go for 15% anytime Most of my target systems have 64M memory so this increase is significant. Even though we dropped the requirement for floopies we should still target small embedded systems. Do you really have systems that usually uses more than 70% of memory? IMHO this growth is significant only for 32M devices. P.S. linux kernel can load archived modules; this can slightly reduce memory consumption by ramfs. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch
03.11.2011 11:28, Andrew пишет: P.S. linux kernel can load archived modules; this can slightly reduce memory consumption by ramfs. From now 'next' branch uses compressed modules - now default memory footprint is ~20M; also it'll require much less RAM for module auto-loading (compressed module tree weights ~10M instead of ~20M). IMHO this modifocation also can be merged into 4.x branch (at first look it shouldn't break anything) -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch
Hi Andrew at 03.11.2011 12:27, Andrew wrote: 03.11.2011 11:28, Andrew пишет: P.S. linux kernel can load archived modules; this can slightly reduce memory consumption by ramfs. From now 'next' branch uses compressed modules - now default memory footprint is ~20M; also it'll require much less RAM for module auto-loading (compressed module tree weights ~10M instead of ~20M). IMHO this modifocation also can be merged into 4.x branch (at first look it shouldn't break anything) Let's see, the compression is just a simple gzip of the kernel modules on the media, which should be compressed anyway in the .lrp format. Once the (kernel) modules are loaded in kernel space there is IMHO no need to keep them in /lib/modules anyway, unless they need to be reloaded. The cheapest way to save space is to simply not use /lib/modules/kernel.. on the ram disk. cheers Erich smime.p7s Description: S/MIME Kryptografische Unterschrift -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch
03.11.2011 14:58, Erich Titl пишет: Hi Andrew at 03.11.2011 12:27, Andrew wrote: 03.11.2011 11:28, Andrew пишет: P.S. linux kernel can load archived modules; this can slightly reduce memory consumption by ramfs. From now 'next' branch uses compressed modules - now default memory footprint is ~20M; also it'll require much less RAM for module auto-loading (compressed module tree weights ~10M instead of ~20M). IMHO this modifocation also can be merged into 4.x branch (at first look it shouldn't break anything) Let's see, the compression is just a simple gzip of the kernel modules on the media, which should be compressed anyway in the .lrp format. Right. But .lrp is placed on big storage, and it's content - on ramdisk w/o compression. Once the (kernel) modules are loaded in kernel space there is IMHO no need to keep them in /lib/modules anyway, unless they need to be reloaded. The cheapest way to save space is to simply not use /lib/modules/kernel.. on the ram disk. cheers Erich You never can surely know when somebody will need modules. For ex.: hotplug, new iptables rules... Yes, modules can be cleaned in local.start if it's surely not needed - but generally they should be present in system. Also compression decreases memory consumption for hardware autodetect for ~10MB. It has just one side-effect - longer depmod/modprobe execution. IMHO this is not too critical - I think on i486 it'll take additional 10-20 seconds max for booting. So why not to use it? :) -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch
On Wed, 2011-11-02 at 15:36 +0200, Andrew wrote: 01.11.2011 21:34, davidMbrooke пишет: On Tue, 2011-11-01 at 21:21 +0200, Andrew wrote: 01.11.2011 20:11, KP Kirchdoerfer пишет: Am Dienstag, 1. November 2011, 00:06:50 schrieb Andrew: The Yocto Project has the backing of The Linux Foundation. There is an overview and Quick Start guide at http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html dMb At first look on documentation - it looks like enough complex system that is covered by enough simple front-end - and IMHO such type of systems usually are hard in customization for needed objectives. Integrated qemu for testing looks good, but I suspect that it's working only with GUI. If you use it, I have a question: it has possibility to work in this buildenv w/o GUI, just from CLI terminal? Even w/o all features, just package building/editing? I have now done a little testing with Yocto Project 1.1. It works OK though it is slow to build the default configuration (because it is building so much - including an X11 GUI for the embedded device!). The developers do seem to have thought about customization of the toolchain and support add-on layers which can be managed separately from the underlying build system. This means that updates can be integrated easily - we would not need to fork the Yocto Project tools but would develop and maintain an add-on layer. It does seem possible to use it from a CLI terminal - the command bitbake (equivalent of our buildtool/buildpacket/buildimage) runs from the command line and can build anything from a single Package to a whole Image. See also http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#platdev-appdev Switching to this would be big change though. dMb -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch
01.11.2011 21:34, davidMbrooke пишет: On Tue, 2011-11-01 at 21:21 +0200, Andrew wrote: 01.11.2011 20:11, KP Kirchdoerfer пишет: Am Dienstag, 1. November 2011, 00:06:50 schrieb Andrew: Not a proposal, just a quick idea: it might be easier longterm to fork again from buildroot and adjust it to our needs, instead of hacking a hack once more. AFAIK David looked into OPenyoko(?), maybe he'll has something to add about his findings... If somebody can move current infrastructure (.lrp creation, etc) to other building environment and it'll be enough useful and simple (not worse than current buildenv) - I haven't any votes against this. In any case, cleaned/ported packages can be moved to new building system easier. That would be http://www.yoctoproject.org/ which does look interesting. I did some tests with the 1.0 release and hit some problems but 1.1 is out since October. I will download now and check if the new version works better. The Yocto Project has the backing of The Linux Foundation. There is an overview and Quick Start guide at http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html It would need to be modified to create .lrp files (rather than .rpm or .deb) and I do not know how difficult that might be. dMb At first look on documentation - it looks like enough complex system that is covered by enough simple front-end - and IMHO such type of systems usually are hard in customization for needed objectives. Integrated qemu for testing looks good, but I suspect that it's working only with GUI. If you use it, I have a question: it has possibility to work in this buildenv w/o GUI, just from CLI terminal? Even w/o all features, just package building/editing? -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch
01.11.2011 01:39, KP Kirchdoerfer пишет: Am Montag, 31. Oktober 2011, 12:40:12 schrieb Andrew: 31.10.2011 13:05, KP Kirchdoerfer пишет: Am Montag, 31. Oktober 2011, 11:19:38 schrieb Andrew: 31.10.2011 12:05, 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. Andrew; in my case it failed while trying to build gcc: checking for the correct version of gmp.h... no configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+ kp Do you have libgmp installed in your system? I exclude it from toolchain because it is present in all modern distros, and it was needed earlier only due to cross-compile x86 gcc binaries on x86_64 system. I have had installed libgmp, but it does not provide gmp.h, so I installed libgmp-dev, libmpfr-dev and libmpc-dev. Seems to be different to other distributions. So it seems to build now... Right, development headers are needed for software building. P.S. Do we really need to pull all host-related binaries (automake, etc) in toolchain? Why we can't simply use system ones, and add them into buildenv prerequisites? As you can see above, even the prerequistes changes between distribution; but over the years we ran in all sorts of issues, when a host system has been changed, too new version of autoconf, later outdated versions, that failed due to changes in the buildtool.cfg files etc... So the aim was to have the buildenvironment as self-containded as possible to be independent of the build system. It is my experience that this is still the better way in the long-term. kp Usually troubles are present with too new versions and too old packages - but this will be noticed by all developers who used modern distros (and, of course, me - I use gentoo so I have enough fresh libtool/automake/autoconf). About old distros - maybe CentOS can be common example for such distro (it has enough old automake/autoconf because software isn't updated through distro lifecycle - there are only backported fixes), and I think that there are no 'older' distros in use among peoples who are interested in building all from source. So IMHO it'll be enough to check building on CentOS 5 and some modern distro (Gentoo or latest Fedora/Ubuntu) to be sure that it'll be built on almost all target hosts. Also, we really didn't pull all dependencies - at least Perl, make, libtool (which sometimes cause headache), etc - so IMHO partial dependency isn't enough good solution. Hi Andrew; the main question is, what will happen, if a new distro breaks the toolchain? This wasn't happened earlier (maybe except one or two exclusions) - at least, updating autoconf/automake wasn't I remember vaguely, we have had struggled with this years ago... I predict, that we'll have to include prerequisites within two years :) But then, I'l be happy if it'll proof me wrong. Let's look. I'm surprised about the changes for iproute (haven't had the time to look into the latest commits). I compiled iproute2 with uclibc-0.9.32 successfully without the chanes you committed. What caused the changes, if not uClibc? Just to understand, what may occur if we update other packages. kp This is not for uClibc. This is for right cross-compilation. iproute2 makefile isn't designed for cross-compilation (it has hardcoded gcc name and it's flags so on). This is one of mentioned non-trivial exclusions. Possible in later versions it will be fixed and we'll not need to have such ugly tricks in our makefile. -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch
Am Dienstag, 1. November 2011, 00:06:50 schrieb Andrew: Hi all again. Now I finished porting of basic package set to new toolchain - all that are needed for building kernel, root.lrp, initrd and moddb, to look how it's working into VM. Minimal system booted OK; also I saw that syslog-ng in new environment is linked with libpthread - so I included in into root.lrp (it is just near 80k). I changed optmization from -Os to -O2 - it causes some size growth, but not catastrophic (+15..20% of user-level app size average); IMHO after initrd/moddb cleanup system still will be usable on 16M devices (default i686 minimal set now requires exact 14MB RAM in VM with one e1000 NIC - comparable to 4.x branch). So now there are such tasks: 1) Add 'arch' command line key for buildtool.pl/buildpackage.pl 2) Add 'template' support for kernel-related package that can have multiple subarchs (moddb and so on) 3) Port other 100+ packages into new toolchain (this is mostly trivial task, except some exceptions with poor makefile/configure); don't forget that ifenslave/vconfig now is present into busybox 4) Add 'arch' to .lrp and checking for corresponding .lrp arch and system arch on .lrp loading/updating, and 'noarch' special type for non-binary packages (scripts etc) 5) Add uClibc++ into toolchain 6) Maybe other important things that I missed because I'm tired enough, and 7) Test toolchain/software assembly on different distros/platforms - I excluded all toolchain apps that should be present in any distro, like nasm/automake/bison (to simplify toolchain and to detect potentially poor/problematic code). Hi Andrew; I successfully tested the changes today, all seems to build well. I'd liked to start with test porting packages myself, but I'm not shure what has to be changed for simple package like dnsmasq and how to test, if everything went as expected. But then I looked into the changes you've made for ppp and think we may sit back and think a few days about the options we have. I want to explain my thoughts: The current buildtool has been adopted from early buildroot/buildtool scripts for uClibc and hacked to work for our needs. Over the years more cross-toolchains came up, and some a lot cleaner, than our ones. I looked today again at buildroot (buildroot.org), which has been improved a lot over the years, since Arne and Martin build our buildtool stuff. And I compared esp. their ppp setup, which seems a lot easier to understand, than what I find in BuC-next. And even it will have a steep learning-curve to learn a new buildtool environment, it seems easier than creating such intrusive makefiles patches as you did - at least for me. And I don't know, how we can write a documentation about how to build a new package, if it possibly requires such patches. Maybe I do need just to work with the changes you made and get used to build packages with toolchain, but then this is such a major change for Bering-uClibc (in terms of effort *and* result), we may take the time to think a bit more about our tool for the forthcoming years. Not a proposal, just a quick idea: it might be easier longterm to fork again from buildroot and adjust it to our needs, instead of hacking a hack once more. AFAIK David looked into OPenyoko(?), maybe he'll has something to add about his findings... Andrew; don't get me wrong, I really appreciate your work and commitment, I just want to make shure that before we put that amount of work (rework 180+ packages, rewrite a lot of documentation, doing all sort of tests), we'll take the time to discuss the options, needs etc. to get something we'll have fun to work with, which can be easy enough to encourage new developers, packagers... every opinion is welcome, thx for reading kp -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch
01.11.2011 20:11, KP Kirchdoerfer пишет: Am Dienstag, 1. November 2011, 00:06:50 schrieb Andrew: Hi all again. Now I finished porting of basic package set to new toolchain - all that are needed for building kernel, root.lrp, initrd and moddb, to look how it's working into VM. Minimal system booted OK; also I saw that syslog-ng in new environment is linked with libpthread - so I included in into root.lrp (it is just near 80k). I changed optmization from -Os to -O2 - it causes some size growth, but not catastrophic (+15..20% of user-level app size average); IMHO after initrd/moddb cleanup system still will be usable on 16M devices (default i686 minimal set now requires exact 14MB RAM in VM with one e1000 NIC - comparable to 4.x branch). So now there are such tasks: 1) Add 'arch' command line key for buildtool.pl/buildpackage.pl 2) Add 'template' support for kernel-related package that can have multiple subarchs (moddb and so on) 3) Port other 100+ packages into new toolchain (this is mostly trivial task, except some exceptions with poor makefile/configure); don't forget that ifenslave/vconfig now is present into busybox 4) Add 'arch' to .lrp and checking for corresponding .lrp arch and system arch on .lrp loading/updating, and 'noarch' special type for non-binary packages (scripts etc) 5) Add uClibc++ into toolchain 6) Maybe other important things that I missed because I'm tired enough, and 7) Test toolchain/software assembly on different distros/platforms - I excluded all toolchain apps that should be present in any distro, like nasm/automake/bison (to simplify toolchain and to detect potentially poor/problematic code). Hi Andrew; I successfully tested the changes today, all seems to build well. I'd liked to start with test porting packages myself, but I'm not shure what has to be changed for simple package like dnsmasq and how to test, if everything went as expected. Just look if i is linked with uClibc, not system glibc. If yes - all is built OK. But then I looked into the changes you've made for ppp and think we may sit back and think a few days about the options we have. I want to explain my thoughts: The current buildtool has been adopted from early buildroot/buildtool scripts for uClibc and hacked to work for our needs. Over the years more cross-toolchains came up, and some a lot cleaner, than our ones. I looked today again at buildroot (buildroot.org), which has been improved a lot over the years, since Arne and Martin build our buildtool stuff. And I compared esp. their ppp setup, which seems a lot easier to understand, than what I find in BuC-next. And even it will have a steep learning-curve to learn a new buildtool environment, it seems easier than creating such intrusive makefiles patches as you did - at least for me. And I don't know, how we can write a documentation about how to build a new package, if it possibly requires such patches. Changes in ppp isn't too heavy - just update plugin's rp_pppoe version to 3.10 (which is now in building tree) and to remove missing library (libresolv) - that is for unknown reason isn't present as separate library and possible included into one of uClibc binaries. Other isn't changed from earlier version. You may look on more common cases - packages with 'true' configure script. They are assembled like on native system. Without need for heavy modifications, without pulling system libraries by mistake and so on. If developers didn't break cross-compilation by ugly hacks (like in dhcpd - which pulls full isc-bind and tries to build it on one of building steps). And I think that we'll clean many hacks from packages - at least, accel-pptp now is assembled in more clear way. Maybe I do need just to work with the changes you made and get used to build packages with toolchain, but then this is such a major change for Bering-uClibc (in terms of effort *and* result), we may take the time to think a bit more about our tool for the forthcoming years. Not a proposal, just a quick idea: it might be easier longterm to fork again from buildroot and adjust it to our needs, instead of hacking a hack once more. AFAIK David looked into OPenyoko(?), maybe he'll has something to add about his findings... If somebody can move current infrastructure (.lrp creation, etc) to other building environment and it'll be enough useful and simple (not worse than current buildenv) - I haven't any votes against this. In any case, cleaned/ported packages can be moved to new building system easier. Andrew; don't get me wrong, I really appreciate your work and commitment, I just want to make shure that before we put that amount of work (rework 180+ packages, rewrite a lot of documentation, doing all sort of tests), we'll take the time to discuss the options, needs etc. to get something we'll have fun to work with, which can be easy enough to encourage new developers, packagers... every opinion is welcome,
Re: [leaf-devel] BuC-next branch
On Tue, 2011-11-01 at 21:21 +0200, Andrew wrote: 01.11.2011 20:11, KP Kirchdoerfer пишет: Am Dienstag, 1. November 2011, 00:06:50 schrieb Andrew: Not a proposal, just a quick idea: it might be easier longterm to fork again from buildroot and adjust it to our needs, instead of hacking a hack once more. AFAIK David looked into OPenyoko(?), maybe he'll has something to add about his findings... If somebody can move current infrastructure (.lrp creation, etc) to other building environment and it'll be enough useful and simple (not worse than current buildenv) - I haven't any votes against this. In any case, cleaned/ported packages can be moved to new building system easier. That would be http://www.yoctoproject.org/ which does look interesting. I did some tests with the 1.0 release and hit some problems but 1.1 is out since October. I will download now and check if the new version works better. The Yocto Project has the backing of The Linux Foundation. There is an overview and Quick Start guide at http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html It would need to be modified to create .lrp files (rather than .rpm or .deb) and I do not know how difficult that might be. dMb -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch - libresolv
Hi Andrew; Am Dienstag, 1. November 2011, 20:21:24 schrieb Andrew: Changes in ppp isn't too heavy - just update plugin's rp_pppoe version to 3.10 (which is now in building tree) and to remove missing library (libresolv) - that is for unknown reason isn't present as separate library and possible included into one of uClibc binaries. Other isn't changed from earlier version. I recently worked on a port to uClibc 0.9.32 (see Trac ticket #39), where I provided a config, that compiled almost every package we have (only yate and mdadm failed). Comparing the uClibc config I attached to the ticket, with the one you committed for toolchain, I see that you probably may have missed an option for libresolv... # UCLIBC_HAS_LIBRESOLV_STUB is not set # UCLIBC_HAS_LIBNSL_STUB is not set --- UCLIBC_HAS_LIBRESOLV_STUB=y UCLIBC_HAS_LIBNSL_STUB=y kp -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch - libresolv
01.11.2011 21:44, KP Kirchdoerfer пишет: Hi Andrew; Am Dienstag, 1. November 2011, 20:21:24 schrieb Andrew: Changes in ppp isn't too heavy - just update plugin's rp_pppoe version to 3.10 (which is now in building tree) and to remove missing library (libresolv) - that is for unknown reason isn't present as separate library and possible included into one of uClibc binaries. Other isn't changed from earlier version. I recently worked on a port to uClibc 0.9.32 (see Trac ticket #39), where I provided a config, that compiled almost every package we have (only yate and mdadm failed). Comparing the uClibc config I attached to the ticket, with the one you committed for toolchain, I see that you probably may have missed an option for libresolv... # UCLIBC_HAS_LIBRESOLV_STUB is not set # UCLIBC_HAS_LIBNSL_STUB is not set --- UCLIBC_HAS_LIBRESOLV_STUB=y UCLIBC_HAS_LIBNSL_STUB=y kp Thanks, it'll be fixed. -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch
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. Andrew; in my case it failed while trying to build gcc: checking for the correct version of gmp.h... no configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+ kp -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. 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
Re: [leaf-devel] BuC-next branch
31.10.2011 12:05, 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. Andrew; in my case it failed while trying to build gcc: checking for the correct version of gmp.h... no configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+ kp Do you have libgmp installed in your system? I exclude it from toolchain because it is present in all modern distros, and it was needed earlier only due to cross-compile x86 gcc binaries on x86_64 system. P.S. Do we really need to pull all host-related binaries (automake, etc) in toolchain? Why we can't simply use system ones, and add them into buildenv prerequisites? -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. 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
Re: [leaf-devel] BuC-next branch
Am Montag, 31. Oktober 2011, 11:19:38 schrieb Andrew: 31.10.2011 12:05, 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. Andrew; in my case it failed while trying to build gcc: checking for the correct version of gmp.h... no configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+ kp Do you have libgmp installed in your system? I exclude it from toolchain because it is present in all modern distros, and it was needed earlier only due to cross-compile x86 gcc binaries on x86_64 system. I have had installed libgmp, but it does not provide gmp.h, so I installed libgmp-dev, libmpfr-dev and libmpc-dev. Seems to be different to other distributions. So it seems to build now... P.S. Do we really need to pull all host-related binaries (automake, etc) in toolchain? Why we can't simply use system ones, and add them into buildenv prerequisites? As you can see above, even the prerequistes changes between distribution; but over the years we ran in all sorts of issues, when a host system has been changed, too new version of autoconf, later outdated versions, that failed due to changes in the buildtool.cfg files etc... So the aim was to have the buildenvironment as self-containded as possible to be independent of the build system. It is my experience that this is still the better way in the long-term. kp -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. 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
Re: [leaf-devel] BuC-next branch
Am Montag, 31. Oktober 2011, 12:05:01 schrieb KP Kirchdoerfer: Am Montag, 31. Oktober 2011, 11:19:38 schrieb Andrew: 31.10.2011 12:05, 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. Andrew; in my case it failed while trying to build gcc: checking for the correct version of gmp.h... no configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+ kp Do you have libgmp installed in your system? I exclude it from toolchain because it is present in all modern distros, and it was needed earlier only due to cross-compile x86 gcc binaries on x86_64 system. I have had installed libgmp, but it does not provide gmp.h, so I installed libgmp-dev, libmpfr-dev and libmpc-dev. Seems to be different to other distributions. So it seems to build now... Not really... make[4]: Leaving directory `/opt/buildtool-next/build/toolchain/gcc- stage1/i486-pc-linux-uclibc/libgcc' /opt/buildtool-next/build/toolchain/gcc-stage1/./gcc/xgcc -B/opt/buildtool- next/build/toolchain/gcc-stage1/./gcc/ -B/opt/buildtool- next/toolchain/i386/i486-pc-linux-uclibc/bin/ -B/opt/buildtool- next/toolchain/i386/i486-pc-linux-uclibc/lib/ -isystem /opt/buildtool- next/toolchain/i386/i486-pc-linux-uclibc/include -isystem /opt/buildtool- next/toolchain/i386/i486-pc-linux-uclibc/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 - D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../.././gcc - I/opt/buildtool-next/source/toolchain/gcc-4.6.2/libgcc -I/opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/. -I/opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/../gcc -I/opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/../include -I/opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/config/libbid - DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/../gcc/libgcc2.c \ In file included from /opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/../gcc/libgcc2.c:29:0: /opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/../gcc/tsystem.h:87:19: fatal error: stdio.h: No such file or directory compilation terminated. make[3]: *** [_muldi3.o] Error 1 kp -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. 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
Re: [leaf-devel] BuC-next branch
31.10.2011 13:05, KP Kirchdoerfer пишет: Am Montag, 31. Oktober 2011, 11:19:38 schrieb Andrew: 31.10.2011 12:05, 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. Andrew; in my case it failed while trying to build gcc: checking for the correct version of gmp.h... no configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+ kp Do you have libgmp installed in your system? I exclude it from toolchain because it is present in all modern distros, and it was needed earlier only due to cross-compile x86 gcc binaries on x86_64 system. I have had installed libgmp, but it does not provide gmp.h, so I installed libgmp-dev, libmpfr-dev and libmpc-dev. Seems to be different to other distributions. So it seems to build now... Right, development headers are needed for software building. P.S. Do we really need to pull all host-related binaries (automake, etc) in toolchain? Why we can't simply use system ones, and add them into buildenv prerequisites? As you can see above, even the prerequistes changes between distribution; but over the years we ran in all sorts of issues, when a host system has been changed, too new version of autoconf, later outdated versions, that failed due to changes in the buildtool.cfg files etc... So the aim was to have the buildenvironment as self-containded as possible to be independent of the build system. It is my experience that this is still the better way in the long-term. kp Usually troubles are present with too new versions and too old packages - but this will be noticed by all developers who used modern distros (and, of course, me - I use gentoo so I have enough fresh libtool/automake/autoconf). About old distros - maybe CentOS can be common example for such distro (it has enough old automake/autoconf because software isn't updated through distro lifecycle - there are only backported fixes), and I think that there are no 'older' distros in use among peoples who are interested in building all from source. So IMHO it'll be enough to check building on CentOS 5 and some modern distro (Gentoo or latest Fedora/Ubuntu) to be sure that it'll be built on almost all target hosts. Also, we really didn't pull all dependencies - at least Perl, make, libtool (which sometimes cause headache), etc - so IMHO partial dependency isn't enough good solution. -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. 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
Re: [leaf-devel] BuC-next branch
31.10.2011 13:16, KP Kirchdoerfer пишет: Am Montag, 31. Oktober 2011, 12:05:01 schrieb KP Kirchdoerfer: Am Montag, 31. Oktober 2011, 11:19:38 schrieb Andrew: 31.10.2011 12:05, 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. Andrew; in my case it failed while trying to build gcc: checking for the correct version of gmp.h... no configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+ kp Do you have libgmp installed in your system? I exclude it from toolchain because it is present in all modern distros, and it was needed earlier only due to cross-compile x86 gcc binaries on x86_64 system. I have had installed libgmp, but it does not provide gmp.h, so I installed libgmp-dev, libmpfr-dev and libmpc-dev. Seems to be different to other distributions. So it seems to build now... Not really... make[4]: Leaving directory `/opt/buildtool-next/build/toolchain/gcc- stage1/i486-pc-linux-uclibc/libgcc' /opt/buildtool-next/build/toolchain/gcc-stage1/./gcc/xgcc -B/opt/buildtool- next/build/toolchain/gcc-stage1/./gcc/ -B/opt/buildtool- next/toolchain/i386/i486-pc-linux-uclibc/bin/ -B/opt/buildtool- next/toolchain/i386/i486-pc-linux-uclibc/lib/ -isystem /opt/buildtool- next/toolchain/i386/i486-pc-linux-uclibc/include -isystem /opt/buildtool- next/toolchain/i386/i486-pc-linux-uclibc/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 - D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../.././gcc - I/opt/buildtool-next/source/toolchain/gcc-4.6.2/libgcc -I/opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/. -I/opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/../gcc -I/opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/../include -I/opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/config/libbid - DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/../gcc/libgcc2.c \ In file included from /opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/../gcc/libgcc2.c:29:0: /opt/buildtool- next/source/toolchain/gcc-4.6.2/libgcc/../gcc/tsystem.h:87:19: fatal error: stdio.h: No such file or directory compilation terminated. make[3]: *** [_muldi3.o] Error 1 kp Fixed. uClibc headers were installed into wrong place by my error. -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. 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
Re: [leaf-devel] BuC-next branch
Hi all again. Now I finished porting of basic package set to new toolchain - all that are needed for building kernel, root.lrp, initrd and moddb, to look how it's working into VM. Minimal system booted OK; also I saw that syslog-ng in new environment is linked with libpthread - so I included in into root.lrp (it is just near 80k). I changed optmization from -Os to -O2 - it causes some size growth, but not catastrophic (+15..20% of user-level app size average); IMHO after initrd/moddb cleanup system still will be usable on 16M devices (default i686 minimal set now requires exact 14MB RAM in VM with one e1000 NIC - comparable to 4.x branch). So now there are such tasks: 1) Add 'arch' command line key for buildtool.pl/buildpackage.pl 2) Add 'template' support for kernel-related package that can have multiple subarchs (moddb and so on) 3) Port other 100+ packages into new toolchain (this is mostly trivial task, except some exceptions with poor makefile/configure); don't forget that ifenslave/vconfig now is present into busybox 4) Add 'arch' to .lrp and checking for corresponding .lrp arch and system arch on .lrp loading/updating, and 'noarch' special type for non-binary packages (scripts etc) 5) Add uClibc++ into toolchain 6) Maybe other important things that I missed because I'm tired enough, and 7) Test toolchain/software assembly on different distros/platforms - I excluded all toolchain apps that should be present in any distro, like nasm/automake/bison (to simplify toolchain and to detect potentially poor/problematic code). Here is list of updated/fixed packages: linux toolchain dropbear kernel busybox bbntpd modules local config iproute etc initrd e3 cron libnet flex syslog-ng tcp_wrappers root syslinux kmodules libpcap ppp accel-pptp igb -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. 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
Re: [leaf-devel] BuC-next branch
Am Montag, 31. Oktober 2011, 12:40:12 schrieb Andrew: 31.10.2011 13:05, KP Kirchdoerfer пишет: Am Montag, 31. Oktober 2011, 11:19:38 schrieb Andrew: 31.10.2011 12:05, 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. Andrew; in my case it failed while trying to build gcc: checking for the correct version of gmp.h... no configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+ kp Do you have libgmp installed in your system? I exclude it from toolchain because it is present in all modern distros, and it was needed earlier only due to cross-compile x86 gcc binaries on x86_64 system. I have had installed libgmp, but it does not provide gmp.h, so I installed libgmp-dev, libmpfr-dev and libmpc-dev. Seems to be different to other distributions. So it seems to build now... Right, development headers are needed for software building. P.S. Do we really need to pull all host-related binaries (automake, etc) in toolchain? Why we can't simply use system ones, and add them into buildenv prerequisites? As you can see above, even the prerequistes changes between distribution; but over the years we ran in all sorts of issues, when a host system has been changed, too new version of autoconf, later outdated versions, that failed due to changes in the buildtool.cfg files etc... So the aim was to have the buildenvironment as self-containded as possible to be independent of the build system. It is my experience that this is still the better way in the long-term. kp Usually troubles are present with too new versions and too old packages - but this will be noticed by all developers who used modern distros (and, of course, me - I use gentoo so I have enough fresh libtool/automake/autoconf). About old distros - maybe CentOS can be common example for such distro (it has enough old automake/autoconf because software isn't updated through distro lifecycle - there are only backported fixes), and I think that there are no 'older' distros in use among peoples who are interested in building all from source. So IMHO it'll be enough to check building on CentOS 5 and some modern distro (Gentoo or latest Fedora/Ubuntu) to be sure that it'll be built on almost all target hosts. Also, we really didn't pull all dependencies - at least Perl, make, libtool (which sometimes cause headache), etc - so IMHO partial dependency isn't enough good solution. Hi Andrew; the main question is, what will happen, if a new distro breaks the toolchain? I remember vaguely, we have had struggled with this years ago... I predict, that we'll have to include prerequisites within two years :) But then, I'l be happy if it'll proof me wrong. I'm surprised about the changes for iproute (haven't had the time to look into the latest commits). I compiled iproute2 with uclibc-0.9.32 successfully without the chanes you committed. What caused the changes, if not uClibc? Just to understand, what may occur if we update other packages. kp btw: 4.1.1-beta1 has been build successfully in the background... -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. 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
Re: [leaf-devel] BuC-next branch
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#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. 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
Re: [leaf-devel] BuC-next branch
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#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. 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
