Re: Cross compiler ITP (armel)
Philipp Kern writes: > On 2011-03-23, Goswin von Brederlow wrote: >> Also does the testing transition consider the Built-Using? If I specify >> 'Built-Using: gcc-4.5 (= 4.5.2-5)' will the package be blocked from >> entering testing until gcc-4.5 (= 4.5.2-5) has entered and block gcc-4.5 >> (= 4.5.2-5) from being replaced from testing? > > It doesn't need to. All we want is compliance on the archive side so that the > sources are not expired away, as long as that binary is carried in a suite. > No need to involve britney at that point. > > Kind regards > Philipp Kern Not quite. For ia32-libs it would be nice if ia32-libs could be blocked from testing as long as the source packages it includes aren't in testing. Currently that is solved by building against testing in the first palce. But that is something we can live with. As a side note the debian-cd package needs to also consider Built-Using when creating source images. Will the Sources.gz file list multiple entries for a source if multiple versions are relevant? MfG Goswin ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Cross compiler ITP (armel)
Mark Hymers writes: > On Tue, 22, Mar, 2011 at 01:57:42PM +, Hector Oron spoke thus.. >> Hi Mark, >> >> 2011/3/22 Mark Hymers : >> >> > The current design is the Binary packages can contain an additional >> > control field: Built-Using. >> >> First of all, thanks very much for taking care of it, that probably >> will get us going. >> >> I just would like to point out that current design solves half of >> the problem (being GPL compliant), but it does not solve code >> duplication in the archive, which it can also be useful for large >> datasets. IMHO, we do not want source and binary packages containing >> the same bits, bytes and nibbles, problem which might be solved by the >> multiarch specification, treating 'source' as yet another architecture >> (in next couple years?) :-) > > I'd have thought the right answer to that was to allow some form of > Build-Depends-Source mechanism where the source is unpacked at build > time in a known place or something. Of course, the problem with this is > that we traditionally haven't allowed network access to be required > during a build so the exact semantics would have to be worked out. > Maybe something like, if a package declares > Build-Depends-Source: gcc-4.5 > the source code must be available under debian/external-source/gcc-4.5 > and then leave it up to the builder to sort that out. That's a rough > (and probably bad) idea off the top of my head - I'm sure the buildd > team at least will have other thoughts on the matter. > > Mark Using the multiarch syntax this could be folded into Build-Depends: Build-Depends: gcc-4.5:src That would then cause the gcc-4.5 source to be unpacked to /usr/src/gcc-4.5/ (I would guess) as part of the installation of Build-Depends done by sbuild or pbuilder or whatever tool you use. There would be no special network access required during the build other than what is already in use for installing Build-Depends in general prior to a build. What this really comes down to is patching dpkg / apt / aptitude so they can "install" sources and sbuild / wanna-build / quinn-diff to cope with the syntax. MfG Goswin ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Cross compiler ITP (armel)
Mark Hymers writes: > On Mon, 14, Mar, 2011 at 02:04:30PM +, Hector Oron spoke thus.. >> Hi, >> >> 2009/11/2 Mark Hymers : >> > On Mon, 02, Nov, 2009 at 12:43:42PM +, Philipp Kern spoke thus.. >> >> Of course it is a sane approach but very special care needs to be taken >> >> when >> >> releasing to ensure GPL compliance. Â So what we should get is support in >> >> the >> >> toolchain to declare against what source package the upload was built to >> >> keep that around. > > Ok, I'm only going to comment on this part. This is nearly implemented > and should be there by the end of the day (I need to run up some test > packages to work with). > > The current design is the Binary packages can contain an additional > control field: Built-Using. > > The specification of this field is that it *must* contain only strict > version dependencies and these must be to source packages. I.e. > > Built-Using: gcc-4.5 (= 4.5.2-5) So ia32-libs could contain Built-using: acl (= 2.2.49-4), ... 112 more entries and drop the source copies (75% of the source package)? It isn't exactly "using" the packages to build but it contains copies of the prebuild debs of those versions. The GPL requirement for the source to exist is the same though. > If dak can't parse this field, or the source versions which are declared > are not present when the binary package is uploaded, it will reject the > upload. If it can parse and find these dependencies, it stores them in > an extra table in projectb which prevents us from throwing away the > relevant source files until these binaries no longer exist anywhere in > the archive, the same way as we handle it for the normal source case. What exactly means "not present"? The ia32-libs packages are curently build against testing. Would an upload to unstable be allowed with a Built-Using string listing versions only in testing? Also does the testing transition consider the Built-Using? If I specify 'Built-Using: gcc-4.5 (= 4.5.2-5)' will the package be blocked from entering testing until gcc-4.5 (= 4.5.2-5) has entered and block gcc-4.5 (= 4.5.2-5) from being replaced from testing? > I'm not entirely sure where this should be documented, it's not really a > policy thing as it's specific to the archive. Suggestions welcome. > We'll obviously include it in the minutes to d-d-a at the end of the > meeting (the main people this should be used by, as far as I know are > cross-compiler builders and the d-i and kernel-wedge people). > > Mark MfG Goswin ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Cross compiler ITP (armel)
On Wed, Mar 23, 2011 at 11:59:11AM +0100, Goswin von Brederlow wrote: > >As a side note the debian-cd package needs to also consider Built-Using >when creating source images. Yup, we'll need to consider that. I'm looking forwards to having all the stuff we need properly dealt with, however it's done. Cheers, -- Steve McIntyre, Cambridge, UK st...@einval.com ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
can linaro toolchain compile ARM earlier than Cortex A8?
Hi All, After downloading linaro toolchain by apt-get in ubuntu, I compiled the uboot for ARM1136 SoC with -march=armv5 option. And it can compile successfully. Then I let the uboot run on target boards and system failed due to "undefined instructions". Checked linaro toolchain options, it is: #arm-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=arm-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.2/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-5ubuntu2~ppa1' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.5.2 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabi --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib Thread model: posix gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-5ubuntu2~ppa1) The imporant options are "--with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16". I just want to ask whether these options stop arm-linux-gnueabi-gcc to support old arch? If so, according to gcc documents at http://gcc.gnu.org/install/configure.html, " --with-cpu=cpu --with-cpu-32=cpu --with-cpu-64=cpu Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC. --with-schedule=cpu --with-arch=cpu --with-arch-32=cpu --with-arch-64=cpu --with-tune=cpu --with-tune-32=cpu --with-tune-64=cpu --with-abi=abi --with-fpu=type --with-float=type These configure options provide default values for the -mschedule=, -march=, -mtune=, -mabi=, and -mfpu= options and for -mhard-float or -msoft-float. As with --with-cpu, which switches will be accepted and acceptable values of the arguments depend on the target. " There are only default values for later compiling. Users should be able to swith to other values by setting other options. But why did arm-linux-gnueabi-gcc still build "undefined instructions" to arm1136 with "arch=armv5"? In fact arm1136 is armv6. Then i compiled a toolchain for linaro gcc-linaro-4.4-2011.02-0 codes by myself, the options are simple: #arm-none-linux-gnueabi-gcc -v Using built-in specs. Target: arm-none-linux-gnueabi Configured with: ../gcc-linaro-4.4-2011.02-0/configure --target=arm-none-linux-gnueabi --prefix=/home/vmuser/development/toolchain/build-toolchain/tools --enable-languages=c,c++ --disable-libgomp Thread model: posix gcc version 4.4.5 (Linaro GCC 4.4-2011.02-0) Then I compiled uboot by this toolchain again, the uboot can work. Then why can the toolchain compiled by myself support more arch? And what performance is lost in my compiling? Thanks Barry ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: can linaro toolchain compile ARM earlier than Cortex A8?
Hi Barry. GCC can be switched at runtime by supplying -march=* and/or -mcpu=* flags to the compiler, just as you have done below. The '--with-arch=*' lines you see below set what GCC compiles to by default. Does your chip have a FPU? If not, it's probably the --with-fpu=vfpv3-d16 line that's causing you trouble. Give: gcc -march=armv5te -mfloat-abi=soft -marm a try and see if that fixes the problem. -- Michael On Thu, Mar 24, 2011 at 2:57 PM, Barry Song <21cn...@gmail.com> wrote: > Hi All, > After downloading linaro toolchain by apt-get in ubuntu, I compiled > the uboot for ARM1136 SoC with -march=armv5 option. And it can compile > successfully. Then I let the uboot run on target boards and system > failed due to "undefined instructions". Checked linaro toolchain > options, it is: > > #arm-linux-gnueabi-gcc -v > Using built-in specs. > COLLECT_GCC=arm-linux-gnueabi-gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.2/lto-wrapper > Target: arm-linux-gnueabi > Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro > 4.5.2-5ubuntu2~ppa1' > --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs > --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > --program-suffix=-4.5 --enable-shared --enable-multiarch > --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib > --without-included-gettext --enable-threads=posix > --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.5.2 > --libdir=/usr/lib --enable-nls --enable-clocale=gnu > --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin > --enable-gold --enable-ld=default --with-plugin-ld=ld.gold > --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a > --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb > --disable-werror --enable-checking=release > --program-prefix=arm-linux-gnueabi- > --includedir=/usr/arm-linux-gnueabi/include --build=x86_64-linux-gnu > --host=x86_64-linux-gnu --target=arm-linux-gnueabi > --with-headers=/usr/arm-linux-gnueabi/include > --with-libs=/usr/arm-linux-gnueabi/lib > Thread model: posix > gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-5ubuntu2~ppa1) > > The imporant options are "--with-arch=armv7-a --with-float=softfp > --with-fpu=vfpv3-d16". I just want to ask whether these options stop > arm-linux-gnueabi-gcc to support old arch? If so, according to gcc > documents at http://gcc.gnu.org/install/configure.html, > > " > > --with-cpu=cpu > --with-cpu-32=cpu > --with-cpu-64=cpu > Specify which cpu variant the compiler should generate code for by > default. cpu will be used as the default value of the -mcpu= switch. > This option is only supported on some targets, including ARM, i386, > M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options > specify separate default CPUs for 32-bit and 64-bit modes; these > options are only supported for i386, x86-64 and PowerPC. > --with-schedule=cpu > --with-arch=cpu > --with-arch-32=cpu > --with-arch-64=cpu > --with-tune=cpu > --with-tune-32=cpu > --with-tune-64=cpu > --with-abi=abi > --with-fpu=type > --with-float=type > These configure options provide default values for the > -mschedule=, -march=, -mtune=, -mabi=, and -mfpu= options and for > -mhard-float or -msoft-float. As with --with-cpu, which switches will > be accepted and acceptable values of the arguments depend on the > target. > " > > There are only default values for later compiling. Users should be > able to swith to other values by setting other options. But why did > arm-linux-gnueabi-gcc still build "undefined instructions" to arm1136 > with "arch=armv5"? In fact arm1136 is armv6. > > Then i compiled a toolchain for linaro gcc-linaro-4.4-2011.02-0 codes > by myself, the options are simple: > > #arm-none-linux-gnueabi-gcc -v > Using built-in specs. > Target: arm-none-linux-gnueabi > Configured with: ../gcc-linaro-4.4-2011.02-0/configure > --target=arm-none-linux-gnueabi > --prefix=/home/vmuser/development/toolchain/build-toolchain/tools > --enable-languages=c,c++ --disable-libgomp > Thread model: posix > gcc version 4.4.5 (Linaro GCC 4.4-2011.02-0) > > Then I compiled uboot by this toolchain again, the uboot can work. > Then why can the toolchain compiled by myself support more arch? And > what performance is lost in my compiling? > > Thanks > Barry > > ___ > linaro-toolchain mailing list > linaro-toolchain@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-toolchain > ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
