-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2010/07/02 16:34, Matthew Fleming wrote:
> On Fri, Jul 2, 2010 at 4:02 PM, Garrett Cooper <yanef...@gmail.com> wrote:
>> On Fri, Jul 2, 2010 at 2:51 PM, Matthew Fleming <mdf...@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?)
Cheers,
- --
Xin LI <delp...@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (FreeBSD)
iQEcBAEBCAAGBQJMLnvNAAoJEATO+BI/yjfB5Z0IAKLkyPPdzjeA0XJiLC3yTPRl
qzMHis5eo9rfFZgFpUzc22AQqxtu6pCYeovnESPiMkxG4r+Y20qQelJWEJs0nADT
AOAqv1dftwnd+WDbdkUOdBwELOOghJerlPClrn8XV5WiBVSf0GUNWeITXbOUEe3n
Urk5rINfoDwgXO1Xg/uxrEVsvJlCpzoKhS6ioQ8MW0QoBLk7WNujNakYqTYMCbLe
yaVkB44ab8Epka+LyjCWQcGtevwE+YX847malrAhtW4RChMEvIzZ9o76vAWPAo6q
8DRjRdN1xtC9hx3yH97kv3nFNMnvYRVCOTiVuatQKDCri60WyQ7vlhyi/zCw5jg=
=Vzkj
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
