From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] uclibc: add simlinks from libdl/libm/libpthread/librt
Date: Sun, 21 Jun 2020 10:51:31 +0200 [thread overview]
Message-ID: <20200621085131.GA2351@scaer> (raw)
In-Reply-To: <N9GXBQ.QY2GW6T2I42F3@crapouillou.net>
Paul, All,
On 2020-06-14 19:51 +0200, Paul Cercueil spake thusly:
> Le dim. 14 juin 2020 ? 17:00, Yann E. MORIN <yann.morin.1998@free.fr> a
> ?crit :
> >On 2020-06-13 18:20 +0200, Paul Cercueil spake thusly:
> >> All the symbols that were previously present in libdl.so.0, libm.so.0,
> >> libpthread.so.0 and librt.so.0 are now all packed within uClibc.
> >>
> >> In order to keep binary compatibility with old executables, which were
> >> dynamically linked with one of the libraries above, add symbolic links
> >> to the uClibc shared library.
> >This does not account for external toolchains.
[--SNIP--]
> >I wonder how good those symlinks are anyway: uClibc has no ABI/API
> >stability anyway, so there are no guarantee that a program linked
> >against a version of uClibc will work against another version, or even
> >the same version that was compiled with another configuration...
We've discussed this with the other maintainers, and we agree that "we do
not really care about binary-level compatibility, especially with uClibc
where it is anyway not guaranteed" (quoting the conclusion from Thomas)
The best bet for you is to remove those symlinks from your overlay, and
create them from a post-build script (where you can do the globbing you
need to find the current version string).
Or to create them as symlinks to libc.so.0 which we already create as a
sylink to the actual libuclibc-XXXX.so (but this is less flexible than a
post-build script).
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
prev parent reply other threads:[~2020-06-21 8:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-13 16:20 [Buildroot] [PATCH] uclibc: add simlinks from libdl/libm/libpthread/librt Paul Cercueil
2020-06-14 15:00 ` Yann E. MORIN
2020-06-14 17:51 ` Paul Cercueil
2020-06-21 8:51 ` Yann E. MORIN [this message]
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=20200621085131.GA2351@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