Re: [fpc-pascal] Internal error 200706094
How can I rewrite this code to make it correct? I want to use constants to calculate offsets from untyped pointer. You don't have to: http://wiki.freepascal.org/Lazarus_Faq#.27Fatal:_Internal_error_YYZZW.27 so just report and wait for a fix, or fix it yourself if you can then post a patch (unless it's already fixed). You are using development version so a feature break is normal. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Internal-error-200706094-tp5720190p5720201.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
On 29/09/2014 19:30, Reinier Olislagers wrote: Re bug report: agreed. I'll raise it. http://bugs.freepascal.org/view.php?id=26801 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
Reinier Olislagers wrote: On 29/09/2014 19:30, Reinier Olislagers wrote: Re bug report: agreed. I'll raise it. Jonas has already closed it, noting http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583%28v=vs.85%29.aspx *** The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. *** I.e., what you are doing is unsupported (must not call the LoadLibrary or LoadLibraryEx function). I think that on most unix platforms, trying to load libraries from other the init function of other libraries is not supported either. However I'd precede that by a thought based on what Jose said. In your example, you're opening the database in the initialisation block of businesslayer.pas, which is invoked at an arbitrary position in the init sequence of the DLL/so. If that operation were moved instead to the initialisation block of testdbdll.lpr, which in the context of the DLL/so is analogous to a program's main block, it might work. If having the open operation in testdbdll.lpr works but having it in businesslayer.pas doesn't, then it's fair to ask why in the context of FPC (hence my suggestion of a bug report). If neither works, then it's presumably explained by Jonas's note i.e. it's a feature in the context of the library loader. In practice, I still think it's best for the main program to tell the database when and how to initialise, since there's things that it might know about the user's intentions or environment that aren't known by the dynamically-loaded libraries (crude example: you might want to know the compile-time name of the project of which the main program was a part). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
On Tue, 30 Sep 2014, Mark Morgan Lloyd wrote: Reinier Olislagers wrote: On 29/09/2014 19:30, Reinier Olislagers wrote: Re bug report: agreed. I'll raise it. Jonas has already closed it, noting http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583%28v=vs.85%29.aspx *** The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. *** I.e., what you are doing is unsupported (must not call the LoadLibrary or LoadLibraryEx function). I think that on most unix platforms, trying to load libraries from other the init function of other libraries is not supported either. However I'd precede that by a thought based on what Jose said. In your example, you're opening the database in the initialisation block of businesslayer.pas, which is invoked at an arbitrary position in the init sequence of the DLL/so. If that operation were moved instead to the initialisation block of testdbdll.lpr, which in the context of the DLL/so is analogous to a program's main block, it might work. No. this is not correct. For a library, this is analogous to initialization code of a unit, it's just the 'last' unit being initialized. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
Michael Van Canneyt wrote: On Tue, 30 Sep 2014, Mark Morgan Lloyd wrote: Reinier Olislagers wrote: On 29/09/2014 19:30, Reinier Olislagers wrote: Re bug report: agreed. I'll raise it. Jonas has already closed it, noting http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583%28v=vs.85%29.aspx *** The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. *** I.e., what you are doing is unsupported (must not call the LoadLibrary or LoadLibraryEx function). I think that on most unix platforms, trying to load libraries from other the init function of other libraries is not supported either. However I'd precede that by a thought based on what Jose said. In your example, you're opening the database in the initialisation block of businesslayer.pas, which is invoked at an arbitrary position in the init sequence of the DLL/so. If that operation were moved instead to the initialisation block of testdbdll.lpr, which in the context of the DLL/so is analogous to a program's main block, it might work. No. this is not correct. For a library, this is analogous to initialization code of a unit, it's just the 'last' unit being initialized. Does the main program explicitly call the initialisation entry point of the (dynamically-loaded) library, or it this done by the OS? I was under the impression that the two were basically asynchronous and (as a particular example) both the program and the library would have distinct copies of the system unit with their own global variables etc. hence the memory manager problem. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] fpcup: FPC trunk 64-bit for Windows
I downloaded fpcup64.exe from https://bitbucket.org/reiniero/fpcup/downloads After installation everything works well, but the FPC version is 2.6.5. How to update it to FPC trunk? I need it for testing purposes. Regards, Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcup: FPC trunk 64-bit for Windows
On 30/09/2014 14:40, Juha Manninen wrote: After installation everything works well, but the FPC version is 2.6.5. How to update it to FPC trunk? I need it for testing purposes. RTFM... Fix for now (by heart, may be missing something): remove the fpc directory change fpcurl for general all etc sections in settings.ini to the trunk versions (commented out in first section for your convenience) remove the generated lazarus config directory as that points to the old compiler version... easiest just to regenerate it http://wiki.lazarus.freepascal.org/fpcup#Ready_to_run see the Note Make sure you have make 3.82 in your fpcbootstrap dir (e.g. from a Laz 1.2.4 install) Rerun. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
On Tue, 30 Sep 2014, Mark Morgan Lloyd wrote: Michael Van Canneyt wrote: On Tue, 30 Sep 2014, Mark Morgan Lloyd wrote: Reinier Olislagers wrote: On 29/09/2014 19:30, Reinier Olislagers wrote: Re bug report: agreed. I'll raise it. Jonas has already closed it, noting http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583%28v=vs.85%29.aspx *** The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. *** I.e., what you are doing is unsupported (must not call the LoadLibrary or LoadLibraryEx function). I think that on most unix platforms, trying to load libraries from other the init function of other libraries is not supported either. However I'd precede that by a thought based on what Jose said. In your example, you're opening the database in the initialisation block of businesslayer.pas, which is invoked at an arbitrary position in the init sequence of the DLL/so. If that operation were moved instead to the initialisation block of testdbdll.lpr, which in the context of the DLL/so is analogous to a program's main block, it might work. No. this is not correct. For a library, this is analogous to initialization code of a unit, it's just the 'last' unit being initialized. Does the main program explicitly call the initialisation entry point of the (dynamically-loaded) library, or it this done by the OS? I was under the impression that the two were basically asynchronous and (as a particular example) both the program and the library would have distinct copies of the system unit with their own global variables etc. hence the memory manager problem. The memory manager problem is completely unrelated to this. DLL and calling program simply have different copies of the FPC memory manager. That is what needs to be solved with dynamic packages. As far as I know, the initialization entry point is called automatically. But the compiler experts should confirm this. IIRC the behaviour changed as the support for libraries improved; Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcup: FPC trunk 64-bit for Windows
On 30/09/2014 14:49, Reinier Olislagers wrote: On 30/09/2014 14:40, Juha Manninen wrote: After installation everything works well, but the FPC version is 2.6.5. How to update it to FPC trunk? I need it for testing purposes. RTFM... Fix for now (by heart, may be missing something): remove the fpc directory change fpcurl for general all etc sections in settings.ini to the trunk versions (commented out in first section for your convenience) remove the generated lazarus config directory as that points to the old compiler version... easiest just to regenerate it http://wiki.lazarus.freepascal.org/fpcup#Ready_to_run see the Note Make sure you have make 3.82 in your fpcbootstrap dir (e.g. from a Laz 1.2.4 install) Run with fpgui and select the profile you want to run (a full build seems best for the initial run) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
Michael Van Canneyt wrote: However I'd precede that by a thought based on what Jose said. In your example, you're opening the database in the initialisation block of businesslayer.pas, which is invoked at an arbitrary position in the init sequence of the DLL/so. If that operation were moved instead to the initialisation block of testdbdll.lpr, which in the context of the DLL/so is analogous to a program's main block, it might work. No. this is not correct. For a library, this is analogous to initialization code of a unit, it's just the 'last' unit being initialized. Does the main program explicitly call the initialisation entry point of the (dynamically-loaded) library, or it this done by the OS? I was under the impression that the two were basically asynchronous and (as a particular example) both the program and the library would have distinct copies of the system unit with their own global variables etc. hence the memory manager problem. The memory manager problem is completely unrelated to this. DLL and calling program simply have different copies of the FPC memory manager. That is what needs to be solved with dynamic packages. Yes, agreed. Except that if cmem (or whatever) isn't being used there are two completely separate copies of the memory manager because... As far as I know, the initialization entry point is called automatically. But the compiler experts should confirm this. IIRC the behaviour changed as the support for libraries improved; ..(pending comment from compiler experts) there are completely separate trees of units in the main program and each dynamically-loaded library. The OS calls the initialisation block(s) for each library, and then finally calls the initialisation block for the main program. So in the context of one particular library, code in the main library initialisation block should have a similar standing to that in the main program initialisation block: everything else in that context (i.e. in the library or in the main program) has been initialised before it is called, and when it exits it goes back to the OS (possibly via finalisation blocks). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
Am 30.09.2014 15:07 schrieb Mark Morgan Lloyd markmll.fpc-pas...@telemetry.co.uk: As far as I know, the initialization entry point is called automatically. But the compiler experts should confirm this. IIRC the behaviour changed as the support for libraries improved; ..(pending comment from compiler experts) there are completely separate trees of units in the main program and each dynamically-loaded library. The OS calls the initialisation block(s) for each library, and then finally calls the initialisation block for the main program. So in the context of one particular library, code in the main library initialisation block should have a similar standing to that in the main program initialisation block: everything else in that context (i.e. in the library or in the main program) has been initialised before it is called, and when it exits it goes back to the OS (possibly via finalisation blocks). It is indeed true that all units are initialized once the main code block of the library is called, but you are still inside the library initialization initiated by the OS and thus you are subject to its restrictions which in the case of Windows includes not to load any libraries there. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Free Pascal Directories
Having ported a large real-time graphical application from Virtual Pascal (DPMI) to Free Pascal Linux , there is one aspect I haven't managed to overcome. For a number of reasons Lazarus was not used , and Geany is used as the IDE , which works well. Unlike Virtual Pascal which allowed me to put different code in separate directories , Free Pascal seems to want ALL unit files in one huge directory which makes it difficult to keep proper revision control. For example if I decide to use fpGUI , I would like to put all the fpGUI source code into one directory and the actual application (my code) in a separate directory. Any suggestions ? Thanks in advance Brian -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Free-Pascal-Directories-tp5720212.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Directories
On Tue, 30 Sep 2014, Brian wrote: Having ported a large real-time graphical application from Virtual Pascal (DPMI) to Free Pascal Linux , there is one aspect I haven't managed to overcome. For a number of reasons Lazarus was not used , and Geany is used as the IDE , which works well. Unlike Virtual Pascal which allowed me to put different code in separate directories , Free Pascal seems to want ALL unit files in one huge directory which makes it difficult to keep proper revision control. Where did you get this idea from ? For example if I decide to use fpGUI , I would like to put all the fpGUI source code into one directory and the actual application (my code) in a separate directory. Any suggestions ? You can perfectly do this, all my code is scattered over multiple directories. All you need to do is add -Fu options. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Directories
some days before we had same type of thread ... the problem is -Fu is not recursive! Em 30.09.2014 11:07, Michael Van Canneyt escreveu: On Tue, 30 Sep 2014, Brian wrote: Having ported a large real-time graphical application from Virtual Pascal (DPMI) to Free Pascal Linux , there is one aspect I haven't managed to overcome. For a number of reasons Lazarus was not used , and Geany is used as the IDE , which works well. Unlike Virtual Pascal which allowed me to put different code in separate directories , Free Pascal seems to want ALL unit files in one huge directory which makes it difficult to keep proper revision control. Where did you get this idea from ? For example if I decide to use fpGUI , I would like to put all the fpGUI source code into one directory and the actual application (my code) in a separate directory. Any suggestions ? You can perfectly do this, all my code is scattered over multiple directories. All you need to do is add -Fu options. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal [1] Links: -- [1] 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] Free Pascal Directories
On Tue, 30 Sep 2014, Philippe wrote: some days before we had same type of thread ... the problem is -Fu is not recursive! And luckily not. The result would be a disaster ! However, you can use wildcards: -Fu/home/some/dir/* Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcup: FPC trunk 64-bit for Windows
On Tue, Sep 30, 2014 at 4:01 PM, Reinier Olislagers reinierolislag...@gmail.com wrote: Run with fpgui and select the profile you want to run (a full build seems best for the initial run) I did a new build with fpcup64.exe --fpcURL=trunk and it works very well. This is quite a big tool already. Lots of options and features. Cool! Regards, Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcup: FPC trunk 64-bit for Windows
On 30/09/2014 17:01, Juha Manninen wrote: On Tue, Sep 30, 2014 at 4:01 PM, Reinier Olislagers reinierolislag...@gmail.com wrote: Run with fpgui and select the profile you want to run (a full build seems best for the initial run) I did a new build with fpcup64.exe --fpcURL=trunk and it works very well. Good to hear that. This is quite a big tool already. Lots of options and features. Cool! Mmmm yeah, thanks. That's both a plus and a minus: many options is also very confusing At least out of the box it gets you a working FPC+Laz but once you want something else you still have to dig. Suggestions for streamlining (fpcupgui etc) more than welcome. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Directories
On 30 September 2014 16:27, Philippe phili...@quarta.com.br wrote: some days before we had same type of thread ... the problem is -Fu is not recursive! We're programmers. Creating our own tools for mundane work is not a problem :-) A few year back at my old company, for Delphi work we developed a small helper app. We gave it a root folder, it gave us back a string containing all sub-folders in a format suitable for pasting into required Library Paths (going via a intermediate listbox so we could exclude any subfolders we didn't want - we had folders for docs for instance). Only needed this app when configuring a new install of Delphi. Shouldn't take you long to generate a similar app for automating a string for -Fu. :-) Mike (one of the other ones) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcup: FPC trunk 64-bit for Windows
On 30 September 2014 17:01, Juha Manninen juha.mannine...@gmail.com wrote: On Tue, Sep 30, 2014 at 4:01 PM, Reinier Olislagers reinierolislag...@gmail.com wrote: Run with fpgui and select the profile you want to run (a full build seems best for the initial run) I did a new build with fpcup64.exe --fpcURL=trunk and it works very well. This is quite a big tool already. Lots of options and features. Cool! In the forums, this is great for dealing with all those but the snapshots don't work anymore... :-) Mike ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
In our previous episode, Sven Barth said: It is indeed true that all units are initialized once the main code block of the library is called, but you are still inside the library initialization initiated by the OS and thus you are subject to its restrictions which in the case of Windows includes not to load any libraries there. So the obvious question might be if the unit initialization really belongs into the library initialization like that. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
On 30.09.2014 20:17, Marco van de Voort wrote: In our previous episode, Sven Barth said: It is indeed true that all units are initialized once the main code block of the library is called, but you are still inside the library initialization initiated by the OS and thus you are subject to its restrictions which in the case of Windows includes not to load any libraries there. So the obvious question might be if the unit initialization really belongs into the library initialization like that. The only other alternative would be to add the RTL initialization code to each exported function. I don't consider this a viable alternative. Note: Dynamic packages won't have this problem, because: - for packages linked at compile time the initialization is run as part of the program initialization AFTER the OS has initialized the library (which doesn't do much in case of a package) - for packages loaded at runtime it's done as part of the LoadPackage call That's however only possible, because dynamic packages are very different from simple libraries (and stuffed with compiler magic). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Directories
On 30.09.2014 16:27, Philippe wrote: some days before we had same type of thread ... the problem is -Fu is not recursive! That's not what Brian asked for. He asked whether he can use multiple directories, not whether he can use them recursively. And the former is definitely the case. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
Marco van de Voort wrote: In our previous episode, Sven Barth said: It is indeed true that all units are initialized once the main code block of the library is called, but you are still inside the library initialization initiated by the OS and thus you are subject to its restrictions which in the case of Windows includes not to load any libraries there. So the obvious question might be if the unit initialization really belongs into the library initialization like that. Assuming that e.g. connecting to a database uses the Dynlibs unit, is there any way that this could recognise that it was being invoked from DLL/so initialisation code and raise a don't try that here exception? Reinier: did you get as far as looking in Dynlibs for an error message immediately after trying to connect to the database? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
Sven Barth wrote: The only other alternative would be to add the RTL initialization code to each exported function. I don't consider this a viable alternative. Which is more or less what Reinier's working code did. I'd hate that to be an implicit default. Note: Dynamic packages won't have this problem, because: - for packages linked at compile time the initialization is run as part of the program initialization AFTER the OS has initialized the library (which doesn't do much in case of a package) - for packages loaded at runtime it's done as part of the LoadPackage call That's however only possible, because dynamic packages are very different from simple libraries (and stuffed with compiler magic). Is it possible for code in a unit to determine what sort of project it's part of, i.e. a standalone program, a library etc.? Could the RTL have a flag indicating that initialisation (or finalisation?) blocks were currently being run, and anything called should assume that facilities were restricted? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Directories
That's not what Brian asked for. He asked whether he can use multiple directories, not whether he can use them recursively. And the former is definitely the case. And indeed it's a disaster, because you might to restructure your units directory if it works recursively depending on how you layout it. Example: If under the same directory you have units for all targets you want to support, it's a hell after -Fu works recursively. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Free-Pascal-Directories-tp5720212p5720226.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reproducible code: DLL calling Firebird crashes
On 30/09/2014 22:05, Mark Morgan Lloyd wrote: Marco van de Voort wrote: In our previous episode, Sven Barth said: It is indeed true that all units are initialized once the main code Reinier: did you get as far as looking in Dynlibs for an error message immediately after trying to connect to the database? No, I didn't. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
