Relocation error on x86_64

[oroppas]

Bugzilla Link	9603
Resolution	FIXED
Resolved on	Apr 01, 2011 18:12
Version	trunk
OS	Linux
CC	@oscarfv

Extended Description

Hi, when I compiled dragonegg on 64-bit version of Linux I got:

Linking dragonegg.so
/usr/bin/ld: cache.o: relocation R_X86_64_32 against `ggc_free' can not be used when making a shared object; recompile with -fPIC
cache.o: could not read symbols: Bad value
collect2: ld returned 1 exit status

I wonder if anyone can replicate the issue.

In my case, adding -fPIC to both CLFAGS ans CXXFLAGS fixed the problem.

Index: Makefile

--- Makefile (revision 128542)
+++ Makefile (working copy)
@@ -21,6 +21,11 @@
CFLAGS+=$(COMMON_FLAGS) $(shell $(LLVM_CONFIG) --cflags)
CXXFLAGS+=$(COMMON_FLAGS) $(shell $(LLVM_CONFIG) --cxxflags)

+ifeq ($(shell uname -m),x86_64)
+CFLAGS+=-fPIC
+CXXFLAGS+=-fPIC
+endif
+
ifeq ($(shell uname),Darwin)
LOADABLE_MODULE_OPTIONS=-bundle -undefined dynamic_lookup
else

Cheers,

Ryuta

[llvmbot]

What does
llvm-config --cflags
return? On my system it includes -fPIC:

-I/usr/local/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fomit-frame-pointer -g -fPIC

[oroppas]

What does
llvm-config --cflags
return? On my system it includes -fPIC:

-I/usr/local/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -O3 -fomit-frame-pointer -g -fPIC

Hmm, mine doesn't. This is how I configured LLVM:

cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr
-DBUILD_SHARED_LIBS:BOOL=ON
-DCMAKE_CXX_FLAGS:STRING="-O2 -march=native -pipe"
-DCMAKE_C_FLAGS:STRING="-O2 -march=native -pipe"
-DLLVM_BUILD_EXAMPLES:BOOL=OFF
-DLLVM_BUILD_TESTS:BOOL=ON
-DLLVM_BUILD_TOOLS:BOOL=ON
-DLLVM_INCLUDE_EXAMPLES:BOOL=ON
-DLLVM_INCLUDE_TESTS:BOOL=ON
-DLLVM_INCLUDE_TOOLS:BOOL=ON
-DLLVM_ENABLE_THREADS:BOOL=ON
-DLLVM_ENABLE_PEDANTIC:BOOL=ON
-DLLVM_ENABLE_WARNINGS:BOOL=ON
-DLLVM_ENABLE_WERROR:BOOL=OFF
-DLLVM_TARGETS_TO_BUILD:STRING="X86;PTX"
-DCLANG_BUILD_EXAMPLES:BOOL=ON

and the output of configuration looks like

-- Target triple: x86_64-unknown-linux-gnu
-- Native target architecture is X86
-- Threads enabled.
-- Building with -fPIC
-- Targeting X86
-- Targeting PTX
-- Clang version: 3.0
-- Configuring done

[llvmbot]

Rummaging around in the configure script, I see that ENABLE_PIC is set by
default. Also, if SHARED_LIBRARY is set then ENABLE_PIC is set in Makefile.rules

So first off it seems like cmake maybe does not default to setting ENABLE_PIC.
If so then I consider this to be a bug in the cmake setup. See below for another
possible explanation though.

More interestingly, it looks like SHARED_LIBRARY was maybe not set in spite of
your
-DBUILD_SHARED_LIBS:BOOL=ON
That would be pretty surprising.

However there is an alternative explanation, which is user error :)
By setting CFLAGS and CXXFLAGS explicitly on the cmake line (with no -fPIC)
you may have overridden the logic in Makefile.rules that puts -fPIC in CFLAGS
and CXXFLAGS if SHARED_LIBRARY is set.

Anyway, I suspect that LLVM itself was not built with -fPIC. As dragonegg links
with the LLVM libraries when building its shared library dragonegg.so, LLVM also
needs to be built with -fPIC.

[oroppas]

Rummaging around in the configure script, I see that ENABLE_PIC is set by
default. Also, if SHARED_LIBRARY is set then ENABLE_PIC is set in
Makefile.rules

So first off it seems like cmake maybe does not default to setting ENABLE_PIC.
If so then I consider this to be a bug in the cmake setup. See below for
another
possible explanation though.

More interestingly, it looks like SHARED_LIBRARY was maybe not set in spite of
your
-DBUILD_SHARED_LIBS:BOOL=ON
That would be pretty surprising.

However there is an alternative explanation, which is user error :)
By setting CFLAGS and CXXFLAGS explicitly on the cmake line (with no -fPIC)
you may have overridden the logic in Makefile.rules that puts -fPIC in CFLAGS
and CXXFLAGS if SHARED_LIBRARY is set.

Yeah. I dug a little bit and found out in llvm/tools/llvm-config/CMakeLists.txt
in line 94 and 95:

set(C_FLGS "${CMAKE_C_FLAGS_${uppercase_CMAKE_BUILD_TYPE}} ${LLVM_DEFINITIONS}")
set(CXX_FLGS "${CMAKE_CXX_FLAGS_${uppercase_CMAKE_BUILD_TYPE}} ${LLVM_DEFINITIONS}")

Anyway, I suspect that LLVM itself was not built with -fPIC. As dragonegg
links
with the LLVM libraries when building its shared library dragonegg.so, LLVM
also
needs to be built with -fPIC.

Contrary to the llvm-config, LLVM is built with -fPIC because in
llvm/cmake/modules/HandleLLVMOptions.cmake in line 86 and 87, there's a logic to append -fPIC to CMAKE_*_FLAGS

  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")
  set(CMAKE_C_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")

Then setting CMAKE_BUILD_TYPE to RelWithDebInfo the compilation looks like

cd /home/ryuta/devel/llvm/src/llvm-build/lib/Transforms/InstCombine && /usr/bin/c++ -DLLVMInstCombine_EXPORTS -D_GNU_SOURCE -D_DEBUG -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fPIC -fno-rtti -O2 -g -fPIC -I/home/ryuta/devel/llvm/src/llvm-build/lib/Transforms/InstCombine -I/home/ryuta/devel/llvm/src/llvm/lib/Transforms/InstCombine -I/home/ryuta/devel/llvm/src/llvm-build/include -I/home/ryuta/devel/llvm/src/llvm/include -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fno-exceptions -o CMakeFiles/LLVMInstCombine.dir/InstCombineShifts.cpp.o -c /home/ryuta/devel/llvm/src/llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp

which verifies the presence of -fPIC during build process.

Once the build finished, I checked the CXX_FLAGS

[ryuta@oroppas]$ ../../pkg/usr/bin/llvm-config --cxxflags
-I/home/ryuta/devel/llvm/pkg/usr/include -O2 -g -D_GNU_SOURCE -Wno-unused-parameter -Wwrite-strings -Wno-long-long -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS

-fPIC is gone. Now I suspect the line

set(CXX_FLGS "${CMAKE_CXX_FLAGS_${uppercase_CMAKE_BUILD_TYPE}} ${LLVM_DEFINITIONS}")

in llvm/tools/llvm-config/CMakeLists.txt is flawed since -fPIC is appended
to CMAKE_CXX_FLAGS as I mentioned above after CMAKE_CXX_FLAGS_${uppercase_CMAKE_BUILD_TYPE} is configured by CMake.

I confirmed it by printing variables in llvm/tools/llvm-config/CMakeLists.txt

-->CMAKE_CXX_FLAGS = -fPIC
-->CMAKE_BUILD_TYPE = RelWithDebInfo
-->uppercase_CMAKE_BUILD_TYPE = RELWITHDEBINFO
-->CMAKE_CXX_FLAGS_RELWITHDEBINFO = -O2 -g
-->CXX_FLGS = -O2 -g -D_GNU_SOURCE -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS

Did you build your LLVM by CMake? Can you verify the CXX_FLGS contains -fPIC?

Thanks.

[oroppas]

If what I described does indeed prevail in CMake build system then
the following patch can fix the issue.
It makes sure -fPIC is contained in CFLAGS and CXXFLAGS
in llvm-config.

Index: cmake/modules/HandleLLVMOptions.cmake

--- cmake/modules/HandleLLVMOptions.cmake (revision 128709)
+++ cmake/modules/HandleLLVMOptions.cmake (working copy)
@@ -84,7 +84,7 @@
if( SUPPORTS_FPIC_FLAG )
message(STATUS "Building with -fPIC")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")

•  set(CMAKE_C_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")
  

•  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fPIC")
  

  else( SUPPORTS_FPIC_FLAG )
  message(WARNING "-fPIC not supported.")
  endif()
  Index: tools/llvm-config/CMakeLists.txt
  ===================================================================
  --- tools/llvm-config/CMakeLists.txt (revision 128709)
  +++ tools/llvm-config/CMakeLists.txt (working copy)
  @@ -91,8 +91,8 @@
  DEPENDS ${LIBDEPS}
  COMMENT "Checking for cyclic dependencies between LLVM libraries.")

-set(C_FLGS "${CMAKE_C_FLAGS_${uppercase_CMAKE_BUILD_TYPE}} ${LLVM_DEFINITIONS}")
-set(CXX_FLGS "${CMAKE_CXX_FLAGS_${uppercase_CMAKE_BUILD_TYPE}} ${LLVM_DEFINITIONS}")
+set(C_FLGS "${CMAKE_C_FLAGS_${uppercase_CMAKE_BUILD_TYPE}} ${CMAKE_C_FLAGS} ${LLVM_DEFINITIONS}")
+set(CXX_FLGS "${CMAKE_CXX_FLAGS_${uppercase_CMAKE_BUILD_TYPE}} ${CMAKE_CXX_FLAGS} ${LLVM_DEFINITIONS}")
set(CPP_FLGS "${CMAKE_CPP_FLAGS_${uppercase_CMAKE_BUILD_TYPE}} ${LLVM_DEFINITIONS}")

We don't want certain flags on the output of

[llvmbot]

Was this only a CFLAGS issue, i.e. do you have -fPIC when you do
llvm-config --cxxflags
?

[oroppas]

No, it wasn't. Both CFLAGS and CXXFLAGS lacked -fPIC.

Was this only a CFLAGS issue, i.e. do you have -fPIC when you do
llvm-config --cxxflags
?

[llvmbot]

Looking in llvm/tools/llvm-config/Makefile I see

Combine preprocessor flags (except for -I) and CXX flags.

SUB_CPPFLAGS = ${CPP.BaseFlags}
SUB_CFLAGS = ${CPP.BaseFlags} ${C.Flags}
SUB_CXXFLAGS = ${CPP.BaseFlags} ${CXX.Flags}

while looking in llvm/Makefile.rules I see that programs actually get passed
more flags, for example:

Compile.CXX = $(BUILD_CXX) $(CPP.Flags) $(CXX.Flags) $(CXXFLAGS)
$(CPPFLAGS)
$(TargetCommonOpts) $(CompileCommonOpts) -c

Notice $(CXXFLAGS). I'm wondering if instead the fix shouldn't be to have
llvm-config also pick up the contents of CFLAGS and CXXFLAGS.

[oroppas]

My understanding is that llvm/tools/llvm-config/Makefile is OK.
Please keep in mind that Makefile is used by configure but not by CMake.
The patches would be applied only to CMake-related files.

Looking in llvm/tools/llvm-config/Makefile I see

Combine preprocessor flags (except for -I) and CXX flags.

SUB_CPPFLAGS = ${CPP.BaseFlags}
SUB_CFLAGS = ${CPP.BaseFlags} ${C.Flags}
SUB_CXXFLAGS = ${CPP.BaseFlags} ${CXX.Flags}

while looking in llvm/Makefile.rules I see that programs actually get passed
more flags, for example:

Compile.CXX = $(BUILD_CXX) $(CPP.Flags) $(CXX.Flags) $(CXXFLAGS)
$(CPPFLAGS)
$(TargetCommonOpts) $(CompileCommonOpts) -c

Notice $(CXXFLAGS). I'm wondering if instead the fix shouldn't be to have
llvm-config also pick up the contents of CFLAGS and CXXFLAGS.

[llvmbot]

As you can see I don't know anything about cmake :) Nonetheless, cmake must then
have its own logic to pass CFLAGS etc to llvm-config. So mightn't that be the
right place to fix things?

[oroppas]

Well, that would be llvm/cmake/modules/HandleLLVMOptions.cmake and
llvm/tools/llvm-config/CMakeLists.txt.

In any case, this is not a bug in DragonEgg but in LLVM.
We may want to file these as bug reports in LLVM.

As you can see I don't know anything about cmake :) Nonetheless, cmake must
then
have its own logic to pass CFLAGS etc to llvm-config. So mightn't that be the
right place to fix things?

[oscarfv]

I committed the patch showed here (with minor modifications.) Please test if this fixes the issue for you and close the bug if the answer is affirmative.

There is another glitch on the output of `llvm-config -cxxflags': it omits the include flags for the source directory. This is due to the logic on llvm-config failing when deciding if it is being executed on a installed directory or on the build directory.

[oroppas]

It looks perfect.

[ryuta@oroppas]$ llvm-config --cflags
-I/usr/include -O2 -march=native -pipe -fPIC -D_GNU_SOURCE -Wno-unused-parameter -Wwrite-strings -Wno-long-long -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
[ryuta@oroppas]$ llvm-config --cxxflags
-I/usr/include -O2 -march=native -pipe -fPIC -D_GNU_SOURCE -Wno-unused-parameter -Wwrite-strings -Wno-long-long -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS

Thanks for the fix!

I committed the patch showed here (with minor modifications.) Please test if
this fixes the issue for you and close the bug if the answer is affirmative.

There is another glitch on the output of `llvm-config -cxxflags': it omits the
include flags for the source directory. This is due to the logic on llvm-config
failing when deciding if it is being executed on a installed directory or on
the build directory.