From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] Allow building a toolchain without (non-trivial) dependencies
Date: Wed, 28 Mar 2018 21:25:36 +0200 [thread overview]
Message-ID: <20180328192536.GB3533@scaer> (raw)
In-Reply-To: <CADYdroNk0nCYZTZt6aVact8URP_fDu5x9pPkKRMHoYEw_KtmdA@mail.gmail.com>
Norbert, All,
On 2018-03-28 20:57 +0200, Norbert Lange spake thusly:
> I would like to have an option to make a reasonable "portable" toolchain,
> means no dependencies apart from the C libs (libc libm libdl).
>
> As you see below, I cant run the toolchain without keeping the libs
> around and setting the LD path,
> limiting its use outside the (locally built) rootfs.
>
> ie. all support libs from gcc should be optionally linked statically
>
> $ ldd cc1plus
> linux-vdso.so.1 (0x00007ffdacd5e000)
> libisl.so.15 => /usr/lib/x86_64-linux-gnu/libisl.so.15 (0x00007f591aad0000)
> libmpc.so.3 => /usr/lib/x86_64-linux-gnu/libmpc.so.3 (0x00007f591a8b7000)
> libmpfr.so.4 => not found
> libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f591a633000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f591a42f000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f591a09c000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5919ce2000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f591ae78000)
> libmpfr.so.6 => /usr/lib/x86_64-linux-gnu/libmpfr.so.6 (0x00007f5919a60000)
Not so long ago, we introduced the notion of 'SDK', whereby you build
your toolchain, and as many libraries you want (which can be none for
a pure toolchain), and distribute that as an SDK, as explained in the
manual:
https://buildroot.org/downloads/manual/manual.html#_using_the_generated_toolchain_outside_buildroot
This is basically a three-step procedure:
- first, you generate the SDK,
- then you distribute the content of the host/ directory (supposedly
as a tarball or other such archive),
- the user extracts it and run a script that fixes the SDK for local
use (presumable in another directory).
That is more flexible than just doing a static link of the toolchain,
and covers the case of distributing the toolchain too, so there we go...
;-)
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. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2018-03-28 19:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-28 18:57 [Buildroot] Allow building a toolchain without (non-trivial) dependencies Norbert Lange
2018-03-28 19:25 ` Yann E. MORIN [this message]
2018-03-28 20:37 ` Norbert Lange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180328192536.GB3533@scaer \
--to=yann.morin.1998@free.fr \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox