fPIC errors

[nachiket]

I'm trying to install CVC on Ubuntu 16.10 but get the following errors on make -f makefile.cvc64

gcc  -pipe -Wall -I../pli_incs -fPIC -D__RHEL6X__  -fno-strength-reduce -fomit-frame-pointer -O2  -export-dynamic dig_main.o cvc.o v_src.o v_src2.o v_src3.o v_fx.o v_genfx.o v_fx2.o v_fx3.o v_cnv.o v_ex.o v_ex2.o v_ex3.o v_ex4.o v_trch.o v_del.o v_sdf.o v_prp.o v_prp2.o v_sim.o v_dbg.o v_dbg2.o v_cvr.o v_ms.o v_tf.o v_acc.o v_vpi.o v_vpi2.o v_vpi3.o v_dpi.o v_bbgen.o v_bbgen2.o v_bbgen3.o v_bbopt.o v_cvcms.o v_asmlnk.o v_aslib.o v_regasn.o v_cvcrt.o v_xprop.o fstapi.o fastlz.o lz4.o \
        -lm -ldl -lpthread -lz cvclib_str.o exe_main_str.o -o cvc64
/usr/bin/ld: v_sim.o: relocation R_X86_64_32S against undefined symbol `__idp' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: v_aslib.o: relocation R_X86_64_32S against undefined symbol `__idp' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.27 internal error, aborting at ../../bfd/elf64-x86-64.c:4580 in elf_x86_64_relocate_section

I added -fPIC to the compile flags but to no avail.

[jankcorn]

It looks like '__idp' should have been defined in the object cvc.o. (when I compiled it, that is where it was) On line 1078 of src/cvc.c, could you change: t_midat *__idp; to t_midat *__idp = NULL; ? (this will push it to the data section instead of BSS/Common) Also, if you could do: nm cvc.o | grep __idp ? I get: 00000004 C __idp 00000000 B __idpdat_areasp thanks jca

…

On Thu, May 4, 2017 at 11:57 AM, nachiket ***@***.***> wrote: I'm trying to install CVC on Ubuntu 16.10 but get the following errors on make -f makefile.cvc64 gcc -pipe -Wall -I../pli_incs -fPIC -D__RHEL6X__ -fno-strength-reduce -fomit-frame-pointer -O2 -export-dynamic dig_main.o cvc.o v_src.o v_src2.o v_src3.o v_fx.o v_genfx.o v_fx2.o v_fx3.o v_cnv.o v_ex.o v_ex2.o v_ex3.o v_ex4.o v_trch.o v_del.o v_sdf.o v_prp.o v_prp2.o v_sim.o v_dbg.o v_dbg2.o v_cvr.o v_ms.o v_tf.o v_acc.o v_vpi.o v_vpi2.o v_vpi3.o v_dpi.o v_bbgen.o v_bbgen2.o v_bbgen3.o v_bbopt.o v_cvcms.o v_asmlnk.o v_aslib.o v_regasn.o v_cvcrt.o v_xprop.o fstapi.o fastlz.o lz4.o \ -lm -ldl -lpthread -lz cvclib_str.o exe_main_str.o -o cvc64 /usr/bin/ld: v_sim.o: relocation R_X86_64_32S against undefined symbol `__idp' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: v_aslib.o: relocation R_X86_64_32S against undefined symbol `__idp' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.27 internal error, aborting at ../../bfd/elf64-x86-64.c:4580 in elf_x86_64_relocate_section I added -fPIC to the compile flags but to no avail. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABvY-EzkxrAS7394sxd2qPcIISLplSaVks5r2h-NgaJpZM4NRFLy> .

[nachiket]

Doesn't seem to have helped. Still fails at the relocation error.

(Before NULL init value)
➜ src git:(master) ✗ 17-05-04 3:35PM nm cvc.o| grep __idp
0000000000000008 C __idp
0000000000000000 B __idpdat_areasp

(After NULL init value)
➜ src git:(master) ✗ 17-05-04 3:40PM nm cvc.o| grep __idp
0000000000000020 B __idp
0000000000000000 B __idpdat_areasp

[jameyhicks]

The error is caused by the use of __idp from inline asm, such as this line:
__asm__ ("movq __first_enterp, %%rax" ::: "%rax");

If I change it to:
void *p_first_enterp = &__first_enterp; __asm__ ("movq %0, %%rax" :: "r" (p_first_enterp): "%rax");
the relocation error goes away. (same pattern for __idp)

I have not tested this yet.

[jameyhicks]

I have a feeling that the compilation model has changed and that code and data may be farther apart in address space than in earlier gcc/glibc, causing this relocation to fail.

[jameyhicks]

Commit a6215a8 is my first attempt to fix this. At least it compiles now.

[phil94028]

I did try a6125a8 and it does indeed compile cvc on Ubuntu 17..04 zesty. The executable errors out though. This is a pretty fresh VM install. A friend reports building and running cvc64 from the basic sources on Ubuntu but even trying his executable errors out on my system. Errors like this ... which look very similar to the original source compile errors. I'm a hardware guy but I'm assuming this something silly with libs?

Copyright (c) 1991-2014 Tachyon Design Automation Corp.
All Rights reserved. Licensed software subject to prohibitions and
restrictions. See OSS CVC artistic license included with release.
Today is Thu Jul 27 06:41:24 2017.
Elaborating source file "test_bench.v"
Highest level modules:
test_bench
Compiling module 1 of 1./usr/bin/ld: /tmp/exe-kWxJTG: relocation R_X86_64_32S against symbol __exe_args_str' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/lib-aE0b0b: relocation R_X86_64_32 against .rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /tmp/comm-u28gNb: relocation R_X86_64_32S against undefined symbol __stmt_suspend' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/M0-9y66cc: relocation R_X86_64_32S against symbol __un_p2_svals' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /tmp/comm_nt_m0-FQwE6G: relocation R_X86_64_32S against undefined symbol `__tevdat_0' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

