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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:22 UTC