From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2] package/sconeserver: needs shared libs or non uClibc toolchain
Date: Mon, 29 Aug 2016 00:15:24 +0200 [thread overview]
Message-ID: <20160828221524.GF5758@free.fr> (raw)
In-Reply-To: <87wpj07dga.fsf@dell.be.48ers.dk>
Peter, All,
On 2016-08-29 00:09 +0200, Peter Korsgaard spake thusly:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
>
> > sconeserver wants to use dlopen(), unconditionally: it does not try to
> > detect it, and it can't work without it (the code is not conditional).
>
> > So, when the toolchain uses uClibc, and that uClibc has been configured
> > with only static support, the dlopen() functions are not available at
> > all, and the corresponding headers are not present:
>
> > ModuleLoader.cpp:29:19: fatal error: dlfcn.h: No such file or directory
> > #include <dlfcn.h>
> > ^
>
> > However, we can't know if uClibc has shared support or is static-only,
> > especially for external toolchains.
>
> > The only way is to forbid the combination {uClibc,static}. So we may
> > indeed forbid working combinations, for example if the external
> > toolchain is uClibc-based and has support for shared libs...
>
> Ehh, this I don't get. Why not simply depend on !BR2_STATIC_LIBS like we
> do for other users of dlfcn.h?
>
> If BR2_STATIC_LIBS is enabled then there won't be any .so files in the
> target rootfs, so even if the C library has dlopen support it won't
> work.
Not necessarily true.
One can use dlopen() to load "addons" even from a staticaly linked
executable.
However, I don't care about sconeserver; I was just looking at build
failures and trying to make it the least broken as possible.
If you're fine with making it depend on non static-only and drop the
uclibc condition, that's fine with me. ;-)
Regards,
Yann E. MORIN.
> If an external (uClibc-based) toolchain has no shared library support
> then it can only be used in BR2_STATIC_LIBS configurations.
>
> --
> Bye, Peter Korsgaard
--
.-----------------.--------------------.------------------.--------------------.
| 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:[~2016-08-28 22:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-28 18:19 [Buildroot] [PATCH 1/2] package/sconeserver: needs host-pkgconf Yann E. MORIN
2016-08-28 18:19 ` [Buildroot] [PATCH 2/2] package/sconeserver: needs shared libs or non uClibc toolchain Yann E. MORIN
2016-08-28 22:09 ` Peter Korsgaard
2016-08-28 22:15 ` Yann E. MORIN [this message]
2016-08-29 7:03 ` Peter Korsgaard
2016-08-28 22:20 ` Matthew Weber
2016-08-28 22:05 ` [Buildroot] [PATCH 1/2] package/sconeserver: needs host-pkgconf Peter Korsgaard
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=20160828221524.GF5758@free.fr \
--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