Thread: [Gtk2forpascal-devel] =?gb2312?B?RXhhbXBsZXMgZG9lc24ndCB3b3JrIGF0IGFsbCE=?=
Brought to you by:
mgaertner
Menu
▾
▴
gtk2forpascal-devel
|
From: mili <mil...@16...> - 2002-07-30 13:59:15
|
Hello, Every one
I downloaded the latest .tgz file from sourceforge.net
(gtk2forpascal-0.4.tgz). I ran the script
"compile_with_fpc_under_linux.sh" under redhat 7.3 with a
freepascal 1.0.6, and the compilation is successful. Then I enter
the path "examples" and ran "make_examples.sh". When I tried to run
any created executables, I get the following errors:
>>>>>>>
specified class size for type `GParamChar' isspecified class size
for type `GParamChar' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamUChar' ispecified class size
for type `GParamUChar' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamBoolean'specified class size
for type `GParamBoolean' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamInt' is specified class size
for type `GParamInt' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamUInt' isspecified class size
for type `GParamUInt' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamLong' isspecified class size
for type `GParamLong' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamULong' ispecified class size
for type `GParamULong' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamInt64' ispecified class size
for type `GParamInt64' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamUInt64' specified class size
for type `GParamUInt64' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamUnichar'specified class size
for type `GParamUnichar' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamEnum' isspecified class size
for type `GParamEnum' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamFlags' ispecified class size
for type `GParamFlags' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamFloat' ispecified class size
for type `GParamFloat' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamDouble' specified class size
for type `GParamDouble' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamString' specified class size
for type `GParamString' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamParam' ispecified class size
for type `GParamParam' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamBoxed' ispecified class size
for type `GParamBoxed' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamPointer'specified class size
for type `GParamPointer' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamValueArrspecified class size
for type `GParamValueArray' is smaller than the parent type's
`GParam' class size
specified class size for type `GParamObject' specified class size
for type `GParamObject' is smaller than the parent type's `GParam'
class size
An unhandled exception occurred at 0x40318F2B :
Access violation
0x40318F2B
0x4031908E
0x4031ABED
0x40317552
0x403175C9
0x402A5F6F
0x400FFD06
0x401000DF
>>>>>>
I am confused by the errors. Can anybody help me to solve the
problems and make the gtk2forpascal work well? Actually, I have
been waiting for such an interface for quite a long time. I like
it. BTW, my free pascal is version 1.0.6-beta [2002/04/30] for
i386.
Thank you very much.
mili
0x080794DB
0x0804DC00 |
|
From: Olaf L. <le...@ne...> - 2002-07-30 14:19:25
Attachments:
compile_with_fpc.sh
|
Hi Mili!
We've discovered serious linking problems using fpc under linux (win32
works well). It seems as if fpc (in any version) has a linking bug that
prevents these examples to be linked correctly. Well, we are working on
it. Mattias Gaertner has created a script to link the pascal programs
correctly. You might try it. Simply put it in the directory where the
source file is kept and give the filename as argument:
./compile_with_fpc.sh sourcefile.pas
BTW: libraries seem to be linked correctly.
Please report us if this solves your problem.
Ciao,
Olaf
Am Die, 2002-07-30 um 15.58 schrieb mili:
Hello, Every one
I downloaded the latest .tgz file from sourceforge.net
(gtk2forpascal-0.4.tgz). I ran the script
"compile_with_fpc_under_linux.sh" under redhat 7.3 with a
freepascal 1.0.6, and the compilation is successful. Then I enter
the path "examples" and ran "make_examples.sh". When I tried to run
any created executables, I get the following errors:
>>>>>>>
specified class size for type `GParamChar' isspecified class size
for type `GParamChar' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamUChar' ispecified class size
for type `GParamUChar' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamBoolean'specified class size
for type `GParamBoolean' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamInt' is specified class size
for type `GParamInt' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamUInt' isspecified class size
for type `GParamUInt' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamLong' isspecified class size
for type `GParamLong' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamULong' ispecified class size
for type `GParamULong' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamInt64' ispecified class size
for type `GParamInt64' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamUInt64' specified class size
for type `GParamUInt64' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamUnichar'specified class size
for type `GParamUnichar' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamEnum' isspecified class size
for type `GParamEnum' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamFlags' ispecified class size
for type `GParamFlags' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamFloat' ispecified class size
for type `GParamFloat' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamDouble' specified class size
for type `GParamDouble' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamString' specified class size
for type `GParamString' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamParam' ispecified class size
for type `GParamParam' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamBoxed' ispecified class size
for type `GParamBoxed' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamPointer'specified class size
for type `GParamPointer' is smaller than the parent type's `GParam'
class size
specified class size for type `GParamValueArrspecified class size
for type `GParamValueArray' is smaller than the parent type's
`GParam' class size
specified class size for type `GParamObject' specified class size
for type `GParamObject' is smaller than the parent type's `GParam'
class size
An unhandled exception occurred at 0x40318F2B :
Access violation
0x40318F2B
0x4031908E
0x4031ABED
0x40317552
0x403175C9
0x402A5F6F
0x400FFD06
0x401000DF
>>>>>>
I am confused by the errors. Can anybody help me to solve the
problems and make the gtk2forpascal work well? Actually, I have
been waiting for such an interface for quite a long time. I like
it. BTW, my free pascal is version 1.0.6-beta [2002/04/30] for
i386.
Thank you very much.
mili
0x080794DB
0x0804DC00
=============================================================
Ãâ·ÑÓÊÏ䜡¿µÉ±¶ŸŽóÐж¯£¡
ÐĶ¯²»ÈçÐж¯ Žó»°Î÷ÓÎ2.0Ãâ·Ñ²âÊÔÖÐ
ÍøÒ׷dz£ÄÐÅ® Ž«µÝ¶ÌÐÅÇéžüÅš
|
|
From: Mattias G. <nc-...@ne...> - 2002-07-30 14:31:20
|
On Tue, 30 Jul 2002 21:58:56 +0800 (CST) "mili" <mil...@16...> wrote: > Hello, Every one > > I downloaded the latest .tgz file from sourceforge.net > (gtk2forpascal-0.4.tgz). I ran the script > "compile_with_fpc_under_linux.sh" under redhat 7.3 with a > freepascal 1.0.6, and the compilation is successful. Then I enter > the path "examples" and ran "make_examples.sh". When I tried to run > any created executables, I get the following errors: > > >>>>>>> > specified class size for type `GParamChar' isspecified class size > for type `GParamChar' is smaller than the parent type's `GParam' > class size > [...] This is a known problem with the linking order. It seems, that the gtk2 needs a special linking order. But there is no nice option to tell the compiler. You can use the script examples/gtk+/demo/compile_with_fpc_under_linux.sh, which compiles and links manually. For example: cd examples/gtk+/demo/ ./compile_with_fpc_under_linux.sh gtk_demo.pas You can use this script to compile any example. Meanwhile we are searching for a better solution. > I am confused by the errors. Can anybody help me to solve the > problems and make the gtk2forpascal work well? Actually, I have > been waiting for such an interface for quite a long time. I like > it. BTW, my free pascal is version 1.0.6-beta [2002/04/30] for > i386. I suggest to upgrade. The beta contains some errors. Mattias |
|
From: Mattias G. <nc-...@ne...> - 2002-07-30 14:38:13
|
On 30 Jul 2002 16:19:30 +0200 Olaf Leidinger <le...@ne...> wrote: > Hi Mili! > > We've discovered serious linking problems using fpc under linux (win32 > works well). It seems as if fpc (in any version) has a linking bug that > prevents these examples to be linked correctly. It is not a fpc bug. The fpc creates a valid link script and puts all needed libs and object files in the order, the bindings were created. But the glib redefines some variables and therefore the linking order must be changed. c programmers simply use the pkg-config output and therefore they ignore this error. > Well, we are working on it. Yep. Maybe I have an idea ... Mattias |
|
From: Olaf L. <le...@ne...> - 2002-07-30 14:46:54
|
Hello! When it isn't a bug why does it work on win32? Is there the linking order not important? > > Well, we are working on it. > Yep. Maybe I have an idea ... What's the idea? Well I'm creating a sample application that should demonstrate how to use plugins in a gtk app. Widgets are created using plugin libraries but for me it seems as if you can open only one library at once. Strange.... Ciao, Olaf |
|
From: Mattias G. <nc-...@ne...> - 2002-07-30 15:28:07
|
On 30 Jul 2002 16:46:57 +0200 Olaf Leidinger <le...@ne...> wrote: > Hello! > > When it isn't a bug why does it work on win32? Is there the linking > order not important? The glib2 bites the ld-linux.so, which win32 does not have. So, it is neither a bug of the compiler, the linker nor the OS. It is 'simply' a linker configuration issue. The gtk2 wants a special linking order under linux. And our problem is that the fpc has no option to put the dynamic linker lib into a custom order. > > > Well, we are working on it. > > > Yep. Maybe I have an idea ... > > What's the idea? Well, playing around with the libs ... > Well I'm creating a sample application that should demonstrate how to > use plugins in a gtk app. Widgets are created using plugin libraries but > for me it seems as if you can open only one library at once. Strange.... Indeed. Mattias |
|
From: Mattias G. <nc-...@ne...> - 2002-07-30 16:06:21
|
On 30 Jul 2002 16:46:57 +0200 Olaf Leidinger <le...@ne...> wrote: > Hello! > > When it isn't a bug why does it work on win32? Is there the linking > order not important? > > > > Well, we are working on it. > > > Yep. Maybe I have an idea ... > > What's the idea? static compiling, but dynamic linking I have removed the lib names from the sources under linux and changed make_examples.sh to do the trick. It will compile now all examples (except the plugin) in one step. This is not a nice solution, not even a generic one, but it should work. The question is if we should move gmodule to an unit of its own. If I remember correct, the problem arises with this part. Mattias |
|
From: Olaf L. <le...@ne...> - 2002-07-30 19:26:58
Attachments:
ppas.sh
|
SEARCH_DIR(/lib/) SEARCH_DIR(/usr/lib/) SEARCH_DIR(/usr/X11R6/lib/) SEARCH_DIR(/usr/lib/gcc-lib/i586-pc-linux-gnu/3.1/) SEARCH_DIR(./glib/plugins/) SEARCH_DIR(/home/leidola/cvs/gtk2/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/rtl/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/libasync/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/paszlib/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/syslog/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/oracle/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/opengl/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/libpng/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/gdbint/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/ncurses/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/fpasync/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/svgalib/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/postgres/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/unzip/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/uncgi/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/mysql/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/libgd/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/ibase/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/forms/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/regexpr/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/zlib/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/utmp/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/inet/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/gdbm/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/cmem/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/x11/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/gtk/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/ggi/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/fcl/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/bfd/) SEARCH_DIR(/usr/lib/fpc/1.0.6/units/linux/) SEARCH_DIR(/usr/local/lib/fpc/1.0.6/units/linux/) SEARCH_DIR(/usr/local/lib/fpc/1.0.6/units/linux/rtl/) SEARCH_DIR(/usr/lib/fpc/1.0.6/) INPUT( /usr/lib/fpc/1.0.6/units/linux/rtl/prt0.o /usr/lib/fpc/1.0.6/units/linux/rtl/errors.o /usr/lib/fpc/1.0.6/units/linux/rtl/strings.o /usr/lib/fpc/1.0.6/units/linux/rtl/linux.o /usr/lib/fpc/1.0.6/units/linux/rtl/sysutils.o /usr/lib/fpc/1.0.6/units/linux/rtl/objpas.o /home/leidola/cvs/gtk2/glib2.o /usr/lib/fpc/1.0.6/units/linux/rtl/syslinux.o ./glib/plugins/main.o ) |
|
From: Mattias G. <nc-...@ne...> - 2002-07-30 21:05:22
|
On 30 Jul 2002 21:27:04 +0200 Olaf Leidinger <le...@ne...> wrote: > What's the idea? >=20 > =20 > static compiling, but dynamic linking > =20 > I have removed the lib names from the sources under linux and chang= ed make_examples.sh to do the trick. > It will compile now all examples (except the plugin) in one step. > =20 > This is not a nice solution, not even a generic one, but it should = work. > =20 > The question is if we should move gmodule to an unit of its own. If= I remember correct, the problem arises with this part. > =20 >=20 > Well, the new script doesn't work for me. First of all the -L option is= n't converted to -k-L.=20 I said, it is not generic. I have only libs and no libpaths in my pkg-con= fig. So, your solution is better. > I've patched this. But even then it sais >=20 > Free Pascal Compiler version 1.0.6 [2002/05/23] for i386 > Copyright (c) 1993-2002 by Florian Klaempfl > Target OS: Linux for i386 > Compiling ./glib/plugins/main.pas > Assembling plugin_test > Linking ./glib/plugins/main > /usr/local/bin/ld: cannot open =CC=E5=FF=BF=D2:: Datei oder Verzeichnis= nicht > gefunden > main.pas(48) Error: Error while linking > Closing script ppas.sh >=20 > My link.res and my ppas.sh are attached. >=20 > For me everything looks okay - but only for me, not for the linker ;-) Your ppas.sh is not correct. The ld line is not complete. I have just tested: There is a 255 char limi= t for the ld line. Damn!. Ok, maybe I have another idea ... Mattias |
|
From: Mattias G. <nc-...@ne...> - 2002-07-30 21:24:18
|
I have fixed the make_examples.sh script. We don't need the sed anymore and with the smaller ld line, even the plug= in lib can be compiled. This is still a dirty solution, but probably that's the price for using d= irty c libraries. Mattias On 30 Jul 2002 21:27:04 +0200 Olaf Leidinger <le...@ne...> wrote: > Well, the new script doesn't work for me. First of all the -L option is= n't converted to -k-L.=20 > I've patched this. But even then it sais >=20 > Free Pascal Compiler version 1.0.6 [2002/05/23] for i386 > Copyright (c) 1993-2002 by Florian Klaempfl > Target OS: Linux for i386 > Compiling ./glib/plugins/main.pas > Assembling plugin_test > Linking ./glib/plugins/main > /usr/local/bin/ld: cannot open =CC=E5=FF=BF=D2:: Datei oder Verzeichnis= nicht > gefunden > main.pas(48) Error: Error while linking > Closing script ppas.sh >=20 > My link.res and my ppas.sh are attached. >=20 > For me everything looks okay - but only for me, not for the linker ;-) >=20 > Ciao, >=20 > Olaf >=20 >=20 >=20 >=20 |
|
From: Olaf L. <le...@ne...> - 2002-07-31 18:18:47
|
Hi everybody!
Well, again, (*g*) the new script doesn't work for me. The reason is
again the -L option. We need to convert this to SEARCH_DIR( [some_dir] )
for each -L option, but I'm not very good at shell-scripting. The
problem is that I don't know how to split this string into tokens. This
is no problem for pascal or c, but for shell-scripts.
If know any command command please tell me,
Ciao,
Olaf
Am Die, 2002-07-30 um 23.18 schrieb Mattias Gaertner:
I have fixed the make_examples.sh script.
We don't need the sed anymore and with the smaller ld line, even the pl=
ugin lib can be compiled.
This is still a dirty solution, but probably that's the price for using=
dirty c libraries.
=20
=20
Mattias
=20
=20
=20
On 30 Jul 2002 21:27:04 +0200
Olaf Leidinger <le...@ne...> wrote:
=20
=20
> Well, the new script doesn't work for me. First of all the -L option =
isn't converted to -k-L.=20
> I've patched this. But even then it sais
>=20
> Free Pascal Compiler version 1.0.6 [2002/05/23] for i386
> Copyright (c) 1993-2002 by Florian Klaempfl
> Target OS: Linux for i386
> Compiling ./glib/plugins/main.pas
> Assembling plugin_test
> Linking ./glib/plugins/main
> /usr/local/bin/ld: cannot open =CC=E5=FF=BF=D2:: Datei oder Verzeichn=
is nicht
> gefunden
> main.pas(48) Error: Error while linking
> Closing script ppas.sh
>=20
> My link.res and my ppas.sh are attached.
>=20
> For me everything looks okay - but only for me, not for the linker ;-=
)
>=20
> Ciao,
>=20
> Olaf
>=20
>=20
>=20
>=20
=20
=20
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code1
_______________________________________________
Gtk2forpascal-devel mailing list
Gtk...@li...
https://lists.sourceforge.net/lists/listinfo/gtk2forpascal-devel
=20
=20
|
|
From: Olaf L. <le...@ne...> - 2002-07-31 21:39:12
|
Hi!
Well, again, (*g*) the new script doesn't work for me. The reason
is again the -L option. We need to convert this to SEARCH_DIR(
[some_dir] ) for each -L option, but I'm not very good at
shell-scripting. The problem is that I don't know how to split this
string into tokens. This is no problem for pascal or c, but for
shell-scripts.
Okay, forget it! A new version is on cvs
Ciao,
Olaf
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X