Relocation error against undefined symbo

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

相关文章推荐

绅士的牛肉面 · 6月3-4日，11-12日基于R语言机器学习 ...· 1 月前 ·

胆小的卤蛋 · ApeForms | C# - ...· 2 月前 ·

呐喊的机器猫 · Entity Framework Support· 6 月前 ·

爽快的咖啡豆 · IBM Cloud Docs· 8 月前 ·

道上混的西红柿 · 【无节操】矢口恭介，在线黑化。_哔哩哔哩_b ...· 10 月前 ·

Hi, When building a certain software, I receive this error message during the link stage:

/usr/bin/ld: _obj/device/r4300/x86_64/dyna_start.o: relocation R_X86_64_PC32 against undefined symbol `g_dev' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value

Since it said to recompile with -fPIC, I followed the instructions.
I opened the Makefile and added it to all the rules, that became:

# standard build rules
$(OBJDIR)/%.o: $(SRCDIR)/%.asm $(SRCDIR)/asm_defines/asm_defines_nasm.h
	$(COMPILE.as) -o -fPIC $@ $<
$(OBJDIR)/%.o: $(SRCDIR)/%.S $(SRCDIR)/asm_defines/asm_defines_gas.h
	$(COMPILE.c) -o -fPIC $@ $<
$(OBJDIR)/%.o: $(SRCDIR)/%.c
	$(COMPILE.c) -o -fPIC $@ $<
$(OBJDIR)/%.o: $(SRCDIR)/%.cpp
	$(COMPILE.cc) -o -fPIC $@ $<
$(OBJDIR)/subprojects/%.o: $(SUBDIR)/%.c
	$(COMPILE.c) -o -fPIC $@ $<
$(OBJDIR)/subprojects/%.o: $(SUBDIR)/%.cpp
	$(COMPILE.cc) -o -fPIC $@ $<

And then tried to build the software again. But now I am receiving:

Makefile:322: Using SDL 1.2 libraries
    CC  _obj/api/callbacks.o
    CC  _obj/api/common.o
gcc: error: _obj/api/common.o: No such file or directory
gcc: error: _obj/api/callbacks.o: No such file or directory

So, what's going on now? Be sure that every object file ( .o ) or static library ( .a ) you are linking in has been compiled with


    -fPIC

.
Maybe adding


    -Wl,--trace

to your gcc linker command can help to show more details.
Also, be sure you re-build your files after Makefile changes. For example, run


    make -B

in order to force a "full" rebuild. Last edited on I added -Wl,--trace, but it didn't provide me any hints about it.
The last lines are these:

-lstdc++ (/media/34GB/Arquivos-de-Programas-Linux/Gcc-4.9.4/lib/gcc/x86_64-linux-gnu/4.9.4/../../../../lib64/libstdc++.so)
-lm (/usr/lib/../lib64/libm.so)
-lgcc_s (/media/34GB/Arquivos-de-Programas-Linux/Gcc-4.9.4/lib/gcc/x86_64-linux-gnu/4.9.4/../../../../lib64/libgcc_s.so)
/lib64/libc.so.6
/lib64/ld-linux-x86-64.so.2
-lgcc_s (/media/34GB/Arquivos-de-Programas-Linux/Gcc-4.9.4/lib/gcc/x86_64-linux-gnu/4.9.4/../../../../lib64/libgcc_s.so)
/media/34GB/Arquivos-de-Programas-Linux/Gcc-4.9.4/lib/gcc/x86_64-linux-gnu/4.9.4/crtfastmath.o
/media/34GB/Arquivos-de-Programas-Linux/Gcc-4.9.4/lib/gcc/x86_64-linux-gnu/4.9.4/crtendS.o
/usr/lib/../lib64/crtn.o
/usr/bin/ld: _obj/device/r4300/x86_64/dyna_start.o: relocation R_X86_64_PC32 against undefined symbol `g_dev' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value

The Makefile's object rules are these:

# It is important to disable LTO for this object file
# otherwise we can't extract usefull information from it.
$(ASM_DEFINES_OBJ): $(SRCDIR)/asm_defines/asm_defines.c
	$(COMPILE.c) -fno-lto -fPIC -o $@ $<

# standard build rules
$(OBJDIR)/%.o: $(SRCDIR)/%.asm $(SRCDIR)/asm_defines/asm_defines_nasm.h
	$(COMPILE.as)  -o $@ $<
$(OBJDIR)/%.o: $(SRCDIR)/%.S $(SRCDIR)/asm_defines/asm_defines_gas.h
	$(COMPILE.c) -fPIC -o $@ $<
$(OBJDIR)/%.o: $(SRCDIR)/%.c
	$(COMPILE.c) -fPIC -o $@ $<
$(OBJDIR)/%.o: $(SRCDIR)/%.cpp
	$(COMPILE.cc) -fPIC -o $@ $<
$(OBJDIR)/subprojects/%.o: $(SUBDIR)/%.c
	$(COMPILE.c) -fPIC -o $@ $<
$(OBJDIR)/subprojects/%.o: $(SUBDIR)/%.cpp
	$(COMPILE.cc) -fPIC -o $@ $<

1
2
3

$(TARGET): $(OBJECTS)
	$(LINK.o) $^ $(LOADLIBES) $(LDLIBS) -Wl,--trace -o $@
	if [ "$(SONAME)" != "" ]; then ln -sf $@ $(SONAME); fi

As can be seen, I did not add -fPIC to

$(OBJDIR)/%.o: $(SRCDIR)/%.asm $(SRCDIR)/asm_defines/asm_defines_nasm.h
	$(COMPILE.as)  -o $@ $<

because it causes a


     nasm: fatal: unrecognised output format `PIC
     
      ' - use -hf for a list

I did use a make clean before the last attempt. make -B does not work
I think when "compiling" assembly (ASM) code, you cannot and don't need to specify


     -fPIC

, because it would be the job of the assembly programmer to ensure that the assembly code itself does not use absolute memory addressing... Last edited on