Pointer values C not interpreted correctly?

[scippie]

it's rather the -fPIC option that gets you into that mess because it means "individual sections can be moved" rather than the app as a whole which makes it rather braindead for your purposes. It also implies the need for a runtime linker

I should have checked the meaning of all options I had taken over blindly from the wiki.
Thanks Combuster! It works now!

[scippie]

it's rather the -fPIC option that gets you into that mess because it means "individual sections can be moved" rather than the app as a whole which makes it rather braindead for your purposes. It also implies the need for a runtime linker

Although this is IMO exactly what I need, I now have a problem with constants. Constants are defined in the .text segment.
Gcc creates assembly code that is position dependent now, which is good, but when it needs constants, it doesn't know about the start address I am passing to the linker.
So, I have a constant "Hello" at address 0x136, but the code is loaded at 0x1a00 and the linker knows that (but I don't think he has to know anymore), but then the constant is at 0x1b36 while the code is still looking at 0x136.

The options-list of gcc is so huge, I have searched, but have not found, can I tell gcc the start-address of the code?

[Griwes]

You seem to have no idea how a linker works and what it does...

[scippie]

You seem to have no idea how a linker works and what it does...

Well, I thought I did, but it seems that when compiling with gcc without position independant support, the addresses are being fixed at compile time and are not changed at runtime. Is this thought wrong?
And if it is, why aren't my addresses different when disassembling the final binary while I have explicitly set a specific start address, a specific .text, .data and .bss address?

I must admit that using gcc and ld is quite new for me, although I understand the basics. I have always been spoiled by visual studio, borland, and some other systems that take care of these things for me.