Re: [fpc-pascal] i386-darwin -> powerpc-darwin crash
Jonas Maebe schreef: On 09 May 2007, at 19:59, Vincent Snijders wrote: I tried to create powerpc units for the lcl on an intelmac, but the compiler crashes. Is this a known issue? The compiler is trying to use RTL/packages units compiled by a native ppc compiler (most likely the ones globally installed on the system). Those cannot be used by a little->big endian cross compiler. Try instead something like this: make OPT="-n -Fu~/fpcinst/usr/local/lib/fpc/2.1.4/units/powerpc-darwin/* -O2 -vei -ap" FPC=~/fpcinst/usr/local/lib/fpc/2.1.4/ppcppc clean all Thanks for guiding me in the right direction. What actually happened is that I created a native powerpc compiler (because I had set crossinstall=1 on the make all command) and used that native compiler to create my units. Now I am using the ppcrossppc (renamed to ppcppc) and things are working. PS: note that if you're doing this on mischi's iMac, it won't work when linking: /usr/bin/powerpc-darwin-ld: warning /sw/lib//libglib-1.2.0.dylib cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) That is not a problem, because I only provide lcl and related compiled units. This should be enough for people who have the right libraries to cross compile their applications. It does mean of course, I cannot test it. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Class Memory Table Size
Op Wed, 9 May 2007, schreef Andrew Haines: > Daniël Mantione wrote: > > > > Op Tue, 8 May 2007, schreef Andrew Haines: > > > >> The reason for this is, I want to trick gtk into thinking that a TObject > >> is really a GObject. This is where the TypeID for GType's are stored. I > >> know this won't work for most GObject's, but I am only implementing this > >> for a GInterface which is looked up by the TypeID, so that is all I need. > >> > >> I've tested this and it is working. But what horrible things can happen? > > > > I think it is much better to use objects for this rather than classes. A > > construction like this: > > > > type gobject=object > > gobject_typeid:...; > >end; > > > >gobject_child=object(gobject) > > constructor init; > > destructor done;virtual; > >end; > > > > ... will exactly to what you want: the gobject_typeid is at offset > > 0 while the size and vmt index are stored after that. > > > > type > TBaseObject=object > FGObject: TGObject; > end; > > TMyObject=object(TBaseObject) > procedure MyProcedure; virtual; cdecl; > end; > > This is working perfectly. I am letting gtk allocate the object's > memory, then in the instance_init func that gtk calls I am running .Init > for the object and voila! I have a real object that I can pass to gtk > and use in my program. I think this is an interresting way to talk to the gtk. I wonder how far can go interfacing directly without adding wrappers. I.e. most GTK function use a pointer to a GTK type as first parameter, which is binary compatible with a self pointer... Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] i386-darwin -> powerpc-darwin crash
On 09 May 2007, at 19:59, Vincent Snijders wrote: I tried to create powerpc units for the lcl on an intelmac, but the compiler crashes. Is this a known issue? The compiler is trying to use RTL/packages units compiled by a native ppc compiler (most likely the ones globally installed on the system). Those cannot be used by a little->big endian cross compiler. Try instead something like this: make OPT="-n -Fu~/fpcinst/usr/local/lib/fpc/2.1.4/units/powerpc- darwin/* -O2 -vei -ap" FPC=~/fpcinst/usr/local/lib/fpc/2.1.4/ppcppc clean all (-n to prevent the compiler loading the global config files) Jonas PS: note that if you're doing this on mischi's iMac, it won't work when linking: /usr/bin/powerpc-darwin-ld: warning /sw/lib//libglib-1.2.0.dylib cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) /usr/bin/powerpc-darwin-ld: warning /sw/lib//libgdk-1.2.0.dylib cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) /usr/bin/powerpc-darwin-ld: warning /sw/lib//libgtk-1.2.0.dylib cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) /usr/bin/powerpc-darwin-ld: warning /sw/lib//libgdk_pixbuf.dylib cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) (i.e., only the i386 versions of those libraries are installed on the system) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] i386-darwin -> powerpc-darwin crash
Hi, I tried to create powerpc units for the lcl on an intelmac, but the compiler crashes. Is this a known issue? Vincent Schindlers-iMac:~/src/lazarus/lcl fpcfan$ make CPU_TARGET=powerpc FPC=~/fpc/bin/fpc /bin/rm -f units/powerpc-darwin/alllclunits.ppu /bin/mkdir -p units/powerpc-darwin /Users/fpcfan/fpc/bin/fpc -gl -Fu. -Funonwin32 -Fuforms -Fuwidgetset -Fiinclude -FE. -FUunits/powerpc-darwin -dpowerpc alllclunits.pp Free Pascal Compiler version 2.1.5 [2007/05/09] for powerpc Copyright (c) 1993-2007 by Florian Klaempfl Target OS: Darwin for PowerPC Compiling alllclunits.pp Fatal: Compilation aborted An unhandled exception occurred at $0004A35C : EListError : List count too large (252444672) $0004A35C Error: /Users/fpcfan/fpc/bin/ppcppc returned an error exitcode (normal if you did not specify a source file to be compiled) make: *** [alllclunits.ppu] Error 1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Class Memory Table Size
Daniël Mantione wrote: > > Op Tue, 8 May 2007, schreef Andrew Haines: > >> The reason for this is, I want to trick gtk into thinking that a TObject >> is really a GObject. This is where the TypeID for GType's are stored. I >> know this won't work for most GObject's, but I am only implementing this >> for a GInterface which is looked up by the TypeID, so that is all I need. >> >> I've tested this and it is working. But what horrible things can happen? > > I think it is much better to use objects for this rather than classes. A > construction like this: > > type gobject=object > gobject_typeid:...; >end; > >gobject_child=object(gobject) > constructor init; > destructor done;virtual; >end; > > ... will exactly to what you want: the gobject_typeid is at offset > 0 while the size and vmt index are stored after that. > type TBaseObject=object FGObject: TGObject; end; TMyObject=object(TBaseObject) procedure MyProcedure; virtual; cdecl; end; This is working perfectly. I am letting gtk allocate the object's memory, then in the instance_init func that gtk calls I am running .Init for the object and voila! I have a real object that I can pass to gtk and use in my program. Thanks, Andrew ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Widestrings length and character iteration
Op Wed, 9 May 2007, schreef Christos Chryssochoidis:
> OK, I figured out what happened. The source file was saved in UTF-8 encoding,
> but I hadn't put in my source file the compiler directive {$CODEPAGE UTF8}.
> After including this directive in my code almost everything worked fine:
> length() was returning the right number of unicode characters, and
> subscripting the widestring returned the right character. But as the widechar
> and widestring encoding is, as you said, UTF-16, while my Mac OS X console
> uses UTF-8 encoding, for the output results to be displayed correctly I had to
> wrap the individual widechars or the whole widestring with the function
> utf8encode(), prior to output them with write()...
This means no widestring manager was used; the default dumb widestring
manager converts to iso-8859-1. Use the "cwstring" unit will use the
system encoding when reading/writing widestrings.
Daniël___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Widestrings length and character iteration
Daniël Mantione wrote:
>
> Op Mon, 7 May 2007, schreef Christos Chryssochoidis:
>
>> Daniël Mantione wrote:
>>> Not possible, a widestring is UCS-2/UTF-16.
>> I defined a widestring with 7 characters (code points), and the
length()
>> function returned the value 15. Of the 7 code points of that
widestring only
>> one of them was greater than $07FF (the maximum code point which can be
>> encoded in 2 bytes under UTF-8). When I changed that character with
another
>> one with code not greater than $07FF, length() returned value 14...
I also
>> printed the byte values of one of the widestring's widechars, and
the values
>> printed indicated UTF-8 encoding.
>
> Yes, the program output is utf-8 on OS-X, because this is the native
> encoding for OS-X. However, widestrings are not utf-8. Can you show your
> code?
>
> Daniël
>
>
>
>
> ___
> fpc-pascal maillist -
[EMAIL PROTECTED]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
OK, I figured out what happened. The source file was saved in UTF-8
encoding, but I hadn't put in my source file the compiler directive
{$CODEPAGE UTF8}. After including this directive in my code almost
everything worked fine: length() was returning the right number of
unicode characters, and subscripting the widestring returned the right
character. But as the widechar and widestring encoding is, as you said,
UTF-16, while my Mac OS X console uses UTF-8 encoding, for the output
results to be displayed correctly I had to wrap the individual widechars
or the whole widestring with the function utf8encode(), prior to output
them with write()...
Thanks for your help,
Christos
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
