date:20180701

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)
+++ compiler/systems/t_bsd.pas    (working copy)
@@ -377,7 +377,10 @@
   if startupfile<>'' then
 begin
  if not librarysearchpath.FindFile(startupfile,false,result) then
-   result:='/usr/lib/'+startupfile
+   if sysutils.fileexists('/usr/lib/'+startupfile) then
+ result:='/usr/lib/'+startupfile
+   else if 
sysutils.fileexists('/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile) 
then
+ 
result:='/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile

 end
   else
 result:='';



Am 01.07.18 um 23:31 schrieb 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 currently fails without the entry in fpc.cfg)



Michael


Index: compiler/systems/t_bsd.pas
===
--- compiler/systems/t_bsd.pas    (revision 39358)
+++ compiler/systems/t_bsd.pas    (working copy)
@@ -248,6 +248,9 @@
 system_i386_darwin,
 system_x86_64_darwin:
   begin
+    { 10.14 and later: crt1.o }
+    if CompareVersionStrings(MacOSXVersionMin,'10.14')>=0 
then

+  exit('crt1.so');
 { 10.8 and later: no crt1.* }
 if CompareVersionStrings(MacOSXVersionMin,'10.8')>=0 
then

   exit('');
@@ -377,7 +380,10 @@
   if startupfile<>'' then
 begin
  if not librarysearchpath.FindFile(startupfile,false,result) then
-   result:='/usr/lib/'+startupfile
+   if sysutils.fileexists('/usr/lib/'+startupfile) then
+ result:='/usr/lib/'+startupfile
+   else if 
sysutils.fileexists('/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/usr/lib/'+startupfile) 
then
+ 
result:='/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile

 end
   else
 result:='';


Am 01.07.18 um 22:52 schrieb 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, the makefile of fpcmake does 
seem to support FPCOPT but somehow the parameter does not get 
forwarded to the makefile:


/Library/Developer/CommandLineTools/usr/bin/make -C utils/fpcm 
bootstrap FPC=/Users/ring/devel/fpc-arm/compiler/ppcrossarm 
FPCFPMAKE=/Users/ring/devel/fpc-arm/compiler/ppc RELEASE=1 'OPT='


results in:

/Users/ring/devel/fpc-arm/compiler/ppc fpcmake.pp -n 
-Fu/Users/ring/devel/fpc-arm/rtl/units/x86_64-darwin 
-FU/Users/ring/devel/fpc-arm/utils/fpcm/units/x86_64-darwin

ld: file not found: /usr/lib/crt1.10.5.o
An error occurred while linking

I could make crosscompiling work by doing this (Use OPT instead of 
FPCOPT)


make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm 
SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi- 
OPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/"


I hope that hardcoding the path 
/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/ in FPC will 
solve this.


Thank you,

Michael



Am 01.07.18 um 22:34 schrieb 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/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif
#ifdef cpux86_64
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif

both actions were needed for a successful compile...


What errors do you get if you don't include the -Fl option?


Is there a better way to make compiles work on Mojave?


The -XR above seems to be the correct way to handle this change. We 
could also hard code that search path in the compiler in addition to 
/usr/lib



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel mai

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 currently fails without the entry in fpc.cfg)



Michael


Index: compiler/systems/t_bsd.pas
===
--- compiler/systems/t_bsd.pas    (revision 39358)
+++ compiler/systems/t_bsd.pas    (working copy)
@@ -248,6 +248,9 @@
 system_i386_darwin,
 system_x86_64_darwin:
   begin
+    { 10.14 and later: crt1.o }
+    if CompareVersionStrings(MacOSXVersionMin,'10.14')>=0 then
+  exit('crt1.so');
 { 10.8 and later: no crt1.* }
 if CompareVersionStrings(MacOSXVersionMin,'10.8')>=0 then
   exit('');
@@ -377,7 +380,10 @@
   if startupfile<>'' then
 begin
  if not librarysearchpath.FindFile(startupfile,false,result) then
-   result:='/usr/lib/'+startupfile
+   if sysutils.fileexists('/usr/lib/'+startupfile) then
+ result:='/usr/lib/'+startupfile
+   else if 
sysutils.fileexists('/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/usr/lib/'+startupfile) 
then
+ 
result:='/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile

 end
   else
 result:='';


Am 01.07.18 um 22:52 schrieb 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, the makefile of fpcmake does 
seem to support FPCOPT but somehow the parameter does not get 
forwarded to the makefile:


/Library/Developer/CommandLineTools/usr/bin/make -C utils/fpcm 
bootstrap FPC=/Users/ring/devel/fpc-arm/compiler/ppcrossarm 
FPCFPMAKE=/Users/ring/devel/fpc-arm/compiler/ppc RELEASE=1 'OPT='


