Re: [fpc-pascal] MacOSX Mojave
On 08/10/18 23:19, Michael Ring wrote: I just realized on a freshly set up computer that there is one more issue, I tried to build the trunk x86_64 compiler and compile fails: /bin/mkdir -p x86_64/units/x86_64-darwin /Applications/Xcode.app/Contents/Developer/usr/bin/make ./msg2inc /usr/local/bin/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/Users/ring/devel/fpc/rtl/units/x86_64-darwin -Fix86_64 -FE. -FUx86_64/units/x86_64-darwin -dRELEASE -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp ld: file not found: /usr/lib/crt1.10.5.o An error occurred while linking msg2inc.pp(822,51) Error: Error while linking msg2inc.pp(822,51) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted problem is that ppcx64 is called with option -n so fpc.cfg gets ignored. I guess the only way to fix this is to change the makefile itself. As Colin mentioned, you can pass the necessary options to make via OPT="-option1 -option2" Also, one thing I do not understand in /etc/fpc.cfg installed by the 3.0.4a installer, why if -Fl ifdef'ed for i386 only? #ifdef cpui386 -Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib #endif It's because the necessary files for x86-64 can be found in /usr/lib, where the compiler looks by default. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Listing the type (even as string) of the parameters and the return of a function
On Mon, Oct 8, 2018 at 6:21 AM Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > Short answer: No. > > Long answer: No. The extended RTTI required for that is currently only > generated for interfaces with $M+ set. > > Regards, > Sven > Hi Sven, thanks for replying. What are the challenges to implement this feature? (Besides changes in the current ABI, new types in the typinfo etc.) I'm busy developing a library for the company, but, after that, I would like to contribute the assembly on invoke.inc for x86/ARM (32-bit only). -- Silvio Clécio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MacOSX Mojave
Until now you could compile trunk without such specific opts, so making OPT= something mandatory for future builds of trunk to work at all does not sound like a good plan to me. and no, at least in my installation there are no crt1* files in /usr/lib, if there were any we would not have this discussion here ;-) I am not trying to solve something for myself, my own builds are working for quite a long time on Mojave, just wanted to make sure that compiling trunk keeps as straightforward as ever Michael Am 09.10.18 um 19:51 schrieb Jonas Maebe: On 08/10/18 23:19, Michael Ring wrote: I just realized on a freshly set up computer that there is one more issue, I tried to build the trunk x86_64 compiler and compile fails: /bin/mkdir -p x86_64/units/x86_64-darwin /Applications/Xcode.app/Contents/Developer/usr/bin/make ./msg2inc /usr/local/bin/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/Users/ring/devel/fpc/rtl/units/x86_64-darwin -Fix86_64 -FE. -FUx86_64/units/x86_64-darwin -dRELEASE -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp ld: file not found: /usr/lib/crt1.10.5.o An error occurred while linking msg2inc.pp(822,51) Error: Error while linking msg2inc.pp(822,51) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted problem is that ppcx64 is called with option -n so fpc.cfg gets ignored. I guess the only way to fix this is to change the makefile itself. As Colin mentioned, you can pass the necessary options to make via OPT="-option1 -option2" Also, one thing I do not understand in /etc/fpc.cfg installed by the 3.0.4a installer, why if -Fl ifdef'ed for i386 only? #ifdef cpui386 -Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib #endif It's because the necessary files for x86-64 can be found in /usr/lib, where the compiler looks by default. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MacOSX Mojave
On 09/10/18 21:06, Michael Ring wrote: Until now you could compile trunk without such specific opts, so making OPT= something mandatory for future builds of trunk to work at all does not sound like a good plan to me. I committed a fix that could be merged to 3.0.4 without having to change the compiler, in order to minimise the chances of introducing any bugs in an existing release. Maybe I'll hardcode new paths in the compiler as well, but hardcoding new paths in the compiler every couple of new macOS releases is not a good plan either. and no, at least in my installation there are no crt1* files in /usr/lib, if there were any we would not have this discussion here ;-) There indeed are none, that is why for x86-64 there is a -XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk option in fpc.cfg. That does not work for i386, because the libraries in that SDK don't contain i386 versions. Only the versions installed as part of the operating systems do (but the crt1.o file for i386 is only there, hence the -Fl statement for that architecture). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Listing the type (even as string) of the parameters and the return of a function
silvioprog schrieb am Di., 9. Okt. 2018, 19:56: > On Mon, Oct 8, 2018 at 6:21 AM Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > >> Short answer: No. >> >> Long answer: No. The extended RTTI required for that is currently only >> generated for interfaces with $M+ set. >> >> Regards, >> Sven >> > > Hi Sven, thanks for replying. > > What are the challenges to implement this feature? (Besides changes in the > current ABI, new types in the typinfo etc.) > The main challenge is to find the time and motivation to implement the whole extended RTTI shenanigans. Though I hope that after my birthday this weekend I'll find the time to work on this as well as finish the support for dynamic packages. > I'm busy developing a library for the company, but, after that, I would > like to contribute the assembly on invoke.inc for x86/ARM (32-bit only). > Feel free to contribute here. A x64 SysV variant would be welcome as well. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GLPT v0.1.1 released
> On Oct 9, 2018, at 12:19 PM, Ingemar Ragnemalm wrote: > > All your demos are old-style. I can't even see a single shader anywhere. I > think you should use modern OpenGL more. For instance, I have made a modern > version of the dear old Gears demo: There’s not even a way to switch the OpenGL version yet so the project is effectively not ready for use (it’s stuck on 2.1 on OS X for example). I suggest he just adds a record to the parameters when creating a window for the simplest solution. SDL uses a constants and setter/getter functions but a simple record is better. type GLPT_Context = record doubleBuffer: boolean; colorSize: byte; depthSize: byte; stencilSize: byte; profile: byte; minorVersion: byte; majorVersion: byte; end; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GLPT v0.1.1 released
Setting the OpenGl version is on top of my list. I 'm no expert but I will make the changes accordingly, counting on feedback from you all. Rgds, Darius On Wed, Oct 10, 2018 at 6:08 AM Ryan Joseph wrote: > > > > On Oct 9, 2018, at 12:19 PM, Ingemar Ragnemalm > wrote: > > > > All your demos are old-style. I can't even see a single shader anywhere. > I think you should use modern OpenGL more. For instance, I have made a > modern version of the dear old Gears demo: > > There’s not even a way to switch the OpenGL version yet so the project is > effectively not ready for use (it’s stuck on 2.1 on OS X for example). > > I suggest he just adds a record to the parameters when creating a window > for the simplest solution. SDL uses a constants and setter/getter functions > but a simple record is better. > > type > GLPT_Context = record > doubleBuffer: boolean; > colorSize: byte; > depthSize: byte; > stencilSize: byte; > profile: byte; > minorVersion: byte; > majorVersion: byte; > end; > > > Regards, > Ryan Joseph > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
