Update: this is something really really weird, if AStream.Free (last
statement) in linguc.lpr is removed, then the error's totally GONE!
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Segmentation-fault-gone-if-compiled-with-glh-tp3334353p3335939.html
Sent from
W dniu 10.01.2011 20:41, Michael Van Canneyt pisze:
On Mon, 10 Jan 2011, dib...@wp.pl wrote:
Sorry for refreshing, but the problem is still present :( . It works
perfect on my mashine (ubuntu 10.10 64 bit) but doesn't work on my
friends computer. For example, one of my friend have this same
- "michael vancanneyt" schreef:
> > My solution, in short, is that packages should have OS independent
> interface
> > to RTL built into executable visible to packages as RTL built as c
> package
> > (with is a bridge to real RTL).
>
> I understood that. Assuming you can make this interfa
On Mon, 10 Jan 2011, dib...@wp.pl wrote:
Sorry for refreshing, but the problem is still present :( . It works perfect
on my mashine (ubuntu 10.10 64 bit) but doesn't work on my friends computer.
For example, one of my friend have this same laptop as me and exactly this
same version of ubuntu
W dniu 02.01.2011 23:21, Michael Van Canneyt pisze:
On Sun, 2 Jan 2011, dib...@wp.pl wrote:
Hi,
Month ago I posted a bug (http://bugs.freepascal.org/view.php?id=18117)
Admin give me solution and feedback, but this solution doesn't work
well and i think he don't read my last comment.
So, may
I've tried changing const to constref and recompile fgl unit, no effect :(
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Segmentation-fault-gone-if-compiled-with-glh-tp3334353p3335091.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
10.01.2011 17:40, Jonas Maebe пишет:
On 10 Jan 2011, at 14:46, Alex Shishkin wrote:
By the way despite the fact that static linking to external libraries
will be impossible, but dynamic linking could be implemented. Anyway
I understand that platform independence of code imposes certain
restr
Den 10-01-2011 16:10, Jonas Maebe skrev:
On 10 Jan 2011, at 06:54, Jeppe Johansen wrote:
Doesn't the problem lie in that TFPGObjectList uses @ on the incoming
parameters?
function TFPGObjectList.Add(const Item: T): Integer;
begin
Result := inherited Add(@Item);
end;
Unless there's some mag
On 10 Jan 2011, at 06:54, Jeppe Johansen wrote:
Doesn't the problem lie in that TFPGObjectList uses @ on the
incoming parameters?
function TFPGObjectList.Add(const Item: T): Integer;
begin
Result := inherited Add(@Item);
end;
Unless there's some magic going on, won't it then point to the
On 10 Jan 2011, at 14:46, Alex Shishkin wrote:
By the way despite the fact that static linking to external
libraries will be impossible, but dynamic linking could be
implemented. Anyway I understand that platform independence of code
imposes certain restrictions and that restrictions impac
As an example, your
proposal would imply that no external calls whatsoever would be possible
(including calls to external libraries due to them using different calling
conventions, etc.).
Tomas
By the way despite the fact that static linking to external libraries
will be impossible, but dynam
In our previous episode, michael.vancann...@wisa.be said:
> >> work as packages are intended to work.
> >
> > Could you explain this?
>
> A Delphi DLL on windows is roughly equivalent to a exe.
> A fully contained binary, no dependencies.
DLL's can perfectly fine depend on other binaries.
I assu
Sorry, I was referring to the new code. Yes, that line adds class instance to
TFPGObjectList.
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Segmentation-fault-gone-if-compiled-with-glh-tp3334353p3334791.html
Sent from the Free Pascal - General mailing list arc
> In the program I could narrow the problem down to line 117 in parser.pp.
> If that one was removed it ran fine
Of course, because removing that line causes nothing to be parsed (it's the
first top level production that deals with something from the input) ;)
--
View this message in context:
On Mon, 10 Jan 2011, Marco van de Voort wrote:
In our previous episode, michael.vancann...@wisa.be said:
The main problem is the Windows target where a library is more like a
self-contained exe. On Linux (and probably Mac OS), libraries already
work as packages are intended to work.
Could y
On Mon, January 10, 2011 13:46, alexv...@mail.ru wrote:
> 10.01.2011 15:31, Marco van de Voort пи�о�:
>> In our previous episode, alexv...@mail.ru said:
>>> But I want packages to be binary portable between OS (on target
>>> processor architecture)
>> That's effectively not possible with all O
In our previous episode, alexv...@mail.ru said:
> >> But I want packages to be binary portable between OS (on target
> >> processor architecture)
> > That's effectively not possible with all OSes providing such emulation
> > ABI.
> >
> > Esperanto for OSes so to speak.
> >
> Does "inefficiently" m
10.01.2011 15:31, Marco van de Voort пишет:
In our previous episode, alexv...@mail.ru said:
But I want packages to be binary portable between OS (on target
processor architecture)
That's effectively not possible with all OSes providing such emulation ABI.
Esperanto for OSes so to speak.
__
In our previous episode, Matt Emson said:
> > Like I said, your proposal requires that we emulate all OSes on all
> > other OSes.
>
> Or create a VM layer that levels the OS level differences - but again,
> why do this? Creating such a VM is probably a magnitude of complexity
> over just using
In our previous episode, Sven Barth said:
>
> The main point with packages is that a package is a libary that can be
> loaded at runtime with some compiler magic.
IMHO that is only secondary.
The primary point is that a set of units (+mainprogram) can be divided over
multiple binaries transpar
In our previous episode, alexv...@mail.ru said:
> But I want packages to be binary portable between OS (on target
> processor architecture)
That's effectively not possible with all OSes providing such emulation ABI.
Esperanto for OSes so to speak.
___
In our previous episode, michael.vancann...@wisa.be said:
> The main problem is the Windows target where a library is more like a
> self-contained exe. On Linux (and probably Mac OS), libraries already
> work as packages are intended to work.
Could you explain this?
_
10.01.2011 14:09, michael.vancann...@wisa.be пишет:
I understood that. Assuming you can make this interface (which I don't
believe), your solution is still not realistic:
And how will you make a package that uses a os-specific function OS
independent ? (for instance, a package with a control
On 10/01/2011 11:09, michael.vancann...@wisa.be wrote:
Like I said, your proposal requires that we emulate all OSes on all
other OSes.
Or create a VM layer that levels the OS level differences - but again,
why do this? Creating such a VM is probably a magnitude of complexity
over just using
On Mon, 10 Jan 2011, alexv...@mail.ru wrote:
10.01.2011 13:50, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, alexv...@mail.ru wrote:
10.01.2011 13:05, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, Vincent Snijders wrote:
2011/1/10 alexv...@mail.ru :
But I want pac
10.01.2011 13:50, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, alexv...@mail.ru wrote:
10.01.2011 13:05, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, Vincent Snijders wrote:
2011/1/10 alexv...@mail.ru :
But I want packages to be binary portable between OS (on target
On Mon, 10 Jan 2011, alexv...@mail.ru wrote:
10.01.2011 13:05, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, Vincent Snijders wrote:
2011/1/10 alexv...@mail.ru :
But I want packages to be binary portable between OS (on target processor
architecture)
I don't think that is fe
10.01.2011 13:19, Florian Klaempfl пишет:
Am 10.01.2011 11:16, schrieb alexv...@mail.ru:
10.01.2011 13:05, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, Vincent Snijders wrote:
2011/1/10 alexv...@mail.ru:
But I want packages to be binary portable between OS (on target
processor
arc
Am 10.01.2011 11:16, schrieb alexv...@mail.ru:
> 10.01.2011 13:05, michael.vancann...@wisa.be пишет:
>>
>>
>> On Mon, 10 Jan 2011, Vincent Snijders wrote:
>>
>>> 2011/1/10 alexv...@mail.ru :
>
But I want packages to be binary portable between OS (on target
processor
architecture)
10.01.2011 13:05, michael.vancann...@wisa.be пишет:
On Mon, 10 Jan 2011, Vincent Snijders wrote:
2011/1/10 alexv...@mail.ru :
But I want packages to be binary portable between OS (on target
processor
architecture)
I don't think that is feasible, unless you don't use any OS features.
On Mon, 10 Jan 2011, Vincent Snijders wrote:
2011/1/10 alexv...@mail.ru :
But I want packages to be binary portable between OS (on target processor
architecture)
I don't think that is feasible, unless you don't use any OS features.
Exactly.
Even just because FPC supports multiple CPUs
Am 10.01.2011 11:00, schrieb alexv...@mail.ru:
10.01.2011 12:50, michael.vancann...@wisa.be пишет:
Why ? There is no need for that; You can perfectly use the OS
functionality.
All you need to do is add a layer on top which hides the OS specifics.
Borland could do it, so we can do it too.
The
2011/1/10 alexv...@mail.ru :
>>
> But I want packages to be binary portable between OS (on target processor
> architecture)
I don't think that is feasible, unless you don't use any OS features.
Vincent
___
fpc-pascal maillist - fpc-pascal@lists.freep
10.01.2011 12:58, Matt Emson пишет:
On 10/01/2011 09:26, alexv...@mail.ru wrote:
If so, there must be an executable format supported by all FPC target
platforms natively. I don't know any such format. We have to
duplicate some OS functions to make things crossplatform.
I don't think that is
Am 10.01.2011 10:58, schrieb Matt Emson:
On 10/01/2011 09:26, alexv...@mail.ru wrote:
If so, there must be an executable format supported by all FPC target
platforms natively. I don't know any such format. We have to duplicate
some OS functions to make things crossplatform.
I don't think that
10.01.2011 12:50, michael.vancann...@wisa.be пишет:
Why ? There is no need for that; You can perfectly use the OS
functionality.
All you need to do is add a layer on top which hides the OS specifics.
Borland could do it, so we can do it too.
The main problem is the Windows target where a li
On 10/01/2011 09:26, alexv...@mail.ru wrote:
If so, there must be an executable format supported by all FPC target
platforms natively. I don't know any such format. We have to duplicate
some OS functions to make things crossplatform.
I don't think that is what Sven meant. I think the executa
On Mon, 10 Jan 2011, alexv...@mail.ru wrote:
10.01.2011 12:05, Sven Barth пишет:
No, FPC should rely on the operating system for dynamic linking. There is
no use in duplicating a functionality that is already there. One "just"
needs to spot all problems that might arise on different platform
10.01.2011 12:05, Sven Barth пишет:
No, FPC should rely on the operating system for dynamic linking. There
is no use in duplicating a functionality that is already there. One
"just" needs to spot all problems that might arise on different
platforms when using dynamic libraries (e.g. symbol reso
Am 09.01.2011 22:03, schrieb alexv...@mail.ru:
24.12.2010 17:31, Sven Barth пишет:
Yeah... and only works on i386- and x86_64-linux.
Runtime packages will come sooner or later, maybe not this year (ok...
that's hard to beat ^^) and maybe not next year. But when they come
they'll be implemented
On Mon, 10 Jan 2011, Jeppe Johansen wrote:
Den 10-01-2011 02:36, leledumbo skrev:
Compile the attached project (really difficult to trim it down) using two
different options. First, using -glh, then using -g. The first one raises
nothing (program runs fine), while the second raises segmentati
41 matches
Mail list logo
