On Thu, 2 Oct 2014, Reinier Olislagers wrote:
On 02/10/2014 12:19, Mark Morgan Lloyd wrote:
Reinier Olislagers wrote:
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
On 02/10/2014 12:19, Mark Morgan Lloyd wrote:
> Reinier Olislagers wrote:
>> 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
Reinier Olislagers wrote:
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 af
In our previous episode, Sven Barth said:
> > 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
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 conne
Am 30.09.2014 22:19 schrieb "Mark Morgan Lloyd" <
markmll.fpc-pas...@telemetry.co.uk>:
>
> 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
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
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 th
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
res
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 inc
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 com
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 i
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.microso
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=
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 en
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 init
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-pasc
Reinier Olislagers wrote:
On 29/09/2014 17:41, Mark Morgan Lloyd wrote:
Reinier Olislagers wrote:
On 29/09/2014 11:19, Mark Morgan Lloyd wrote:
Reinier Olislagers wrote:
2. In businesslayer.pas, $define CRASH to see the problem.
The code in question is:
initialization
DBLayer:=TDBInterface.
On 29/09/2014 17:41, Mark Morgan Lloyd wrote:
> Reinier Olislagers wrote:
>> On 29/09/2014 11:19, Mark Morgan Lloyd wrote:
>>> Reinier Olislagers wrote:
2. In businesslayer.pas, $define CRASH to see the problem.
The code in question is:
initialization
DBLayer:=TDBInterface.Cre
Reinier Olislagers wrote:
On 29/09/2014 11:19, Mark Morgan Lloyd wrote:
Reinier Olislagers wrote:
2. In businesslayer.pas, $define CRASH to see the problem.
The code in question is:
initialization
DBLayer:=TDBInterface.Create;
finalization
DBLayer.Free;
... so probably initialization order
On 29/09/2014 16:51, José Mejuto wrote:
> El 29/09/2014 a las #4, Reinier Olislagers escribió:
> You must not initialize dbengine in the Initialization section and must
> not finalize it in that place (maybe only as last chance) because
> initialization order and finalization order is undefined by
El 29/09/2014 a las #4, Reinier Olislagers escribió:
What I would like to know what is the cause of this problem - dlls being
loaded before some kind - what kind? - of initialization is complete?
Anyway, I'll keep digging; probably first looking at geting postgresql
support in anyway.
_
On 29/09/2014 11:19, Mark Morgan Lloyd wrote:
> Reinier Olislagers wrote:
> What happens if you move the responsibility for initialising and closing
> the database connection to the app-level code? In other words, the app
> does something like
Ok, after eliminating some PEBKAC, my real dll works f
On 29/09/2014 11:19, Mark Morgan Lloyd wrote:
> Reinier Olislagers wrote:
>> 2. In businesslayer.pas, $define CRASH to see the problem.
>> The code in question is:
>> initialization
>> DBLayer:=TDBInterface.Create;
>>
>> finalization
>> DBLayer.Free;
>> ... so probably initialization order play
Reinier Olislagers wrote:
Apparently my crashes in a dll that use Firebird have to do with
initialization sections in my business layer creating a single instance
of my db layer.
Distilled reproducible code that demonstrates problem:
https://bitbucket.org/reiniero/fpc_laz_patch_playground/downlo
Apparently my crashes in a dll that use Firebird have to do with
initialization sections in my business layer creating a single instance
of my db layer.
Distilled reproducible code that demonstrates problem:
https://bitbucket.org/reiniero/fpc_laz_patch_playground/downloads/dllcrash.zip
1. Please
26 matches
Mail list logo
