Re: [fpc-devel] MacOS Mojave beta - crt1.o not installed to /usr/lib

2018-07-01 Thread Michael Ring
Seems I misunderstood the meaning of "MacOSXVersionMin", it is set to 10.5 on my MacOS Mojave !!??!! So the patch gets even more simple: Index: compiler/systems/t_bsd.pas === --- compiler/systems/t_bsd.pas    (revision 39358) +++

Re: [fpc-devel] MacOS Mojave beta - crt1.o not installed to /usr/lib

2018-07-01 Thread Michael Ring
This small patch helped me to get rid of the need to define -XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ in /etc/fpc.cfg It would be greet to have something similar in the upcoming 3.0.5 release (and of course in trunk) so that also building lazarus with a 3.0.5 compiler works (It

Re: [fpc-devel] MacOS Mojave beta - crt1.o not installed to /usr/lib

2018-07-01 Thread Michael Ring
I only adjusted -Fl to match the current version installed, having a wrong issue there did not change the build behaviour. The change necessary was to include -XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ otherwise fpcmake will not compile. Cross-Compiling did however not work,

Re: [fpc-devel] MacOS Mojave beta - crt1.o not installed to /usr/lib

2018-07-01 Thread Jonas Maebe
On 01/07/18 22:18, Michael Ring wrote: make clean buildbase CPU_TARGET=x86_64 INSTALL_PREFIX=$HOME/3.1.1 FPCOPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/" and patching my /etc/fpc.cfg to include: #ifdef cpui386 -XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/

[fpc-devel] MacOS Mojave beta - crt1.o not installed to /usr/lib

2018-07-01 Thread Michael Ring
We've had this discussion (Jonas and me) a looong time ago (2013) with MacOS Maverics In the past, when xcode commandline tools was installed it created a link to crt1.10.5.o in /usr/lib. It now seems that this is not done anymore (at least not on my computer...) and as /usr/lib is

Re: [fpc-devel] Maximum symbol length -- answer needed

2018-07-01 Thread Florian Klaempfl
Am 01.07.2018 um 20:49 schrieb Jonas Maebe: > On 01/07/18 20:27, Florian Klaempfl wrote: >> Am 23.06.2018 um 10:48 schrieb Jonas Maebe: >>> I doubt this is a major contributor to that fact (especially since >>> implicit exception frames are disabled for the compiler binary, so >>> ansistrings

Re: [fpc-devel] Maximum symbol length -- answer needed

2018-07-01 Thread Jonas Maebe
On 01/07/18 20:27, Florian Klaempfl wrote: Am 23.06.2018 um 10:48 schrieb Jonas Maebe: I doubt this is a major contributor to that fact (especially since implicit exception frames are disabled for the compiler binary, so ansistrings don't result in extra exception frames). I tested on

Re: [fpc-devel] Maximum symbol length -- answer needed

2018-07-01 Thread Florian Klaempfl
Am 23.06.2018 um 10:48 schrieb Jonas Maebe: >> Personally, if I had any stake in this, I would be against it. I mean, >> FPC is already slower than DCC. > > I doubt this is a major contributor to that fact (especially since > implicit exception frames are disabled for the compiler binary, so >

Re: [fpc-devel] Attn. Generics.Collections and rev. 39345 and speed slowdown

2018-07-01 Thread Maciej Izak
2018-06-30 11:03 GMT+02:00 Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org>: > mORMot is a third party project that can be used with FPC while Delphi is > essentially a template and base line for compatibility, so there is a > difference between the two. Though if you have a formal name