This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Bruno, All, On Tuesday 23 March 2010 11:44:50 Bruno Tarquini wrote: > > That's absolutely not the purpose of those tarballs. What you really want > > to package is the resulting toolchain. The bckup tarballs are only for > > debug purposes. > It wasn't to make a package to distribute but to make faked packages for > the target system: > basically, sys-kernel/linux-headers and sys-libs/glibc (gentoo > embedded). The entire toolchain shouldn't be installed on the target > (and will not run). And, yeah, I should have rebuilt > libc but importing faked package from the toolchain was easier and less > time consuming. I still don't understand. What do you want those packages for? Do you mean you want to copy something on the target? If you mean that your root file system is missing the libraries from the toolchain, then look at the populate script (that is installed with your toolchain): # arm-unknown-linux-uclibc-populate -h NAME arm-unknown-linux-uclibc-populate - populate the target root file system SYNOPSIS arm-unknown-linux-uclibc-populate OPTIONS -s source_root -d destination_root DESCRIPTION arm-unknown-linux-uclibc-populate will 'populate' your target root file system ('src_dir') with libraries from the toolchain (eg. libc.so...), storing the result into 'dst_dir'. OPTIONS -s src_dir use 'src_dir' as the un-populated (source) root directory -d dst_dir use 'dst_dir' as the place to put the populated root directory -l name1[:name2[...]] Always add the specified shared library/ies name1, name2... from the toolchain (in the sys-root). Actual library names are searched as follows (where 'name' is replaced with the given name) in the sys-root directory: - libname.so - name.so - name If the file is found, then the SONAME of the library is used, and the library is copied with that name. If the library was not found, this yields an error (unless -f was given). -L file Read 'file' for a list of shared libraries to always add from the toolchain. The file should contain one library name per line; text after a # is ignored until the end of the line; spaces are ignored; empty lines are ignored. Libraries are searched for as with -l. -f force execution: if destination directory already exists, it will be removed first; if a specified library (above) was not found, continue. -v Be verbose. By default, populate is absolutely silent. Basically, you use it like that: 1) Build all your packages (adapt as needed!): # cd my-package # ./configure --prefix=/usr \ --build="build-tuple" \ --host="host-tuple" \ CFLAGS="-I/some/where/staging/usr/include \ LDFLAGS="-L/some/where/staging/usr/lib # make # make DESTDIR=/some/where/staging install And so on for all your packages... 2) And finally: # host-tuple-populate -s /some/where/staging \ -d /some/where/staging-full At this point, staging-full/ contains all that your package(s) did install *and* the required libraries from the toolchain (eg. libc.so, ld-linux.so...) without touching the staging/ area, thus leaving in staging/ *only* the files that your packages did install. > > Wanna come with a patch to this effect, please? > For correcting what ? changing -3 to -6 in the documentation ? or using > -3 everywhere ? > which is what my previous patch did (with the add of the --no-name > option to which is pretty harmful, IMHO). Forget it, I'll do the gzip -3. :-) Just for fun, I re-did the measurements that I used to do a long time ago, to back my claims that gzip -3 is just enough. I leave up to the reader the leasure to interpret the folowing numbers! :-) File: linux-2.6.33.tar Size of file: 395100160 (377MiB) Measured with: time gzip -1 -c linux-2.6.33.tar |wc -c (replace 'gzip -1' with any appropriate combo below!). compression size ratio time gain gain/time (1-ratio)/time gzip -1 105849688 0.268 6.527 289250472 16217204 0.112164 gzip -3 97533167 0.247 8.213 297566993 11875462 0.091701 gzip -6 85317011 0.216 16.093 309783149 5301498 0.048721 gzip -9 84532819 0.214 31.270 310567341 2703320 0.025137 bzip2 -1 79515133 0.201 44.798 315585027 1774971 0.017830 bzip2 -3 71257550 0.180 44.733 323842610 1592953 0.018323 bzip2 -6 67779650 0.172 46.977 327320510 1442826 0.017635 bzip2 -9 66266488 0.168 49.214 328833672 1346497 0.016911 The 'time' columns is the 'real' part returned by the time command, in seconds. The file was entirely cached in memory prior to the tests, and the machine entirely idle, except for the compression. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |