[Gluster-devel] Gluster 3.6.2 On Xeon Phi

[Rudra Siva]

Adding LEXLIB= works.

bison supports -p however the output from the build is different than
when I do bison -y -p ...

>From bison -y -p .. y.tab.c looks as follows:

#define yylex           graph.yylex

>From standard configure bison output:

#define yylex           graphyylex

Looks like the standard configure output is correct and might be
better to check -lfl.so during the configure stage.

Thanks
-Siva


On Thu, Jan 29, 2015 at 10:09 AM, Kaleb KEITHLEY <kkeithle at redhat.com> wrote:
> 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>
>>
>>
>



-- 
-Siva