> 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 plac
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 distinctio
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
ftp://ftp.freepascal.org/pub/fpc/contri
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 m
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':
/mn
> 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
> > `cre
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
> 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 p
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 undocumente
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 refer
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 imme
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 wor
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 th
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 L
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 brea
22 matches
Mail list logo
