Using lex in a shared library

[Matthew Fleming]

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?

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. :-(

Thanks,
matthew