Using lex in a shared library

[Xin LI]

-----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 at gmail.com> wrote:
>>> On Fri, Jul 2, 2010 at 2:51 PM, Matthew Fleming <mdf356 at gmail.com> wrote:
>>>> I have the following Makefile for a shared library at $work:
>>>>
>>>> ISI_TOP=        ../..
>>>>
>>>> LIB=            isi_date
>>>> SHLIB_MAJOR=    1
>>>> SHLIB_MINOR=    0
>>>> SRCS=           date.c date_parser.new.c lex.yy.c
>>>> INCS=           date.h
>>>> INCLUDEDIR=     /usr/include/isi_date
>>>>
>>>> YFLAGS+=        -vt
>>>> FLEX=           /usr/bin/flex
>>>> LDADD=          -ll
>>>>
>>>> CLEANFILES+=    date_parser.new.c y.tab.h y.tab.c lex.yy.c y.output \
>>>>                check_date.log test
>>>>
>>>> lex.yy.c: date_lexer.new.l
>>>>        ${FLEX} $>
>>>>
>>>> CFLAGS+=        -I${.CURDIR}
>>>> #CFLAGS+=       -g
>>>>
>>>> .include "${ISI_TOP}/isi.lib.mk"
>>>>
>>>>
>>>>
>>>> This builds fine as on i386.  I'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/libl.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/libl.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
>>>> ===================================================================
>>>> --- usr.bin/lex/lib/Makefile    (revision 153343)
>>>> +++ usr.bin/lex/lib/Makefile    (working copy)
>>>> @@ -4,11 +4,16 @@
>>>>
>>>>  LIB=    ln
>>>>  SRCS=   libmain.c libyywrap.c
>>>> -NO_PIC=
>>>> +#NO_PIC=
>>>>
>>>> +SHLIB_MAJOR=   1
>>>> +SHLIB_MINOR=   0
>>>> +
>>>>  .if ${MK_INSTALLLIB} != "no"
>>>>  LINKS=  ${LIBDIR}/libln.a ${LIBDIR}/libl.a
>>>>  LINKS+=        ${LIBDIR}/libln.a ${LIBDIR}/libfl.a
>>>> +LINKS+=        ${LIBDIR}/libln.so ${LIBDIR}/libl.so
>>>> +LINKS+=        ${LIBDIR}/libln${LIB_SUFFIX}.so ${LIBDIR}/libl${LIB_SUFFIX}.so
>>>>  .endif
>>>>
>>>>  .if ${MK_PROFILE} != "no"
>>>
>>> The static-only version was done on purpose:
>>>
>>> Revision 1.2: download - view: text, markup, annotated  - 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.  Also,
>>> 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 will
>>> 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 => some 32-bit x86 variant, etc) is what really needs
>>> to be done here.
> 
>> I guess I'm still confused.  The isi_date library compiles fine if
>> it's for i386, but switching to amd64 gives this error.  Since 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.  Was the 32-bit
>> version building successfully an unfortunate fluke?  What 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.  This 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?  (do your code call yywrap() directly?)

^^^^ I mean that the -ll can be just removed for most .l files that have
noyywrap.

Cheers,
- -- 
Xin LI <delphij at delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!	       Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (FreeBSD)

iQEcBAEBCAAGBQJMLnwpAAoJEATO+BI/yjfBWqYIAIIWXmxVQd4M50KGu95aqlcm
cfNKfyNzVfskdIj6Bcv5R/rRBAcqzdO+lPFdOupe0yMLFe0RUXiakNrI/NsMwKDx
T/JErNiOgIUnsAKzkeV720nd73o1oTFGwIfqJ0XoNzYwl+bPU1JWG6cognXSlJha
MCVVO8Rh/91Sle0KUb51dhCC+LFES+F9zzDMrPb1cGihN2CLZgaLvdDVbLYuRXn3
SZd62lE2dCZiILy7fy3nJRhybDJf/9hvu4WWFlmNPGt95U6Nzo9KBx9/MHMuvGCm
kt7BUxj/zxR2PW9gBhn7ao8AtOkwA5qKSm07xb3w0LL6xXtgZDQpXQNwMIZP57g=
=Ilvp
-----END PGP SIGNATURE-----