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@xxxxxxxxxx
<mailto:kkeithle@xxxxxxxxxx>> 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@xxxxxxxxxxx <mailto:Gluster-devel@xxxxxxxxxxx>
http://www.gluster.org/__mailman/listinfo/gluster-devel
<http://www.gluster.org/mailman/listinfo/gluster-devel>
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
