Re: [Ipsec-tools-devel] Link failure with libfl shared library
Brought to you by:
mit_warlord,
netbsd
From: Paul B. <pa...@pa...> - 2014-04-08 16:20:02
|
On 8 April 2014 16:33, Rainer Weikusat <rwe...@mo...> wrote: > Paul Barker <pa...@pa...> writes: >> I'm getting link failures against libfl.so (the flex library) which >> weren't present when only libfl.a had been built. libfl only provides >> two functions, a main function which just calls yylex and a dummy >> yywrap function which always returns 1. That causes a link problem as >> ld is looking for the symbol 'yylex' after it has read libfl.so and >> can't find it. > > IMHO, you shouldn't link with an actual 'libflex.so' except if you're > compiling 'the binaries' with -fpic so that the linker finds the yylex > routine in cftoken.o. > I agree, that's why I sent the patch. The $(LEXLIB) variable in the current build system expands to '-lfl' during builds using the OpenEmbedded build system on my machine. This gets resolved to point to 'libflex.so' by the linker. Thus, at least in my setup, ipsec-tools is linking against libflex.so by default without this patch. It looks like flex-2.5.37 and earlier just install 'libflex.a', 2.5.38 installs both 'libflex.a' and 'libflex.so'. There is no error when 'libflex.so' isn't present during compilation. The patch therefore removes these references to $(LEXLIB), but that then causes errors regarding 'yywrap()' not being found. So I've added '%option noyywrap' to the lex source files which don't appear to need to use yywrap. That looks like the right approach to me but I could be wrong. If I need to try a different approach let me know. Thanks, -- Paul Barker Email: pa...@pa... http://www.paulbarker.me.uk |