From: Lu Chong <Chong.Lu@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] flex: not to build shared libraries
Date: Wed, 5 Mar 2014 17:58:44 +0800 [thread overview]
Message-ID: <5316F554.1030201@windriver.com> (raw)
In-Reply-To: <1394011283.31845.97.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]
On 03/05/2014 05:21 PM, Richard Purdie wrote:
> On Wed, 2014-03-05 at 17:18 +0800, Chong Lu wrote:
>> Some packages do not link successfully using shared libraries.
>> When link something to libfl.so, we will get this:
>>
>> libfl.so: undefined reference to `yylex'
>>
>> So we only build static libraries to fix this issue.
>>
>> Signed-off-by: Chong Lu <Chong.Lu@windriver.com>
>> ---
>> .../files/flex-not-to-build-shared-libraries.patch | 39 ++++++++++++++++++++++
>> meta/recipes-devtools/flex/flex.inc | 1 +
>> 2 files changed, 40 insertions(+)
>> create mode 100644 meta/recipes-devtools/flex/files/flex-not-to-build-shared-libraries.patch
> Why aren't the shared libraries working? Which packages show this
> problem? Is this not a problem in the recipes using the shared
> libraries?
>
> At the very least this patch needs more explanation but I don't like the
> idea.
>
> Cheers,
>
> Richard
>
>
>
In flex 2.5.38, libfl.so was built by libtool.
ipsec-tools shows this problem.
When link libipsec.so to libfl.so, it uses '-lfl' flag. It will link
from libfl.so.
But libfl.so doesn't define yylex, we may get "libfl.so not found"
through `ldd libipsec.so'.
If we only build static libraries, libipsec.so will not link to
libfl.so. it will link to libfl.a.
Then libipsec.so uses yylex function by itself rather than libfl.so
provided.
In Mageia distribution, revert building libraries with libtool.
http://www.rpmfind.net//linux/RPM/mageia/cauldron/x86_64/media/core/release/flex-2.5.38-1.mga5.x86_64.html
And in flex 2.5.37 version, it will only generate static libraries.
So in order to ignore blocking some packages(likes ipsec-tools), I have
two ways to fix this issue.
1. revert building libraries with libtool.
2. modify libtool to make it only build static libraries.
I choose the second way. The same result to first.
Best Regards
Chong
[-- Attachment #2: Type: text/html, Size: 2969 bytes --]
next prev parent reply other threads:[~2014-03-05 9:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-05 9:18 [PATCH 0/1] flex: not to build shared libraries Chong Lu
2014-03-05 9:18 ` [PATCH 1/1] " Chong Lu
2014-03-05 9:21 ` Richard Purdie
2014-03-05 9:58 ` Lu Chong [this message]
2014-03-05 11:37 ` Burton, Ross
2014-03-05 12:49 ` Paul Barker
2014-03-05 13:45 ` Paul Barker
2014-03-07 1:15 ` Paul Barker
2014-03-05 9:43 ` Burton, Ross
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=5316F554.1030201@windriver.com \
--to=chong.lu@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/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