From owner-freebsd-current@FreeBSD.ORG Thu Dec 29 11:59:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C59C0106564A; Thu, 29 Dec 2011 11:59:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 275C48FC08; Thu, 29 Dec 2011 11:59:10 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pBTBx4IA053135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Dec 2011 13:59:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pBTBx4oN017116; Thu, 29 Dec 2011 13:59:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBTBx4Oo017115; Thu, 29 Dec 2011 13:59:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 29 Dec 2011 13:59:04 +0200 From: Kostik Belousov To: "O. Hartmann" Message-ID: <20111229115904.GH50300@deviant.kiev.zoral.com.ua> References: <4EFAF3FC.60002@zedat.fu-berlin.de> <20111228135808.GW50300@deviant.kiev.zoral.com.ua> <4EFB2344.3000302@zedat.fu-berlin.de> <20111228142957.GX50300@deviant.kiev.zoral.com.ua> <4EFB447D.3000808@gwdg.de> <20111228181054.GF1895@hoeg.nl> <4EFB5E0C.90302@zedat.fu-berlin.de> <20111228183132.GB50300@deviant.kiev.zoral.com.ua> <4EFC4579.6060608@gwdg.de> <4EFC4CCC.3050507@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EUBiG/BDWfQOM97z" Content-Disposition: inline In-Reply-To: <4EFC4CCC.3050507@zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ed Schouten , Ports FreeBSD , Current FreeBSD Subject: Re: lang/lua: /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 11:59:11 -0000 --EUBiG/BDWfQOM97z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 29, 2011 at 12:19:40PM +0100, O. Hartmann wrote: > Am 12/29/11 11:48, schrieb Rainer Hurling: > > On 28.12.2011 19:31 (UTC+1), Kostik Belousov wrote: > >> On Wed, Dec 28, 2011 at 07:21:00PM +0100, O. Hartmann wrote: > >>> Am 12/28/11 19:10, schrieb Ed Schouten: > >>>> * Rainer Hurling, 20111228 17:31: > >>>>> error: macro "_Static_assert" passed 3 arguments, but takes just 2 > >>>>> In file included from > >>>>> /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/pr= ecompiled/stdc++.h:103:0: > >>>>> > >>>> > >>>> Hmmm... This seems to apply to my changes. I will look into this > >>>> tomorrow. Thanks for the report! > >>>> > >>> > >>> > >>> Be aware that the error produced by the linker I mentioned in the > >>> initial post occurs on FreeBSD 10 as well as FreeBSD 9.0. > >>> > >>> I already filed a PR about the problem of a non compiling lang/gcc46 > >>> today (ports/163672: lang/gcc46: make failed for lang/gcc46). For test > >>> puproses, I rebuild gcc46 on our FreeBSD 9.0 boxes - without any > >>> problem. > >>> > >>> I guess, the commit r228902 has been done to FreeBSD 10.0 and not 9.0. > >> > >> Obviously, linker error during the compilation of third-party software > >> has nothing to do with compiler error occuring when building gcc. > >> > >> Do people ever read the texts of the messages ? > >=20 > > Kostik, probably you are right. I had read the messages, but there are > > some strange errors with gcc46 on head for two days now, which leaded me > > in the wrong direction. So sorry for erroneously 'hijacking' this thread > > with another problem most certain only existing in head. > >=20 > >=20 > > I found another trail, which hopefully is more usefull for solving the > > problem Oliver described. > >=20 > > Whe I try to build lang/lua I get this error: > >=20 > > [..snip..] > > cc -o liblua.so -O2 -fno-strict-aliasing -pipe -msse3 -Wall > > -DLUA_USE_LINUX -shared -Wl,-soname=3Dliblua-5.1.so.1 lapi.o lcode.o > > ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o > > lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o > > lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o > > lstrlib.o loadlib.o linit.o > > ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o > > llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o > > ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o > > lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o > > ranlib liblua.a > > cc -o lua lua.o liblua.a -lm -Wl,-E -lreadline > > cc -o luac luac.o print.o liblua.a -lm -Wl,-E -lreadline > > /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' > > can not be used when making a shared object; recompile with -fPIC > > lapi.o: could not read symbols: Bad value > > *** Error code 1 > >=20 > >=20 > > It also gives a linker error, almost the same relocation is named. This > > does only happen with option '-msse3' enabled in /etc/make.conf: > >=20 > > CFLAGS=3D -O2 -fno-strict-aliasing -pipe -msse3 > >=20 > > Using CLFAGS without -msse3 (default) works well: > >=20 > > CFLAGS=3D -O2 -fno-strict-aliasing -pipe > >=20 > >=20 > > The systems processor, were this happens, is a > >=20 > > CPU: AMD Phenom(tm) II X6 1090T Processor (3214.32-MHz K8-class CPU) > > Origin =3D "AuthenticAMD" Id =3D 0x100fa0 Family =3D 10 Model =3D a > > Stepping =3D 0 > > Features=3D0x178bfbff > >=20 > > Features2=3D0x802009 > > AMD > > Features=3D0xee500800 > > AMD > > Features2=3D0x37ff > >=20 > > TSC: P-state invariant, performance statistics > >=20 > > FreeBSD 10-CURRENT (amd64) r228920 > >=20 > > In hope of a more belonging posting, > > Rainer > > _______________________________________________ >=20 >=20 > WOW! >=20 > I tried lang/lua on FreeBSD 9.0-PRE and see exactly this error: >=20 > clang -O2 -fno-strict-aliasing -pipe -march=3Dcore2 -Wall -DLUA_USE_LINUX > -c print.c > clang -o liblua.so -O2 -fno-strict-aliasing -pipe -march=3Dcore2 -Wall > -DLUA_USE_LINUX -shared -Wl,-soname=3Dliblua-5.1.so.1 lapi.o lcode.o > ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o > lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o > lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o > lstrlib.o loadlib.o linit.o > /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' > can not be used when making a shared object; recompile with -fPIC > lapi.o: could not read symbols: Bad value > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > *** Error code 1 > ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o > llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o > ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o > lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o > ranlib liblua.a > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 1 >=20 > Stop in /usr/ports/lang/lua. >=20 > =3D=3D=3D>>> make failed for lang/lua > =3D=3D=3D>>> Aborting update >=20 >=20 >=20 > On FreeBSD 10.0-CURRENT I see this: > clang -O2 -fno-strict-aliasing -pipe -march=3Dcore2 -Wall -DLUA_USE_LINUX > -c linit.c > ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o > llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o > ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o > lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o > ranlib liblua.a > clang -O2 -fno-strict-aliasing -pipe -march=3Dcore2 -Wall -DLUA_USE_LINUX > -c lua.c > clang -o lua lua.o liblua.a -lm -Wl,-E -lreadline > clang -O2 -fno-strict-aliasing -pipe -march=3Dcore2 -Wall -DLUA_USE_LINUX > -c luac.c > clang -O2 -fno-strict-aliasing -pipe -march=3Dcore2 -Wall -DLUA_USE_LINUX > -c print.c > clang -o luac luac.o print.o liblua.a -lm -Wl,-E -lreadline > clang -o liblua.so -O2 -fno-strict-aliasing -pipe -march=3Dcore2 -Wall > -DLUA_USE_LINUX -shared -Wl,-soname=3Dliblua-5.1.so.1 lapi.o lcode.o > ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o > lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o > lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o > lstrlib.o loadlib.o linit.o > /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' > can not be used when making a shared object; recompile with -fPIC > lapi.o: could not read symbols: Bad value > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > *** Error code 1 >=20 > Stop in /usr/ports/lang/lua/work/lua-5.1.4/src. > *** Error code 1 >=20 > Stop in /usr/ports/lang/lua/work/lua-5.1.4/src. > *** Error code 1 >=20 > Stop in /usr/ports/lang/lua/work/lua-5.1.4. > *** Error code 1 >=20 > Stop in /usr/ports/lang/lua. >=20 > =3D=3D=3D>>> make failed for lang/lua > =3D=3D=3D>>> Aborting update >=20 > Terminated > Terminated >=20 > This is very strange! What is strange ? It is exactly the same problem as in the first message started this thread. You must use -fPIC flag for compiler when compiling objects that shall be later linked into dso. So, for lua case, -fPIC must be present on the cc -c command line. Again, -msse3 is not relevant there. Presense of -msse3 flag might casually change compiler output to generate the relocation unsuitable for dso, but compiler has full permit to do so without -msse3 as well. Issue with broken gcc 4.6 build is different, it is indeed due to recent changes in system headers due to C11 compliance work. Hopefully, Ed will fix it. --EUBiG/BDWfQOM97z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk78VggACgkQC3+MBN1Mb4hN4wCfSZQ3tHL8OQ+3k8zq8lNr+NfK mvkAoMd0mvwXqpjlLoomyIDqb0xkeXF4 =ypP7 -----END PGP SIGNATURE----- --EUBiG/BDWfQOM97z--