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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.