On 18 Nov 2014, at 11:31, Mattias Gaertner wrote:
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
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'
On 18 Nov 2014, at 00:09, Mattias Gaertner wrote:
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 t
On Mon, 17 Nov 2014 16:13:40 +0100
Jonas Maebe wrote:
>
> 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 re
On Mon, Nov 17, 2014 at 10:13 AM, 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 Lazar
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,
e
On Mon, Nov 17, 2014 at 2:51 AM, 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
co
On 17 Nov 2014, at 05:04, Dmitry Boyarintsev wrote:
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 variab
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_RICHM
