Torben von Deyen wrote

I'm using FPC version 1.0.4. What seems to be the problem?

You need version 1.0.5

ftp://www.lazarus.freepascal.org/lazarus/fpc-1.0.5-laz1.i386.rpm

Marc

Maybe you can make this a FAQ entry

Peter

Hi

I got a little problem compiling Lazarus. I checked out the latest source from cvs, but when I make it I get following:

svinet:/opt/fpc/lazarus# make
make -C lcl all
make[1]: Entering directory `/opt/fpc/lazarus/lcl' rm -f ./units/allunits.ppu
ppc386 -Ca -Fu./units -Fu. -Fu./interfaces/gtk -Fu/usr/lib/fpc/1.0.4/units/linux/rtl -Fu/usr/lib/fpc/1.0.4/units/linux/fcl -Fu/usr/lib/fpc/1.0.4/units/linux -Fi./include -Fi./interfaces/gtk -FE. -FU./units -di386 allunits.pp gtkproc.inc(134,49) Error: Incompatible type for arg no. 3: Got Array Of LONGINT, expected Array Of CHAR gtkproc.inc(135,49) Error: Incompatible type for arg no. 3: Got Array Of LONGINT, expected Array Of CHAR gtkproc.inc(136,49) Error: Incompatible type for arg no. 3: Got Array Of LONGINT, expected Array Of CHAR gtkproc.inc(137,49) Error: Incompatible type for arg no. 3: Got Array Of LONGINT, expected Array Of CHAR gtkproc.inc(138,49) Error: Incompatible type for arg no. 3: Got Array Of LONGINT, expected Array Of CHAR gtkint.pp(640) Fatal: There were 5 errors compiling module, stopping make[1]: *** [allunits.ppu] Error 1
make[1]: Leaving directory `/opt/fpc/lazarus/lcl'
make: *** [lcl_all] Error 2
I'm using FPC version 1.0.4.

What seems to be the problem?

Torben.

Torben von Deyen wrote