[ShepardSiegel]

Phil, just roll back to Ubuntu 16 and you are good to go. Well, you may need
sudo apt-get install zlib-dev
But other than that, should be off to the races.

[jameyhicks]

Hi Phil,

It turns out the code is not very portable. It uses some inline assembly language that appears to depend on the details of the calling convention, among other things. I'm not sure what changed in the compiler or libraries between Ubuntu 16.04 and 16.10 to break it.

I had enough time to get the code to compile but I don't know the x86 application calling convention well enough to debug it.

[phil94028]

Hi Jamey ...

It was indeed the later versions of Ubuntu that were the problem. The stock Tachyon source builds fine on 16.04, as you suggest. In case it helps anyone else on a stock install, you will need to install zlib1g-dev and also copy hexasm (which is small binary built by the make file) to somewhere like /usr/local/bin and run the make a second time.

[elshera]

Hi All,
Between the several READMEs, there is an incontinence on where to find what in the directory structure. where is the file to check and where are the real binaries. Have anyone seen this ?

[quark17]

I has similar issues on Debian Stretch. The problem is that GCC now uses -pie by default, and to get back to the previous behavior you need to add -no-pie to the GCC command line.

First, I was able to build cvc (cvc64) on Debian Stretch by adding -no-pie to CFLAGS in makefile.cvc (makefile.cvc64):

98c98
< CFLAGS= $(ARCHFLGS) -pipe $(WARNS) $(INCS) $(CVCCFLGS) $(OPTFLGS) -O2 -no-pie
---
> CFLAGS= $(ARCHFLGS) -pipe $(WARNS) $(INCS) $(CVCCFLGS) $(OPTFLGS) -O2 

This works to compile the original cvc source, without the a6125a8 patch.

However, running cvc (cvc64) still gave errors, because it is calling GCC under the covers. So, second, I edited src/v_asmlnk.c to add -no-pie in a few places, and now things work! I don't know if it's needed in both of these places, but here's what I changed:

