How to Compile: Unrecognized Relocation

unable to compile: unrecognized relocation 0x2a in section text

Relocation 42 on x86-64 is R_X86_64_REX_GOTPCRELX. These relocations are used for optimizations implemented in binutils 2.26 and later.

You will either need to upgrade your binutils version, or re-compile the library you want to use with your current toolchain version.

Centos 7 with custom built GLFW binary /usr/bin/ld: /usr/local/lib/libglfw3.a(init.c.o): unrecognized relocation (0x2a) in section `.text'

Wow, this has to do with a frustrating on going problem Centos 7 has... Centos 7 had such an old version of g++ I was forced to use dev-toolset-6 in order to get a modern version of g++ ie one that supported c++14. This was unrelated to the current project (which I clearly was using c++11 with) but the thing about Clion is that by default it uses uses the g++/gcc/gmake version found in /usr/bin/ which is not where the g++ 6.2.1 version is located.

I had already fixed this issue with projects that used C++14, go into settings for the project you want, and paste the following line in CMake options underneath Build, Execution, Deployment:

-D CMAKE_CXX_COMPILER=/opt/rh/devtoolset-6/root/usr/bin/g++ -D CMAKE_C_COMPILER=/opt/rh/devtoolset-6/root/usr/bin/gcc

This is the correct location of g++ now. Of course I could do some symbolic linking to fix it, but I had previously assumed that my solution to finding the correct version in terminal (modifying .bashrc) would work for clion as well.

When I tested c++14 features on a whim it was clear this didn't work.

Now why this was an issue? I was using two very different versions of g++/gcc, I used g++/gcc 6.2.1 to compile my GLFW, and used 4.7 or something to compile my actual program. That is why I was getting this strange error.

Note that this only fixes the odd .txt issue, my cmake file was also incorrect, as I forgot to target Xcursor. The new cmake file now looks like this:

cmake_minimum_required(VERSION 3.7)
project(opengltest)

set(CMAKE_CXX_STANDARD 11)
include_directories("include/")
set(SOURCE_FILES main.cpp glad.c)
add_executable(opengltest ${SOURCE_FILES})
target_link_libraries(opengltest -L/usr/local/lib -lglfw3 -pthread -lGLU -lGL -lrt -lX11 -lXrandr -lXinerama -lXi -lXxf86vm -lXcursor -ldl)

And I now have no errors (well I still git that odd warning with clock skew, I just assume there's something wrong with GLAD websystem)

MASM error Unknown relocation type (1) with 16b code

The MASM32 package doesn't come with support for 16-bit executable generation, although it's not difficult to alter this behaviour. The MASM assembler in the MASM32 package will generate 16-bit code but the linkers supplied will not generate 16-bit executables. This results in the type of error(s) you are seeing.

You can download a copy of an older linker that supports 16-bit targets. I've made link16.exe (version 5.60.339 Dec 5 1994) available for download on my server.

Place link16.exe into the \masm32\bin directory. You will have to modify the generated makeit.bat file. The line that calls the linker (like link.exe or polink.exe) has to be replaced with:

\masm32\bin\link16.exe "filename.obj" ;

filename.obj is the name of the file you want to link. Change it to suit your project. The semicolon on the end will default all the file names and won't prompt for them. You will then have to modify the the ml line in makeit.bat so that it doesn't produce coff files. To do that remove /coff option:

\masm32\bin\ml /c "filename.asm"

Again filename.asm can be replaced by the name of the file in your project.

Other Observations

Once you are able to generate a 16-bit executable some issues with your code:

Remove stack db 100 dup(?) and use the .stack directive instead
```
.stack 100h
```
You need to set up the segment value of MSG in DS instead:
```
mov ax, seg MSG
mov ds, ax 
```
With the .small model there is only one data segment. In the .small model .data and .data? will be combined into a single .data segment. With this memory model you can also initialize DS this way:
```
mov ax, @data
mov ds, ax
```
For an DOS EXE program you'll need to exit with something like the DOS exit interrupt
```
mov ax, 4c00h
int 21h
```

If you are using MASM32 on a 64-bit version of Windows you wil not be able to directly run the 16-bit applications you create. You will have to download an emulator like DOSBox to run it, or install Virtual Machine (VMWare, VirtualBox, QEMU etc) software with a version of DOS/Windows that can run the code.

Hello world kernel module for android & unknown relocation: 27 when insmod

It turns out I had to use

make CFLAGS_MODULE=-fno-pic

Relocation Error when Inserting External Cross-Compiled SPARC Linux Module

I have exactly the same problem with my own module, for a Leon-Linux configuration (linuxbuild-1.0.1).

What I did is that I moved the 'case R_SPARC_DISP32' portion of code (the 4 lines) just after the line '#endif /* CONFIG_SPARC64 */'

That's some bad hack Harry ;-) but at least I can now insmod the module...
Now I need to look for side-effects on the user-land side, when apps call the routines of the module.

So, to be continued...

Best regards,
Karim