Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2014-11

Mixing PIC non-PIC code/variables when linking a shared library

9 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Dmitry Boyarintsev

Hello Fpc-developers,

Why would a global variable cause an issue when linking a shared library (specifically 64-bit linux)?
The more detailed description is here:
http://bugs.freepascal.org/view.php?id=17412

Linker fails to generate an .SO file complaining about a bad code generated for:
TC_RICHMEMO_RTFLOADSTREAM
Where RTFLoadStream is declared as:
var
RTFLoadStream : function (AMemo: TCustomRichMemo; Source: TStream): Boolean = nil;
The variable doesn't seem to be exported by the library in any way. Are global variables treated in some special manner when generating shared library?

To add to that. RichMemo comes as Lazarus package. Thus object files for it are compiled without -fPIC flag set, by default. However, it's possible to recompile the page with -fPIC flag later (that should resolve the issue named in the bug report)

thanks,
Dmitry

Reply by email

Jonas Maebe
to Dmitry Boyarintsev
Dmitry Boyarintsev wrote 12 lines
Linker fails to generate an .SO file complaining about a bad code generated for: TC_RICHMEMO_RTFLOADSTREAM Where RTFLoadStream is declared as: var RTFLoadStream : function (AMemo: TCustomRichMemo; Source: TStream): Boolean = nil; The variable doesn't seem to be exported by the library in any way. Are global variables treated in some special manner when generating shared library?

All global data, exported or not, need special code to be accessed in a position-independent way on most targets (including x86-64).

Jonas

Reply by email

Dmitry Boyarintsev
to Jonas Maebe
Jonas Maebe wrote
All global data, exported or not, need special code to be accessed in a position-independent way on most targets (including x86-64).

Thanks for clarification.

So based on the bug report description: "There is no problem with other LCL components"
I guess LCL itself was compiled with PIC flag as well (though, not mentioned in the report).

thanks,
Dmitry

Reply by email

Jonas Maebe
to Dmitry Boyarintsev

Dmitry Boyarintsev wrote on ma, 17 nov 2014:

So based on the bug report description: "There is no problem with other LCL components" I guess LCL itself was compiled with PIC flag as well (though, not mentioned in the report).

Yes, fpcmake automatically adds -Cg/-fPIC for x86-64 platforms, exactly because of this issue.

Jonas

Reply by email

Dmitry Boyarintsev
to Jonas Maebe
Jonas Maebe wrote
Yes, fpcmake automatically adds -Cg/-fPIC for x86-64 platforms, exactly because of this issue.

Aha... now it makes sense. Lazarus and LCL itself are products of fpcmake, while Lazarus packages are not.
This has to be addressed in Lazarus packaging system.

thanks,
Dmitry

Reply by email

Mattias Gaertner
to Jonas Maebe: Dmitry Boyarintsev wrote on ma, 17 nov 2014: Yes, fpcmake automatically adds -Cg/-fPIC…
Show quoted text 10 lines
Dmitry Boyarintsev wrote on ma, 17 nov 2014: > So based on the bug report description: "There is no problem with other LCL > components" > I guess LCL itself was compiled with PIC flag as well (though, not > mentioned in the report). Yes, fpcmake automatically adds -Cg/-fPIC for x86-64 platforms, exactly because of this issue.

Does "automatically" means here "always on x86_64"?

Mattias

Reply by email

Jonas Maebe
to Mattias Gaertner
Mattias Gaertner wrote 7 lines
On Mon, 17 Nov 2014 16:13:40 +0100 Jonas Maebe wrote: > Yes, fpcmake automatically adds -Cg/-fPIC for x86-64 platforms, > exactly because of this issue. Does "automatically" means here "always on x86_64"?

Yes, but "x86-64" is apparently bit too broad:
* it's added for x86-64/(freebsd, openbsd, netbsd, linux, solaris)
* for Darwin, -Cg is always on by default on all platforms, but this is done in the compiler itself (because it's also on by default in the system compilers)

Jonas

Reply by email

Mattias Gaertner
to Jonas Maebe
Show quoted text 6 lines
[...] Yes, but "x86-64" is apparently bit too broad: * it's added for x86-64/(freebsd, openbsd, netbsd, linux, solaris) * for Darwin, -Cg is always on by default on all platforms, but this is done in the compiler itself (because it's also on by default in the system compilers)

Thanks. I will add it to Lazarus.
Why does the compiler not always add -Cg on Linux/x86-64?

Mattias

Reply by email

Jonas Maebe
to Mattias Gaertner
Mattias Gaertner wrote 13 lines
On Tue, 18 Nov 2014 11:03:03 +0100 Jonas Maebe wrote: > [...] > Yes, but "x86-64" is apparently bit too broad: > * it's added for x86-64/(freebsd, openbsd, netbsd, linux, solaris) > * for Darwin, -Cg is always on by default on all platforms, but this > is done in the compiler itself (because it's also on by default in > the > system compilers) Thanks. I will add it to Lazarus. Why does the compiler not always add -Cg on Linux/x86-64?

Because the system compilers (gcc/clang) don't do so either.

Jonas

Reply by email