[PATCH 0/1] flex: not to build shared libraries

[PATCH 0/1] flex: not to build shared libraries

[Chong Lu]

The following changes since commit f03955041d0e44d377ca1c4def630982f24f1e8b:

  Revert "ncurses: use ln -r to generate relative symlink" (2014-03-03 15:55:27 +0000)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib chonglu/flex
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=chonglu/flex

Chong Lu (1):
  flex: not to build shared libraries

 .../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

-- 
1.8.1.2

[PATCH 1/1] flex: not to build shared libraries

[Chong Lu]

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

diff --git a/meta/recipes-devtools/flex/files/flex-not-to-build-shared-libraries.patch b/meta/recipes-devtools/flex/files/flex-not-to-build-shared-libraries.patch
new file mode 100644
index 0000000..a50569f
--- /dev/null
+++ b/meta/recipes-devtools/flex/files/flex-not-to-build-shared-libraries.patch
@@ -0,0 +1,39 @@
+flex: not to build shared libraries
+
+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.
+
+Upstream-Status: Pending
+
+Signed-off-by: Chong Lu <Chong.Lu@windriver.com>
+---
+ Makefile.am |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Makefile.am b/Makefile.am
+index 1f90356..f3638aa 100644
+--- a/Makefile.am
++++ b/Makefile.am
+@@ -73,13 +73,13 @@ libfl_la_SOURCES = \
+ 	libmain.c \
+ 	libyywrap.c
+ 
+-libfl_la_LDFLAGS = -no-undefined -version-info @SHARED_VERSION_INFO@
++libfl_la_LDFLAGS = -all-static -no-undefined -version-info @SHARED_VERSION_INFO@
+ 
+ libfl_pic_la_SOURCES = \
+ 	libmain.c \
+ 	libyywrap.c
+ 
+-libfl_pic_la_LDFLAGS = -no-undefined -version-info @SHARED_VERSION_INFO@
++libfl_pic_la_LDFLAGS = -all-static -no-undefined -version-info @SHARED_VERSION_INFO@
+ 
+ noinst_HEADERS = \
+ 	flexdef.h \
+-- 
+1.7.9.5
+
diff --git a/meta/recipes-devtools/flex/flex.inc b/meta/recipes-devtools/flex/flex.inc
index 75c10ef..616f4d7 100644
--- a/meta/recipes-devtools/flex/flex.inc
+++ b/meta/recipes-devtools/flex/flex.inc
@@ -7,6 +7,7 @@ SECTION = "devel"
 LICENSE = "BSD"
 
 SRC_URI = "${SOURCEFORGE_MIRROR}/flex/flex-${PV}.tar.bz2 \
+           file://flex-not-to-build-shared-libraries.patch \
            file://run-ptest \
 "
 
-- 
1.8.1.2

Re: [PATCH 1/1] flex: not to build shared libraries

[Richard Purdie]

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

Re: [PATCH 1/1] flex: not to build shared libraries

[Lu Chong]

[-- 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 --]

Re: [PATCH 1/1] flex: not to build shared libraries

[Burton, Ross]

On 5 March 2014 09:58, Lu Chong <Chong.Lu@windriver.com> wrote:
> 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.

Same result apart from that there is no longer a shared libfl.so
anymore, so it's not the same.

Mageia's solution is cleaner as it only impacts ipsec-tools, but I'd
have thought it could be solved without having to revert using libtool
(as the error suggests its an as-needed ordering problem).

Ross

Re: [PATCH 1/1] flex: not to build shared libraries

[Paul Barker]

On 5 March 2014 09:58, Lu Chong <Chong.Lu@windriver.com> wrote:
>
> 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'.

I've used flex before, this is correct, libfl is not supposed to
define yylex. See for example
https://www.mail-archive.com/tools-linking@mail.opensolaris.org/msg00601.html

The problem is in how ipsec-tools is being linked, not in flex. I'd
suggest patching that recipe instead.

Cheers,

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: [PATCH 1/1] flex: not to build shared libraries

[Paul Barker]

On 5 March 2014 12:49, Paul Barker <paul@paulbarker.me.uk> wrote:
> On 5 March 2014 09:58, Lu Chong <Chong.Lu@windriver.com> wrote:
>>
>> 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'.
>
> I've used flex before, this is correct, libfl is not supposed to
> define yylex. See for example
> https://www.mail-archive.com/tools-linking@mail.opensolaris.org/msg00601.html
>
> The problem is in how ipsec-tools is being linked, not in flex. I'd
> suggest patching that recipe instead.
>
> Cheers,
>

I've patched ipsec-tools to fix this, will send the patch to the oe-devel list.

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: [PATCH 1/1] flex: not to build shared libraries

[Paul Barker]

On 5 March 2014 13:45, Paul Barker <paul@paulbarker.me.uk> wrote:
> On 5 March 2014 12:49, Paul Barker <paul@paulbarker.me.uk> wrote:
>> On 5 March 2014 09:58, Lu Chong <Chong.Lu@windriver.com> wrote:
>>>
>>> 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'.
>>
>> I've used flex before, this is correct, libfl is not supposed to
>> define yylex. See for example
>> https://www.mail-archive.com/tools-linking@mail.opensolaris.org/msg00601.html
>>
>> The problem is in how ipsec-tools is being linked, not in flex. I'd
>> suggest patching that recipe instead.
>>
>> Cheers,
>>
>
> I've patched ipsec-tools to fix this, will send the patch to the oe-devel list.
>

Sent.

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: [PATCH 1/1] flex: not to build shared libraries

[Burton, Ross]

On 5 March 2014 09:18, Chong Lu <Chong.Lu@windriver.com> 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'

Isn't that generally because the makefile is doing it wrong, for
example linking the lexer in C++ mode instead of C?

Remove a shared library and forcing everyone to static link doesn't
seem like a long-term solution to me.

Ross