mtcp-stack / mtcp

mTCP: A Highly Scalable User-level TCP Stack for Multicore Systems

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Issue compiling with clang?

ZiyanWu93 opened this issue · comments

Hi,

I am trying to setup/run mTCP in my environment (uses mlx5).
I compiled DPDK from the the devel branch. It is compiled using clang.
RTE_TARGET=x86_64-native-linuxapp-clang

While doing make, I get this error. Here is a snippet.

r - io_module.o
r - dpdk_module.o
r - netmap_module.o
r - onvm_module.o
r - icmp.o
r - pacing.o
r - clock.o
make[2]: Leaving directory '/home/user/test/mtcp/mtcp/src'
Making all in util
make[2]: Entering directory '/home/user/test/mtcp/util'
   CC tdate_parse.c
   CC http_parsing.c
   CC netlib.c
make[2]: Leaving directory '/home/user/test/mtcp/util'
Making all in io_engine/lib
make[2]: Entering directory '/home/user/test/mtcp/io_engine/lib'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/user/test/mtcp/io_engine/lib'
Making all in apps/example
make[2]: Entering directory '/home/user/test/mtcp/apps/example'
   LD epserver.o
/usr/bin/ld: /home/user/test/mtcp/dpdk/x86_64-native-linuxapp-clang/lib/librte_pipeline.a(rte_pipeline.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /home/user/test/mtcp/dpdk/x86_64-native-linuxapp-clang/lib/librte_pipeline.a(rte_port_in_action.o): relocation R_X86_64_32 against `.text' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /home/user/test/mtcp/dpdk/x86_64-native-linuxapp-clang/lib/librte_pipeline.a(rte_table_action.o): relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /home/user/test/mtcp/dpdk/x86_64-native-linuxapp-clang/lib/librte_table.a(rte_table_lpm.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /home/user/test/mtcp/dpdk/x86_64-native-linuxapp-clang/lib/librte_table.a(rte_table_lpm_ipv6.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /home/user/test/mtcp/dpdk/x86_64-native-linuxapp-clang/lib/librte_table.a(rte_table_acl.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /home/user/test/mtcp/dpdk/x86_64-native-linuxapp-clang/lib/librte_table.a(rte_table_hash_cuckoo.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /home/user/test/mtcp/dpdk/x86_64-native-linuxapp-clang/lib/librte_table.a(rte_table_hash_key8.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /home/user/test/mtcp/dpdk/x86_64-native-linuxapp-clang/lib/librte_table.a(rte_table_hash_key16.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /home/user/test/mtc

I tried to search more about recompile with -fPIC and found this SO discussion suggesting to use --enable-shared with ./configure might help.

Unfortunately, it didn't.

Any help is much appreciated.

@ZiyanWu93 ,

Can you please tell which version of clang you are using? I will try to do some tests on my end as well. Also, please check whether you are able to compile example applications in dpdk/examples/ directory.

A short term solution is that you update all the Makefiles present in the dpdk/lib* directory and append -fPIC to CFLAGS macro. Let me get back to you and see if I can find an easier fix.

@ZiyanWu93,

The following is the easiest, quick fix for this issue:

Compile dpdk for clang the normal way. Follow the guideline mentioned in the README. At the very last stage, manually edit CC in apps/example/Makefile to clang. Leave the CC as gcc in mtcp/src/Makefile for the time being. mTCP was never really tested with clang. I will patch up the source the next time I find time.

@ajamshed

The compilation is successful now. Thanks for your answer and help!