Date: Sat, 3 Jul 2010 04:04:47 +0000 From: Matthew Fleming <mdf356@gmail.com> To: d@delphij.net Cc: Garrett Cooper <yanefbsd@gmail.com>, freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library Message-ID: <AANLkTilyr3FTpZrttd812M7J_czEQ5xy21MbUPDa6Xla@mail.gmail.com> In-Reply-To: <4C2E7C29.2080307@delphij.net> References: <AANLkTilp0zvMRbw96cifhIzmT4YbNVkxgOFZFa_nvl2m@mail.gmail.com> <AANLkTimGsM7Ibaryx6e3gLSy5xpkpYxQmE3w5gAwlXXD@mail.gmail.com> <AANLkTikWqJgfETncKV3pEZ8JgxzcAsALFGtSk_dYNxbl@mail.gmail.com> <4C2E7BCD.4020609@delphij.net> <4C2E7C29.2080307@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 2, 2010 at 11:54 PM, Xin LI <delphij@delphij.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2010/07/02 16:52, Xin LI wrote: >> On 2010/07/02 16:34, Matthew Fleming wrote: >>> On Fri, Jul 2, 2010 at 4:02 PM, Garrett Cooper <yanefbsd@gmail.com> wro= te: >>>> On Fri, Jul 2, 2010 at 2:51 PM, Matthew Fleming <mdf356@gmail.com> wro= te: >>>>> I have the following Makefile for a shared library at $work: >>>>> >>>>> ISI_TOP=3D =A0 =A0 =A0 =A0../.. >>>>> >>>>> LIB=3D =A0 =A0 =A0 =A0 =A0 =A0isi_date >>>>> SHLIB_MAJOR=3D =A0 =A01 >>>>> SHLIB_MINOR=3D =A0 =A00 >>>>> SRCS=3D =A0 =A0 =A0 =A0 =A0 date.c date_parser.new.c lex.yy.c >>>>> INCS=3D =A0 =A0 =A0 =A0 =A0 date.h >>>>> INCLUDEDIR=3D =A0 =A0 /usr/include/isi_date >>>>> >>>>> YFLAGS+=3D =A0 =A0 =A0 =A0-vt >>>>> FLEX=3D =A0 =A0 =A0 =A0 =A0 /usr/bin/flex >>>>> LDADD=3D =A0 =A0 =A0 =A0 =A0-ll >>>>> >>>>> CLEANFILES+=3D =A0 =A0date_parser.new.c y.tab.h y.tab.c lex.yy.c y.ou= tput \ >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0check_date.log test >>>>> >>>>> lex.yy.c: date_lexer.new.l >>>>> =A0 =A0 =A0 =A0${FLEX} $> >>>>> >>>>> CFLAGS+=3D =A0 =A0 =A0 =A0-I${.CURDIR} >>>>> #CFLAGS+=3D =A0 =A0 =A0 -g >>>>> >>>>> .include "${ISI_TOP}/isi.lib.mk" >>>>> >>>>> >>>>> >>>>> This builds fine as on i386. =A0I'm trying to get all our user-space = to >>>>> be 64-bit clean, and I run into an error when building on amd64: >>>>> >>>>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/bin/ld= : >>>>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/li= bl.a(libyywrap.o): >>>>> relocation R_X86_64_32 can not be used when making a shared object; >>>>> recompile with -fPIC >>>>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/li= bl.a: >>>>> could not read symbols: Bad value >>>>> >>>>> The following diff makes the compile work, but I have no idea (yet) >>>>> whether this will run, if it's the right solution, etc. >>>>> >>>>> >>>>> Index: usr.bin/lex/lib/Makefile >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> --- usr.bin/lex/lib/Makefile =A0 =A0(revision 153343) >>>>> +++ usr.bin/lex/lib/Makefile =A0 =A0(working copy) >>>>> @@ -4,11 +4,16 @@ >>>>> >>>>> =A0LIB=3D =A0 =A0ln >>>>> =A0SRCS=3D =A0 libmain.c libyywrap.c >>>>> -NO_PIC=3D >>>>> +#NO_PIC=3D >>>>> >>>>> +SHLIB_MAJOR=3D =A0 1 >>>>> +SHLIB_MINOR=3D =A0 0 >>>>> + >>>>> =A0.if ${MK_INSTALLLIB} !=3D "no" >>>>> =A0LINKS=3D =A0${LIBDIR}/libln.a ${LIBDIR}/libl.a >>>>> =A0LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.a ${LIBDIR}/libfl.a >>>>> +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.so ${LIBDIR}/libl.so >>>>> +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln${LIB_SUFFIX}.so ${LIBDIR}/l= ibl${LIB_SUFFIX}.so >>>>> =A0.endif >>>>> >>>>> =A0.if ${MK_PROFILE} !=3D "no" >>>> >>>> The static-only version was done on purpose: >>>> >>>> Revision 1.2: download - view: text, markup, annotated =A0- select for= diffs >>>> Thu Aug 25 23:11:07 1994 UTC (15 years, 10 months ago) by wollman >>>> Branches: MAIN >>>> CVS tags: RELENG_2_1_7_RELEASE, RELENG_2_1_6_RELEASE, >>>> RELENG_2_1_6_1_RELEASE, RELENG_2_1_5_RELEASE, RELENG_2_1_0_RELEASE, >>>> RELENG_2_1_0_BP, RELENG_2_0_5_RELEASE, RELENG_2_0_5_BP, >>>> RELENG_2_0_5_ALPHA, RELENG_2_0_5, RELEASE_2_0, BETA_2_0, ALPHA_2_0 >>>> Branch point for: RELENG_2_1_0 >>>> Diff to: previous 1.1: preferred, colored >>>> Changes since revision 1.1: +2 -8 lines >>>> >>>> We really, really /don't/ want to have a shared lex library. =A0Also, >>>> current users should note that the old 1.1.5 lex can't process the >>>> new scan.l, so you have to copy initscan.c to obj/scan.c before it wil= l >>>> build. >>>> >>>> Garrett Wollman probably has more information about why this was done. >>>> >>>> I think that fixing the lib to build with the appropriate options (not >>>> -m32, or CPUTYPE =3D> some 32-bit x86 variant, etc) is what really nee= ds >>>> to be done here. >> >>> I guess I'm still confused. =A0The isi_date library compiles fine if >>> it's for i386, but switching to amd64 gives this error. =A0Since I >>> didn't specify any -m32 flags or anything, and it's essentially using >>> the standard bsd.lib.mk magic, I am trying to figure out why the >>> 32-bit isi_date.1.so built and the 64-bit one won't. =A0Was the 32-bit >>> version building successfully an unfortunate fluke? =A0What build flags >>> would get the shared library to link with -ll? >> >> I think that amd64 requires a static library be compiled with -fPIC if >> it's being linked into shared object. =A0This should not be done for >> normal static libraries, though, as this could give some performance >> penalty when it's not needed (i.e. a static binary). >> >>> Unfortunately, I didn't write this library, and I don't know anything >>> about lex(1), so if I need my own yywrap() that might be fine, but I >>> wouldn't have the first clue what to put in there. :-( >> >> I think you could probably just change the code and use %option noyywrap >> in the .l file? =A0(do your code call yywrap() directly?) > > ^^^^ I mean that the -ll can be just removed for most .l files that have > noyywrap. Thanks! I will try this on Tuesday when I get back to $work, Cheers, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTilyr3FTpZrttd812M7J_czEQ5xy21MbUPDa6Xla>