results in:

/Users/ring/devel/fpc-arm/compiler/ppc fpcmake.pp -n 
-Fu/Users/ring/devel/fpc-arm/rtl/units/x86_64-darwin 
-FU/Users/ring/devel/fpc-arm/utils/fpcm/units/x86_64-darwin

ld: file not found: /usr/lib/crt1.10.5.o
An error occurred while linking

I could make crosscompiling work by doing this (Use OPT instead of 
FPCOPT)


make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm 
SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi- 
OPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/"


I hope that hardcoding the path 
/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/ in FPC will 
solve this.


Thank you,

Michael



Am 01.07.18 um 22:34 schrieb 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/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif
#ifdef cpux86_64
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif

both actions were needed for a successful compile...


What errors do you get if you don't include the -Fl option?


Is there a better way to make compiles work on Mojave?


The -XR above seems to be the correct way to handle this change. We 
could also hard code that search path in the compiler in addition to 
/usr/lib



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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, the makefile of fpcmake does seem 
to support FPCOPT but somehow the parameter does not get forwarded to 
the makefile:


/Library/Developer/CommandLineTools/usr/bin/make -C utils/fpcm bootstrap 
FPC=/Users/ring/devel/fpc-arm/compiler/ppcrossarm 
FPCFPMAKE=/Users/ring/devel/fpc-arm/compiler/ppc RELEASE=1 'OPT='


results in:

/Users/ring/devel/fpc-arm/compiler/ppc fpcmake.pp -n 
-Fu/Users/ring/devel/fpc-arm/rtl/units/x86_64-darwin 
-FU/Users/ring/devel/fpc-arm/utils/fpcm/units/x86_64-darwin

ld: file not found: /usr/lib/crt1.10.5.o
An error occurred while linking

I could make crosscompiling work by doing this (Use OPT instead of FPCOPT)

make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm 
SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi- 
OPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/"


I hope that hardcoding the path 
/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/ in FPC will solve 
this.


Thank you,

Michael



Am 01.07.18 um 22:34 schrieb 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/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif
#ifdef cpux86_64
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif

both actions were needed for a successful compile...


What errors do you get if you don't include the -Fl option?


Is there a better way to make compiles work on Mojave?


The -XR above seems to be the correct way to handle this change. We 
could also hard code that search path in the compiler in addition to 
/usr/lib



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif
#ifdef cpux86_64
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif

both actions were needed for a successful compile...


What errors do you get if you don't include the -Fl option?


Is there a better way to make compiles work on Mojave?


The -XR above seems to be the correct way to handle this change. We 
could also hard code that search path in the compiler in addition to 
/usr/lib



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[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 write protected for root in newer 
versions of MacOSX it is not that easy to create a link by hand.


The good news is that

clang -print-search-dirs

programs: =/Library/Developer/CommandLineTools/usr/bin
libraries: =/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0

returns a libraries path that helps finding a valid crt1.(10.5).o file:

find /Library/Developer/CommandLineTools/ -name "crt1*"
/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/usr/lib/crt1.o
/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/usr/lib/crt1.10.5.o
/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/usr/lib/crt1.10.6.o

I managed to get a successful compile by doing this:

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/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif
#ifdef cpux86_64
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif


both actions were needed for a successful compile...


Is there a better way to make compiles work on Mojave?


Michael






___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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 don't result in extra exception frames).
>>
>> I tested on x86_64-linux and the increase is around 10 % for make cycle.
>> So it cannot be neglected imo.
> 
> Many compiler helpers still use "string" or "shortstring"
> parameters/results/local variables, so there are still quite a few type
> conversions going on from shortstring to ansistring.

Yes, but this needs to be profiled in detail.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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 x86_64-linux and the increase is around 10 % for make cycle.
So it cannot be neglected imo.


Many compiler helpers still use "string" or "shortstring" 
parameters/results/local variables, so there are still quite a few type 
conversions going on from shortstring to ansistring.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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
> ansistrings don't result in extra exception frames).

I tested on x86_64-linux and the increase is around 10 % for make cycle.
So it cannot be neglected imo.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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 for the hash
> that Delphi uses we can change that as well :P
>

TDelphi*HashFactory is not required for compatibility with Delphi (as many
other things in rtl-generic). Correct name for this hash is "BobJenkins"
(Delphi has special slightly modified version of HashLittle which in Delphi
is called BobJenkins - don't ask :P). I will fix all hash names where
"Delphi" word exist.

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

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

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

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

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

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

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

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

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

9 matches

Site Navigation

Mail list logo

Footer information