It is ugly, produces warnings and is possibly forbidden in FPC 2.1.1 (I don't
know). A more elegant solution would be to have something like 'friend units'
where protected class members are visible:
I wonder what the use of making a private/public/protected distinction is in
the first place,
Marco van de Voort wrote:
It is ugly, produces warnings and is possibly forbidden in FPC 2.1.1 (I don't
know). A more elegant solution would be to have something like 'friend units'
where protected class members are visible:
I wonder what the use of making a private/public/protected
I think I've worked out how to build fpc and fp 2.0.4 for SPARC starting off
from 2.0.0, many thanks in particular to Jonas. The next question, before I try
moving the result to a virgin machine, is how to add gdb support.
I eventually found the libraries at
Why does sysutils use CharUpperBuff() user32.dll function instead of
CharUpper(): it does not check the return value?
(last 2.1.x SVN)
---
By the way: (from MSDN regarding CharUpper()) Return value...There is no
indication of success or failure. Failure is rare.
On Sunday 13 August 2006 13.27, Marco van de Voort wrote:
It is ugly, produces warnings and is possibly forbidden in FPC 2.1.1 (I
don't know). A more elegant solution would be to have something like
'friend units' where protected class members are visible:
I wonder what the use of making a
On 14 aug 2006, at 12:21, Mark Morgan Lloyd wrote:
/fpcsrc/compiler/ppcsparc -Fl/fpcsrc/libgdb/linux -Ur -Xs -n -Sg
-Fu/fpcsrc/rtl/units/sparc-linux -Fu/fpcsrc/fv/units/sparc-linux -
Fu/fpcsrc/s
/fpcsrc/libgdb/linux/libgdb.a(gdbtypes.o)(.text+0x1154): In function
`create_array_type':
On 14 aug 2006, at 12:21, Mark Morgan Lloyd wrote:
/fpcsrc/compiler/ppcsparc -Fl/fpcsrc/libgdb/linux -Ur -Xs -n -Sg
-Fu/fpcsrc/rtl/units/sparc-linux -Fu/fpcsrc/fv/units/sparc-linux -
Fu/fpcsrc/s
/fpcsrc/libgdb/linux/libgdb.a(gdbtypes.o)(.text+0x1154): In function
Hi,
The problem is, missed keyword 'class' in zipper.pp line 368 and 439.
Gabor
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On Mon, 14 Aug 2006, Gabor Boros wrote:
Hi,
The problem is, missed keyword 'class' in zipper.pp line 368 and 439.
Fixed.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On Mon, 14 Aug 2006, Martin Schreiber wrote:
On Sunday 13 August 2006 13.27, Marco van de Voort wrote:
It is ugly, produces warnings and is possibly forbidden in FPC 2.1.1 (I
don't know). A more elegant solution would be to have something like
'friend units' where protected class members are
On 14 aug 2006, at 13:20, Marco van de Voort wrote:
This can normally be solved by linking in libgcc. Try adding {$l gcc}
to the gdbint unit.
2.0.4's and recent 2.1.1/2.0.3's, (rougly all versions since mid-
end june),
put
-XLAc=c,gcc
in your fpc.cfg to fix similar cases globally.
I
On 14 aug 2006, at 13:20, Marco van de Voort wrote:
This can normally be solved by linking in libgcc. Try adding {$l gcc}
to the gdbint unit.
2.0.4's and recent 2.1.1/2.0.3's, (rougly all versions since mid-
end june),
put
-XLAc=c,gcc
in your fpc.cfg to fix similar cases
No. It just means the classes are designed wrong.
Very true. There are a number of places in Delphi's VCL where this is
true... for D5 at least.
If you need to access directly private class fields, I think there are
serious design flaws in your code.
Class crackers only give access to
Marco van de Voort wrote:
-XLAc=c,gcc
in your fpc.cfg to fix similar cases globally.
I thought this was not supposed to be publicised/encouraged? (and
that for that reason you didn't add this option to the help pages?)
Jonas is right. Sorry, this is undocumented behaviour.
On 14 aug 2006, at 14:46, Mark Morgan Lloyd wrote:
What is the correct solution to the problem, and allowing for the
fact that the
available binary libgdb was SPARC where does this leave somebody
building for
another architecture- do they need to compile the full GNU
toolchain then patch
Jonas Maebe wrote:
The {$l gcc} does not have to be added to the GNU toolchain sources,
only to our interfacing unit with libgdb (namely packages/base/gdbint/
gdbint.pp). And only for certain platforms that need it (not all of
them do, which is why it isn't there yet).
OK, noted for
Mark Morgan Lloyd wrote:
This fails when the longest filename is around 119 characters, but is OK
when it is a couple of characters shorter.
As an experiment, I'm going to leave the actual directory the same length but
see if setting up a short symlink to it works.
Didn't help, make
On 14 aug 2006, at 15:19, Mark Morgan Lloyd wrote:
This fails when the longest filename is around 119 characters, but
is OK
when it is a couple of characters shorter.
As an experiment, I'm going to leave the actual directory the same
length but
see if setting up a short symlink to it
On 14 aug 2006, at 15:33, Jonas Maebe wrote:
I'm not sure where exactly 119 fits in here, unless length(binstr)
(full path to your copy of ar) around 120 chars or so.
I forgot to add some more relevant code:
Replace(cmdstr,'$LIB',maybequoted
(current_module.staticlibfilename^));
Jonas Maebe wrote:
I'm not sure where exactly 119 fits in here, unless length(binstr)
(full path to your copy of ar) around 120 chars or so.
0 1[EMAIL PROTECTED]:/fpcsrc$ which ar
/usr/bin/ar
About enough room for the path to ar, some options, and a couple of filenames.
And it's clear that
Mark Morgan Lloyd wrote:
OK, noted for reference. I was assuming that the addition was to the FPC stuff
rather than the toolchain.
Requires gcc.o, which I presume implies that the entire toolchain has to be on
the system. Can I generate that without risking breaking things?
--
Mark Morgan
On 14 Aug 2006, at 23:58, Mark Morgan Lloyd wrote:
OK, noted for reference. I was assuming that the addition was to
the FPC stuff
rather than the toolchain.
Requires gcc.o, which I presume implies that the entire toolchain
has to be on
the system. Can I generate that without risking
22 matches
Mail list logo
