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
O. Hartmann
ohartman at zedat.fu-berlin.de
Thu Dec 29 12:19:27 UTC 2011
Am 12/29/11 12:59, schrieb Kostik Belousov:
> 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<rhurlin at gwdg.de>, 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/precompiled/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 ?
>>>
>>> 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.
>>>
>>>
>>> I found another trail, which hopefully is more usefull for solving the
>>> problem Oliver described.
>>>
>>> Whe I try to build lang/lua I get this error:
>>>
>>> [..snip..]
>>> cc -o liblua.so -O2 -fno-strict-aliasing -pipe -msse3 -Wall
>>> -DLUA_USE_LINUX -shared -Wl,-soname=liblua-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
>>>
>>>
>>> It also gives a linker error, almost the same relocation is named. This
>>> does only happen with option '-msse3' enabled in /etc/make.conf:
>>>
>>> CFLAGS= -O2 -fno-strict-aliasing -pipe -msse3
>>>
>>> Using CLFAGS without -msse3 (default) works well:
>>>
>>> CFLAGS= -O2 -fno-strict-aliasing -pipe
>>>
>>>
>>> The systems processor, were this happens, is a
>>>
>>> CPU: AMD Phenom(tm) II X6 1090T Processor (3214.32-MHz K8-class CPU)
>>> Origin = "AuthenticAMD" Id = 0x100fa0 Family = 10 Model = a
>>> Stepping = 0
>>> Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
>>>
>>> Features2=0x802009<SSE3,MON,CX16,POPCNT>
>>> AMD
>>> Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
>>> AMD
>>> Features2=0x37ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT>
>>>
>>> TSC: P-state invariant, performance statistics
>>>
>>> FreeBSD 10-CURRENT (amd64) r228920
>>>
>>> In hope of a more belonging posting,
>>> Rainer
>>> _______________________________________________
>>
>>
>> WOW!
>>
>> I tried lang/lua on FreeBSD 9.0-PRE and see exactly this error:
>>
>> clang -O2 -fno-strict-aliasing -pipe -march=core2 -Wall -DLUA_USE_LINUX
>> -c print.c
>> clang -o liblua.so -O2 -fno-strict-aliasing -pipe -march=core2 -Wall
>> -DLUA_USE_LINUX -shared -Wl,-soname=liblua-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
>>
>> Stop in /usr/ports/lang/lua.
>>
>> ===>>> make failed for lang/lua
>> ===>>> Aborting update
>>
>>
>>
>> On FreeBSD 10.0-CURRENT I see this:
>> clang -O2 -fno-strict-aliasing -pipe -march=core2 -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=core2 -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=core2 -Wall -DLUA_USE_LINUX
>> -c luac.c
>> clang -O2 -fno-strict-aliasing -pipe -march=core2 -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=core2 -Wall
>> -DLUA_USE_LINUX -shared -Wl,-soname=liblua-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
>>
>> Stop in /usr/ports/lang/lua/work/lua-5.1.4/src.
>> *** Error code 1
>>
>> Stop in /usr/ports/lang/lua/work/lua-5.1.4/src.
>> *** Error code 1
>>
>> Stop in /usr/ports/lang/lua/work/lua-5.1.4.
>> *** Error code 1
>>
>> Stop in /usr/ports/lang/lua.
>>
>> ===>>> make failed for lang/lua
>> ===>>> Aborting update
>>
>> Terminated
>> Terminated
>>
>> 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.
This therefore strange, since this problem with lua occurs on machines,
where I've set "CFLAGS=" and "COPTFLAGS=" as in
/usr/share/examples/etc/make.conf and on one box, one box I accidentally
set those flags to "CFLAGS+=" and "COPTFLAGS+=" and there it works and
the -fPIC flag is set by the FreeBSD's port framework.
So I guess there is a bug introduced with one of the last Mk-files updates.
>
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20111229/cc33b31a/signature.pgp
More information about the freebsd-ports
mailing list