From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 23:52:59 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE146106566C for ; Fri, 2 Jul 2010 23:52:59 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 327128FC08 for ; Fri, 2 Jul 2010 23:52:59 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 3A379A5A480; Sat, 3 Jul 2010 07:52:58 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id AQu8bQGWVL6b; Sat, 3 Jul 2010 07:52:52 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 8C0CAA5A47B; Sat, 3 Jul 2010 07:52:50 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=NXSxbpQkRtEFg2owCXKttGHcgD/RoT4kC5i0b1a8rvQ9B7yBPpkOMTf7YTAmPhU2g cQA3UxJvkx+tbp+bPw5Gg== Message-ID: <4C2E7BCD.4020609@delphij.net> Date: Fri, 02 Jul 2010 16:52:45 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100629 Thunderbird/3.0.5 ThunderBrowse/3.3 MIME-Version: 1.0 To: Matthew Fleming References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 23:53:00 -0000 -----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 wrote: >> On Fri, Jul 2, 2010 at 2:51 PM, Matthew Fleming 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 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-----