-1

The full error the console is handing back to me is below. I'm using Lubuntu on VirtualBox and VMware (tried both). For some reason it works on my laptop but not on my desktop. After trying to find out more myself through many message forums it seems like something might be wrong with ld itself on my system but I'm not skilled enough to figure out what's going wrong. I know "1 exit status" means failure but that's about it. I don't know why it's failing. Has nothing to do with my code if it'll run on one machine and not the other.

The language I'm programming in is Assembly using the YASM compiler. The script for compilation is linked below the error code

Error code:

/usr/bin/ld: funcs.o: relocation R_X86_64_32 against `.data' 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

Compiling script:

g++ -g -c $1.cpp -lglut -lGLU -lGL -lm
yasm -g dwarf2 -f elf64 $2.asm -l $2.lst
g++ -g -o $1 $1.o $2.o -lglut -lGLU -lGL -lm

Note that while the above script is slightly more complicated, a simple script such as the one below will not work either.

yasm -g dwarf2 -f elf64 $1.asm
yasm -g dwarf2 -f elf64 $2.asm
gcc -g -o $1 $1.o $2.o
Nick Graeff
  • 89
  • 1
  • 7
  • 1
    What is "funcs.o", is that from your source? Looks like you are using absolute address in 64b mode of some symbol, this can't be done with shared library, so you can either rewrite the "funcs" to use relative `rip` addressing in PIC style, or as a quick dirty fix it MAY be enough to put `-static` to linker, so all those libraries will go into executable (this is disliked practice in linux world, as that makes your binary forever tied to the version of libs, which it was linked against, so such binary would have hard time to get into any official repository). – Ped7g Mar 07 '17 at 03:46
  • Some hint about PIC style of asm (but for NASM): http://stackoverflow.com/a/12061900/4271923 – Ped7g Mar 07 '17 at 03:48
  • I really just need this thing to work. Where should I put static, in what order of the arguments? I have close to no idea what I'm doing here so what you were saying about rip addressing I don't follow at all. Does the fact that this will link and load perfectly fine on my laptop mean anything? – Nick Graeff Mar 07 '17 at 04:03
  • @Ped7g I fixed it. My version of linux was 16.04 so I rolled back to 14.04. Not sure what the problem was and don't really care at this point. – Nick Graeff Mar 07 '17 at 04:29
  • *" Does the fact that this will link and load perfectly fine on my laptop mean anything?"* depends... for your personal use? Perfect, enjoy while it lasts. For distribution among other users... probably not good enough already, but don't worry about that, any binary-distributed SW is dead/zombie from the day 1. Only SW distributed as source may live a bit longer. Although considering the mankind progress and time scales involved, will take at least another millennium to evaluate this properly, maybe the whole "SW by humans" thing is small 200-300y episode. – Ped7g Mar 07 '17 at 04:39
  • Any chance you are using 16.10 on one and 16.04 on the other? – Michael Petch Mar 07 '17 at 09:18

1 Answers1

-1

The solution to this problem was to switch from Lubuntu 16.10 to Lubuntu 14.04. The program ended up working fine on my system on that version. Not sure what the source of the error was beyond that.

Nick Graeff
  • 89
  • 1
  • 7
  • Can you do us a favor and show us your funcs.asm code. – Michael Petch Mar 10 '17 at 14:41
  • I installed a fresh Lubuntu 16.04 Distro (upgraded all the packages), cloned your git repository and used your `sh` script to generate an executable. It worked. – Michael Petch Mar 11 '17 at 17:57
  • To work around this on 16.10 you'd have to make the assembly position independent or maybe easier is on the **linker** line build the executable with `-no-pie` option. So try `g++ -g -o $1 $1.o $2.o -lglut -lGLU -lGL -lm -no-pie` – Michael Petch Mar 12 '17 at 01:32