From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 3 04:04:48 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 7385F1065672 for ; Sat, 3 Jul 2010 04:04:48 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 369D98FC0C for ; Sat, 3 Jul 2010 04:04:47 +0000 (UTC) Received: by iwn35 with SMTP id 35so1963681iwn.13 for ; Fri, 02 Jul 2010 21:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GgbCKxjDMBJIQzBK3ois0wt+UljZO/8+74sqSK3dfGE=; b=DlABBfxlwpjGH7rGxdnoyBoB6Eqg3f2npnZs3y9+fO2jYcCrTaaJ8fDp6RH2j/g3SY a9j7WKjrKX8PVCPe2spgkLQWI78rCAHtzbTY7hLVLh1XTnfkb3UG+2iCgZgMf5iI54z2 2zPeZjmyCN0VziuOPsJBL9TDHoZ3rwKHkN4lY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WNtUfw7Ri0j0KvXwQ48P5ZbC9xfnIwnCzqgFingACWZTyYLIwepfgwpg2eABefDcDd baRNx8dFg688auL4XgZ14eTtrUadcYntsvOum2uZOBXPee7m4k2Emwjl8otu5lsQofVI mcPKbQIC+pmxoKd2GlTgh4Uj43b41weUvYNrA= MIME-Version: 1.0 Received: by 10.42.9.29 with SMTP id k29mr561769ick.90.1278129887522; Fri, 02 Jul 2010 21:04:47 -0700 (PDT) Received: by 10.42.5.78 with HTTP; Fri, 2 Jul 2010 21:04:47 -0700 (PDT) In-Reply-To: <4C2E7C29.2080307@delphij.net> References: <4C2E7BCD.4020609@delphij.net> <4C2E7C29.2080307@delphij.net> Date: Sat, 3 Jul 2010 04:04:47 +0000 Message-ID: From: Matthew Fleming To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 04:04:48 -0000 On Fri, Jul 2, 2010 at 11:54 PM, Xin LI 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 wro= te: >>>> On Fri, Jul 2, 2010 at 2:51 PM, Matthew Fleming 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