Re: [fpc-pascal] 2.1.1 new protected
> 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, if USES'ing units can override it at will. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 2.1.1 new protected
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 distinction is in the first place, if USES'ing units can override it at will. Little :) Borland realized this as well and added the strict private/protected ... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Building FPC with gdb support for SPARC
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/contrib/libgdb/v6.3/ and figured I'd try using them rather than ploughing my way through the toolchain sources which looked like a 60Mb download for Debian "Sarge". After a certain amount of trial and error I worked out that the files needed to be put in /fpcsrc/libgdb/linux for make to use them. It looks as though the point at which they are initially used is OK: make -C gdbint smart make[4]: Entering directory `/fpcsrc/packages/base/gdbint' make all LINKSMART=1 CREATESMART=1 make[5]: Entering directory `/fpcsrc/packages/base/gdbint' /bin/mkdir -p units/sparc-linux /fpcsrc/compiler/ppcsparc -XX -CX -Ur -Xs -n -Fu/fpcsrc/rtl/units/sparc-linux -Fl/fpcsrc/libgdb/linux -Fo/fpcsrc/libgdb/linux -FE. -FUunits/sp /usr/bin/ar: creating units/sparc-linux/libpgdbver.a make gdbint.ppu GOTGDBVER=1 make[6]: Entering directory `/fpcsrc/packages/base/gdbint' Using GDB GDB_V603 /fpcsrc/compiler/ppcsparc -XX -CX -Ur -Xs -n -Fu/fpcsrc/rtl/units/sparc-linux -Fl/fpcsrc/libgdb/linux -Fo/fpcsrc/libgdb/linux -FE. -FUunits/sp /bin/rm -f gdbver gdbver.o make[6]: Leaving directory `/fpcsrc/packages/base/gdbint' /fpcsrc/compiler/ppcsparc -XX -CX -Ur -Xs -n -Fu/fpcsrc/rtl/units/sparc-linux -Fl/fpcsrc/libgdb/linux -Fo/fpcsrc/libgdb/linux -FE. -FUunits/sp /usr/bin/ar: creating units/sparc-linux/libpgdbcon.a make[5]: Leaving directory `/fpcsrc/packages/base/gdbint' make[4]: Leaving directory `/fpcsrc/packages/base/gdbint' (Sorry, that's slightly truncated by my telnet client). However further on things go badly wrong: /bin/mkdir -p /fpcsrc/ide/units/sparc-linux /fpcsrc/compiler/ppcsparc -dBrowserCol -dGDB -Ur -Xs -n -Ur -dNOCATCH -Fu/fpcsrc/compiler -Fu/fpcsrc/compiler/sparc -Fu/fpcsrc/compiler/targes make[5]: Leaving directory `/fpcsrc/ide/compiler' make[4]: Leaving directory `/fpcsrc/ide' make testgdb make[4]: Entering directory `/fpcsrc/ide' LibGDB found in /fpcsrc/libgdb/linux/libgdb.a make[4]: Leaving directory `/fpcsrc/ide' make fpc_all make[4]: Entering directory `/fpcsrc/ide' /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': /mnt/hda1/florian/gdb-6.3.woody/gdb/gdbtypes.c:752: undefined reference to `__muldi3' /fpcsrc/libgdb/linux/libgdb.a(ada-lang.o)(.text+0x1098): In function `max_of_size': /mnt/hda1/florian/gdb-6.3.woody/gdb/ada-lang.c:519: undefined reference to `__ashldi3' And so on. The obvious questions are: i) Are precompiled binaries of the gdb interface library available for Debian Sarge? So far I can't track down an appropriate standard package. ii) Can I compile them myself without breaking my toolchain, and if so what configure parameters etc. do I need? iii) What am I missing that is blindingly obvious? :-) -- 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/mailman/listinfo/fpc-pascal
[fpc-pascal] minor sysutils question under win32
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." ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 2.1.1 new protected
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 private/public/protected distinction is > in the first place, if USES'ing units can override it at will. > In a tool library: public -> interface for the library users, use it without knowledge of the internals. protected -> interface for the library developers, use it if you know what you do. Use strict protected if you want to secure encapsulate things. private -> secure encapsulated class items. Note that I had to use 'cracker classes' in MSEgui to access private FPC class items to implement workarounds... I must repeat: It is not possible to develop a complex system in a clean single class hierarchy, especially not if you use foreign units which are not under your control . I know it because I tried it... Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Building FPC with gdb support for SPARC
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':
/mnt/hda1/florian/gdb-6.3.woody/gdb/gdbtypes.c:752: undefined
reference
to `__muldi3'
/fpcsrc/libgdb/linux/libgdb.a(ada-lang.o)(.text+0x1098): In function
`max_of_size':
/mnt/hda1/florian/gdb-6.3.woody/gdb/ada-lang.c:519: undefined
reference to
`__ashldi3'
This can normally be solved by linking in libgcc. Try adding {$l gcc}
to the gdbint unit.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Building FPC with gdb support for SPARC
> 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':
> > /mnt/hda1/florian/gdb-6.3.woody/gdb/gdbtypes.c:752: undefined
> > reference
> > to `__muldi3'
> > /fpcsrc/libgdb/linux/libgdb.a(ada-lang.o)(.text+0x1098): In function
> > `max_of_size':
> > /mnt/hda1/florian/gdb-6.3.woody/gdb/ada-lang.c:519: undefined
> > reference to
> > `__ashldi3'
>
> 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.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Compile error in sources from SVN Rev. 4420
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
Re: [fpc-pascal] Compile error in sources from SVN Rev. 4420
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
Re: [fpc-pascal] 2.1.1 new protected
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 visible: I wonder what the use of making a private/public/protected distinction is in the first place, if USES'ing units can override it at will. In a tool library: public -> interface for the library users, use it without knowledge of the internals. protected -> interface for the library developers, use it if you know what you do. Use strict protected if you want to secure encapsulate things. private -> secure encapsulated class items. Note that I had to use 'cracker classes' in MSEgui to access private FPC class items to implement workarounds... I must repeat: It is not possible to develop a complex system in a clean single class hierarchy, especially not if you use foreign units which are not under your control . I know it because I tried it... No. It just means the classes are designed wrong. If you need to access directly private class fields, I think there are serious design flaws in your code. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Building FPC with gdb support for SPARC
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 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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Building FPC with gdb support for SPARC
> 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 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. Undocumented on
purpose, so there is a fair chance it might change in the future.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 2.1.1 new protected
> 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 protected members - well in Delphi at any rate. type TCrackControl = class(TControl); var _label: TLabel; ... TCrackControl(_label).Text := 'I can do this now'; This is pointless as the Text and Caption of a label map to the same internal data, but using this method it demonstrates access to internals. As to why Borland made a distinction between Caption and Text properties.. another debate ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Building FPC with gdb support for SPARC
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. Undocumented on > purpose, so there is a fair chance it might change in the future. OK, noted. However if it gets me out of the initial hole it's a very good start. 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 the source to pick it up? -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Building FPC with gdb support for SPARC
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
the source to pick it up?
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).
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Building FPC with gdb support for SPARC
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 reference. I was assuming that the addition was to the FPC stuff
rather than the toolchain.
--
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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling for SPARC
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 immediately expanded it to the full path. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling for SPARC
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 works. Didn't help, make immediately expanded it to the full path. Actually, I was wrong earlier on when I said it would always add 3 file names. It does this: function GetNextFiles(const maxCmdLength : AInt; var item : TStringListItem) : string; begin result := ''; while (assigned(item) and ((length(result) + length(item.str) + 1) < maxCmdLength)) do begin result := result + ' ' + item.str; item := TStringListItem(item.next); end; end; ... repeat Replace(nextcmd,'$FILES',GetNextFiles(240 - length(nextcmd) + 6 - length(binstr) - 1, current)); success:=DoExec(binstr,nextcmd,false,true); nextcmd := cmdstr; until (not assigned(current)) or (not success); 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. And it's clear that if not a single file name fits in this string, this is going to produce an endless loop of empty "ar" invocations (as you experienced)... Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling for SPARC
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^));
{ create AR commands }
success := true;
nextcmd := cmdstr;
current := TStringListItem(SmartLinkOFiles.First);
repeat
Replace(nextcmd,'$FILES',GetNextFiles(240 - length(nextcmd)
+ 6 - length
(binstr) - 1, current));
success:=DoExec(binstr,nextcmd,false,true);
nextcmd := cmdstr;
until (not assigned(current)) or (not success);
The first replace already puts the library name in the string. So if
the directory + name of that library (which always is in a subdir of
the unit output directory) is around 120 chars, things do add up.
Not sure how to fix this properly though, except by finally doing
that whole "replace Dos and shortstrings with Sysutils and
ansistrings for all external interfacing in the compiler" thing.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling for SPARC
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 if not a single file name fits in this string, > this is going to produce an endless loop of empty "ar" invocations > (as you experienced)... Yes, I thought it was going to end up something like that... :-/ -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Building FPC with gdb support for SPARC
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 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Building FPC with gdb support for SPARC
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 breaking things? No, it should require libgcc.a, which should be installed on your system already. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