/usr/bin/ld: cannot open -lgdk: No such file or directory make[1]: Leaving directory `/opt/fpc/lazarus

Do you have gdk installed ?

other whise look at the following thread:

http://www.miraclec.com/list_archives/lazarus/3-9-00_4-24-00/msg00084.html

This sounds familiar. A while ago there was a discussion about this. You can look at:
http://www.miraclec.com/list_archives/lazarus/10-22-99_3-8-00/threads.html Search for: [lazarus] Linking Error
In short: look if you have libX11.so (as a sysmlink to libX11.so.?.?)

Tell me if this solves your problem (I'll make a faq from this)

Marc

Hi all,

I think you can't avoid it. If look at the VCL itself, how many times

are

objects referred within one unit ?? In a circular reference you do

allmost

Yes, I know the problem -sigh-.
But I think the LCL has not the 'really huge unit' problem as the VCL, because it uses includes. Michael Hess suggested to combine the code of forms.pp and controls.pp, and leave forms.pp a "dummy" unit. This will produce only a slight incompatibility and a big controls.pp. Big units are terrible (see Delphis windows.pas) but if this is the price for compatibility and optimization then I will pay. But there are only a few cases where units must be that big. If we would not try to be compatible to the VCL we would define a TAbstractCustomForm for TWinControl and we could destroy the binding between controls and forms. But I think we all agree, that this important point should be compatible to the VCL and thus the LCL has a cross dependency between TWinControl and TCustomForm. I will test Michael H.'s proposal and search for more circles.

Believe me, when I tried to create the Makefiles, I tried to first

compile

the Interface, after that the LCL (since the LCL is interface

indipendent,

only a binary interface should satisfy). There were that many circular references that I gave up.

I believe you. Although I do not understand why a unit like gtkint which I would expect to be at the bottom of the hierachy is one of the topmost.

Mattias

Hi all,

I want to discuss a structure problem in the LCL.
This is nothing new:
There some circle dependencies in the LCL. For example forms.pp<->controls.pp.
Although the compiler can handle this, there are some problems. Some weeks ago this was hidden with funny tricks like "make -C lcl" 6 times. Then a new trick was invented: -Ca. AFAIK this prevents some optimization. I believe it is bad coding to program circle dependencies. A circle is an important sign that code should be gathered in one unit.

Case 1:
graphics.pp <-> controls.pp
Even Delphi avoids this. This circle can easily be destroyed. Move the procedure CN_SendMessage from
controls.pp to lmessages.pp.

Case 2:
controls <-> dialogs
Why does controls depend on dialogs?

Case 3:
forms.pp <-> controls.pp
Delphi has the same problem. The LCL should be
very similar to the VCL, but of course we don't
want to copy the problems, do we?
The dependency is TWinControl<->TCustomForm.
To distribute them to two units is a design
mistake.

What do you think?

Mattias

You need to install the glib-devel-1.2.6*.rpm package. GLib GLibC. GLib contains basic structures used in GDK and GTK.

Peter

Mattias Gaertner wrote

I believe it is bad coding to program circle dependencies.

Possibly but not always avoidable.

By all means if this can remove a circle dependency I am all for it. The reason SendMessage was original placed in controls.pp was because I wanted to limit the location of the link between the LCL and the Widget API. Since just about everything uses controls.pp this seemed reasonable at the time. However things have evolved over time. If it now makes more sence to place this link in lmessages.pp and it doesn't break anything else and removes the circle dependency then move it. :-)

Case 2: controls <-> dialogs Why does controls depend on dialogs?

You got me there. I'm not sure why. The comment that it is needed for SetVisible doesn't make sense. Try removing it form the uses clause and see what happens.

Well this is were we tend to get into various arguements. How closely do we match the VCL and it's layout. The idea was to match the unit layout as close as possible so that very little needed to change in uses clauses in current Delphi code. You know easier porting type stuff. Is that a big factor to me. No. So maybe we should combine the controls and forms units into just the controls unit with a dummy forms unit that doesn't do anything but make code compatible.

Other comments.

:)

you're right it isn't the same. I've installed them both

from rpm -qi libc

Description :
Older Linux systems (including all Red Hat Linux releases between 2.0 and 4.2, inclusive) were based on libc version 5. The libc package includes the libc5 libraries and other libraries based on libc5. With these libraries installed, old applications which need them will be able to run on your glibc (libc version 6) based system.

The libc package should be installed so that you can run older applications which need libc version 5.

Marc

I already have it as a news item on the Welcome page but a FAQ might be in order.

I installed the recommended FPC compiler version 1.0.5, but I get this now:

....

make --assume-new=lazarus.pp lazarus
make[1]: Entering directory `/opt/fpc/lazarus'
ppc386 -Fu. -Fu./lcl/units -Fu./components/units -Fu./designer -Fu/usr/lib/fpc/1.0.5/units/linux/rtl -Fu/usr/lib/fpc/1.0.5/units/linux/fcl -Fu/usr/lib/fpc/1.0.5/units/linux -Fi. -Fi./include -Fi./include/linux -FE. -di386 lazarus.pp /usr/bin/ld: cannot open -lgdk: No such file or directory make[1]: Leaving directory `/opt/fpc/lazarus

Torben.

The howto has also to state that we need 1.0.5.

Michael: is it possible to make this configurable (so that the howto doesne have to be updated/transplated each time)

Marc

There is a great bug of Lazarus that you can not easily set the place of component. I've fixed it problem in wincontrol.inc. The property (left, top...) is not set in setbounds method!

+ From: Mattias Gaertner
+
+ Hi all,
+
+ I want to discuss a structure problem in the LCL.
+ This is nothing new:
+ There some circle dependencies in the LCL. For example
+ forms.pp<->controls.pp.
+ Although the compiler can handle this, there are some
+ problems. Some weeks ago this was hidden with funny tricks
+ like "make -C lcl" 6 times. Then a new trick was
+ invented: -Ca. AFAIK this prevents some optimization.

It isn't a trick. If you want to distribute only a binary LCL I think you need it anyhow. (Think of this: If you don't need all functionality of the LCL a more optimized LCL could exist so it needs to be recompiled for that purpose)

+ I believe it is bad coding to program circle dependencies. A
+ circle is an important sign that code should be gathered in one unit.

I think you can't avoid it. If look at the VCL itself, how many times are objects referred within one unit ?? In a circular reference you do allmost the same. Only now for redability/maintainability/etc you split one unit into 2 separate units.

If I look at the project I'm working on myself, I tried to avoid it, but unless I let my units grow (if you put all in one unit your problem is solved), I couldn't

+ What do you think?

Believe me, when I tried to create the Makefiles, I tried to first compile the Interface, after that the LCL (since the LCL is interface indipendent, only a binary interface should satisfy). There were that many circular references that I gave up.

Whithin the LCL it is a project on it's own to remove all dependencies. Sure, we should avoud it if we can, but I don't think we can without.

Marc

Mattias Gaertner wrote

Hi all, Yes, I know the problem -sigh-.

[combining units]

Point is if you combine units, you in fact hide the problem and you make indirect more references (IMO dirtier code). If you split things up for instance you cant poke in other objects private vars, which can if you put all together. In that case I think a few xrefs are ok.

I'm not to happy with that either, I still plan to do some cleanup in the far future.

For now: For callbacks it has to know about TWinControl, for GTKObject has to know about various controls to get data from etc.

Marc

I did't have the gdk installed, so I downloaded and installed gtk+-devel-1.2.6-1.i386.rpm from Red Hat. And the compilation came further:

But it then came with:

/usr/bin/ld: cannot open -lX11: No such file or directory

I made the symlink libX11.so to the libX11.so.x.y (as written in your discussion group). The compilation continued, but now this:

/usr/bin/ld: cannot open -lglib: No such file or directory

The answer might then be "you must install the glibc packages" ?? But I got the libc packages installed isn't it the same? or..

Torben.

I think clean up of the LCL is needed but I'm not sure if it should be our priority at this point. Clean up of code and functions in the LCL could be done but changing the way the units are structured could be put off until later.

Shane

>> 01/15/01 09:25AM >>>

Hi all,

I want to discuss a structure problem in the LCL.
This is nothing new:
There some circle dependencies in the LCL. For example forms.pp<->controls.pp.
Although the compiler can handle this, there are some problems. Some weeks ago this was hidden with funny tricks like "make -C lcl" 6 times. Then a new trick was invented: -Ca. AFAIK this prevents some optimization. I believe it is bad coding to program circle dependencies. A circle is an important sign that code should be gathered in one unit.

Case 1:
graphics.pp <-> controls.pp
Even Delphi avoids this. This circle can easily be destroyed. Move the procedure CN_SendMessage from
controls.pp to lmessages.pp.

Case 2:
controls <-> dialogs
Why does controls depend on dialogs?

Case 3:
forms.pp <-> controls.pp
Delphi has the same problem. The LCL should be
very similar to the VCL, but of course we don't
want to copy the problems, do we?
The dependency is TWinControl<->TCustomForm.
To distribute them to two units is a design
mistake.

What do you think?

Mattias

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus