[Gluster-devel] Gluster 3.6.2 On Xeon Phi

[Kaleb KEITHLEY]

On 01/29/2015 09:12 AM, Kaushal M wrote:
> tl;dr: Add a 'LEXLIB=' flag to your configure command, ie. `./configure
> .... LEXLIB=`
>
> This is problem with flex-2.5.38 and above. From this version, flex
> generates a shared library in its default build (libfl.so). This shared
> object doesn't actually contain any exported symbols (AFAIK).
>
> Automake/autoconf automatically add a LEXLIB flag to the linker options
> whenever flex is used. Before 2.5.38, this used to be an empty flag as
> there was no actual library that needed to be linked. But, for 2.5.38
> and above automake sets the flag to '-lfl'. Now during linking, the
> linker searches this library for symbols (yyparse, yylex etc.), fails to
> find any, and fails the glusterfs build.

Excellent. Thanks Kaushal.

But, FYI, I don't experience this problem building on Debian Jessie, 
which has flex-2.5.39. Somehow this has been fixed?

libfl.so (or really libfl_pic.a) on Debian jessie does export two 
symbols: main and yywrap. Looks like the intent is to produce a 
stand-alone parser for something.

i.e.
# nm /usr/lib/x86_64-linux-gnu/libfl_pic.a

libmain.o:
0000000000000000 T main
                  U yylex

libyywrap.o:
0000000000000000 T yywrap



>
> I suppose this problem can be fixed by fixing our build configuration.
> But till then, we can force 'LEXLIB' to be empty by passing and empty
> flag to configure.
>
> I had this problem almost a year back IIRC, when Archlinux updated it's
> flex package to 2.5.38, and found the empty flag solution soon after. I
> added this to my build scripts and forgot about it. The Archlinux
> glusterfs package also uses the same method for its build. I didn't
> report it at the time because it only affected me.
>
> ~kaushal
>
> On Thu, Jan 29, 2015 at 6:53 PM, Kaleb KEITHLEY <kkeithle at redhat.com
> <mailto:kkeithle at redhat.com>> wrote:
>
>     On 01/29/2015 07:43 AM, Rudra Siva wrote:
>
>         Hi,
>
>         Have been able to get Gluster running on Intel's MIC platform. The
>         only code change to Gluster source was an unresolved yylex (I am not
>         really sure why that was coming up - may be someone more
>         familiar with
>         it's use in Gluster can answer).
>
>         At the step for compiling the binaries (glusterd, glusterfsd,
>         glusterfs, glfsheal)  build breaks with an unresolved yylex error.
>
>
>     Hi,
>
>     Maybe your version of bison doesn't support the -p option?
>
>     In libglusterfs the
>         bison -y -p graphyy  ./graph.y
>
>     should have produced a y.tab.c file with
>
>     ...
>     #define yylex           graphyylex
>     ...
>     int graphyylex ();
>     ...
>            yychar = yylex ();
>     ...
>
>     Which is what we get on Linux, MacOS, and *BSD.
>
>
>         For now have a routine yylex that simply calls graphyylex - I don't
>         know if this is even correct however mount functions.
>
>
>     That's a reasonable work-around/hack. At least your flex seems to
>     support the -P option correctly.
>
>
>         GCC - 4.7 (it's an oddity, latest GCC is missing the Phi patches)
>
>         flex --version
>         flex 2.5.39
>
>         bison --version
>         bison (GNU Bison) 3.0
>
>
>     Those seem reasonable. Fedora21 has flex 2.5.37 and boson-3.0.2
>
>
>         I'm still working on testing the RDMA and Infiniband support and can
>         make notes, numbers available when that is complete.
>
>
>     That would be great. Thanks.
>
>     --
>
>     Kaleb
>
>
>
>     _________________________________________________
>     Gluster-devel mailing list
>     Gluster-devel at gluster.org <mailto:Gluster-devel at gluster.org>
>     http://www.gluster.org/__mailman/listinfo/gluster-devel
>     <http://www.gluster.org/mailman/listinfo/gluster-devel>
>
>