10059c10059
<  fprintf(fp, "CFLAGS = -no-pie -g -m32\n");
---
>  fprintf(fp, "CFLAGS = -g -m32\n");
10061c10061
<  fprintf(fp, "CFLAGS = -no-pie -g\n");
---
>  fprintf(fp, "CFLAGS = -g\n");
10184c10184
<  sprintf(cmd, "gcc -no-pie -o %s %s %s ", __exe_name, __exe_file_name, 
---
>  sprintf(cmd, "gcc -o %s %s %s ", __exe_name, __exe_file_name, 
10187c10187
<  sprintf(cmd, "gcc -no-pie -O2 -o %s %s %s ", __exe_name, __exe_file_name,
---
>  sprintf(cmd, "gcc -O2 -o %s %s %s ", __exe_name, __exe_file_name,

[jameyhicks]

Awesome! I would be delighted to accept a pull request, or I can make the changes.

[byzantic]

I ran into this problem after upgrading to Ubuntu 18.04. I have also run into similar problems with GHDL.

cvc64 no longer worked, presumably at the stage where it calls GCC, because the default is now to build a PIE. I immediately assumed that I just needed to recompile cvc64 with the latest GCC; of course this just fell over. I tried adding -fPIC into $(CVCCFLAGS), but this didn't help.

A quick search found this repo, many thanks for this, I would never have found the fix in the v_asmlnk file!

BUT .. the compile of cvc64 still fell over. However, just changing the $(CVCCFLAGS) to include -no-pie did the trick!

[jdavid75]

I had this same problem on Linux Mint 19. I tried pulling the branch "asm-reference-fix" and building. This built, but then the executable failed with this output:

OSS_CVC_7.00b-x86_64-rhel6x of 07/07/14 (Linux-elf).
Copyright (c) 1991-2014 Tachyon Design Automation Corp.
All Rights reserved. Licensed software subject to prohibitions and
restrictions. See OSS CVC artistic license included with release.
Today is Thu Jan 3 21:11:41 2019.
Elaborating source file "../../lib/clog2.v"
Elaborating source file "../amp_sim_top_tb.v"
Elaborating source file "../../src/ram_dual.v"
Elaborating source file "../../src/amp_sim_top.v"
../../src/amp_sim_top.v(38) WARN [531] tap_mem(ram_dual) implicit connection list fewer ports 1 in list than type's 9
../../src/amp_sim_top.v(44) WARN [531] kernel_mem(ram_dual) explicit connection list fewer ports 8 connected than type's 9
Highest level modules:
fir_top_tb
../amp_sim_top_tb.v(150) WARN [552] d format but value expression (pos. 1) type real - converted to 32 bit reg
../amp_sim_top_tb.v(277) WARN [552] d format but value expression (pos. 1) type real - converted to 32 bit reg
Compiling module 4 of 4./usr/bin/ld: /tmp/comm-DzTijN: relocation R_X86_64_32S against undefined symbol __stmt_suspend' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: /tmp/M0-PpfFq2: relocation R_X86_64_32S against symbol __un_p2_svals' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /tmp/M1-ho1mZ9: relocation R_X86_64_32S against undefined symbol __tevdat_51' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: /tmp/M2-TVQ5xh: relocation R_X86_64_32S against undefined symbol __tevdat_57' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /tmp/M3-5VEP6o: relocation R_X86_64_32S against undefined symbol __tevdat_59' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: /tmp/comm_nt_m0-14KjEt: relocation R_X86_64_32S against undefined symbol __tevdat_41' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

CVC compilation 0.3 seconds elapsed.

EXECUTABLE SAVED TO 'cvcsim'.

End of OSS_CVC_7.00b-x86_64-rhel6x at Thu Jan 3 21:11:41 2019 (elapsed 0.4 seconds).

So I researched a bit and found this seemingly related link:
https://stackoverflow.com/questions/43367427/32-bit-absolute-addresses-no-longer-allowed-in-x86-64-linux

I switched back to the master branch, and as per the recommendation there, I added "-fno-pie -no-pie" to CVCCFLGS in makefile.cvc64.

On my system this now builds and runs correctly.